Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

IPv6 BGP TE (was Couldflare routing problems)

 

 

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


Jean-Francois.TremblayING at videotron

Jun 21, 2012, 6:30 AM

Post #1 of 11 (681 views)
Permalink
IPv6 BGP TE (was Couldflare routing problems)

> > Out of curiosity do you follow current RIPE PA filtering
recommendation?
> > http://www.ripe.net/ripe/docs/ripe-532
> > It is suggested that prefix filters allow for prudent subdivision of
an
> > IPv6 allocation. The operator community will ultimately decide what
> > degree of subdivision is supportable, but the majority of ISPs accept
> > prefixes up to a length of /48 within PA space.
>
> No we don't, because we do not agree with that reasoning.
> In those rare occasions where it is required to announce more
> specifics out of /32 globally because of disjoint networks (and
> apart from that I see no valid reason at all),
> the individual disjoint networks should either get a separate /32
> each, or get a /48 PI out of the designated netblocks.
>
> Regards,
> Chris
> AS559

Sorry for pointing at the big pink elephant in the room, but what about
IPv6 BGP traffic engineering? This is probably not a concern on the short
term, but it could become one fairly rapidly as traffic grows. I
understand
the fears about table growth, but there's also a genuine need for ISPs to
control traffic flows, at least a few ASes away when using multiple links.


For example, on our side of the pond, using the current ARIN
recommendations
of /56s to end-users (https://www.arin.net/policy/nrpm.html#two8), a
single
/40 could represent up to 65k residential users. That's probably a few
gigs
of trafic and would be a good unit for TE. /36 is definitely way too big
for this purpose.

Any thoughts/experiences/ideas on this?

/JF
Videotron
AS5769


gert at space

Jun 21, 2012, 6:51 AM

Post #2 of 11 (648 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

Hi,

On Thu, Jun 21, 2012 at 09:30:57AM -0400, Jean-Francois.TremblayING [at] videotron wrote:
> Sorry for pointing at the big pink elephant in the room, but what about
> IPv6 BGP traffic engineering? This is probably not a concern on the short
> term, but it could become one fairly rapidly as traffic grows. I
> understand
> the fears about table growth, but there's also a genuine need for ISPs to
> control traffic flows, at least a few ASes away when using multiple links.

I do understand the need for *local* traffic engineering, but I'm not
sure why I should bother when I'm half a world away - so I'll filter your
more-specifics, and rely on the covering aggregate to reach one of
your upstream-ISPs (or someone close). Then the more-specifics will
cut in and do your local TE.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279


chris.welti at switch

Jun 21, 2012, 6:54 AM

Post #3 of 11 (642 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

Hi JF,

I specifically said I don't see a valid use case for *globally* advertising
more specifics. Locally is a different case:

Using more specifics for TE is fine towards your upstreams or direct
peers, where you can still negotiate acceptance of more specific
announcements for this purpose.

It shouldn't be a problem to also originate a covering /32 in this case, so you will
not suffer from any connectivity issues.
Of course, all your upstreams would need to accept your more specifics from each other,
for TE to be really effective, but you can include that in your contracts with them.

Regards,
Chris

Am 6/21/12 3:30 PM, schrieb Jean-Francois.TremblayING [at] videotron:
> Sorry for pointing at the big pink elephant in the room, but what
> about IPv6 BGP traffic engineering? This is probably not a concern on
> the short term, but it could become one fairly rapidly as traffic
> grows. I understand the fears about table growth, but there's also a
> genuine need for ISPs to control traffic flows, at least a few ASes
> away when using multiple links.
>
>
> For example, on our side of the pond, using the current ARIN
> recommendations of /56s to end-users
> (https://www.arin.net/policy/nrpm.html#two8), a single /40 could
> represent up to 65k residential users. That's probably a few gigs of
> trafic and would be a good unit for TE. /36 is definitely way too big
> for this purpose.
>
> Any thoughts/experiences/ideas on this?
>
> /JF Videotron AS5769
>
>


Jean-Francois.TremblayING at videotron

Jun 21, 2012, 7:24 AM

Post #4 of 11 (646 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

Hi Chris.

> I specifically said I don't see a valid use case for *globally*
advertising
> more specifics. Locally is a different case:
> Using more specifics for TE is fine towards your upstreams or direct
> peers, where you can still negotiate acceptance of more specific
> announcements for this purpose.

Glad to see your local policies could be different. This will at least
allow
for your clients to load-balance.

What about a client doing load-balacing between multiple providers? Would
you,
for example, carry longer prefixes from your clients one or multiple peers
away?
It boils down to what do you consider local vs global. You'd probably have
to
put a limit on the AS path length of the longer prefixes.

I guess this all can be negotiated with transit and peers, but it's good
to share views on this so that we end up with consistent policies
wherever that's possible.

/JF


chris.welti at switch

Jun 21, 2012, 9:23 AM

Post #5 of 11 (641 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

Hi JF,

Am 6/21/12 4:24 PM, schrieb Jean-Francois.TremblayING [at] videotron:
> Hi Chris.
>
>> I specifically said I don't see a valid use case for *globally*
> advertising
>> more specifics. Locally is a different case:
>> Using more specifics for TE is fine towards your upstreams or direct
>> peers, where you can still negotiate acceptance of more specific
>> announcements for this purpose.
>
> Glad to see your local policies could be different. This will at least
> allow
> for your clients to load-balance.
>
> What about a client doing load-balacing between multiple providers? Would
> you,
> for example, carry longer prefixes from your clients one or multiple peers
> away?

Only if it makes sense to do so. E.g. for a paying customer that is multi-homing
within our AS (as in redundantly connected to us) we will of course carry the
more specifics internally, *within* our own AS. I surely would not expect any
other upstreams or peers to accept longer prefixes. Therefore, there should
always be a covering /32 announcement with a valid path to the longer prefix.
There can be special arangements with direct peers to accept longer prefixes
in case of a mutual multi-homing customer, but I wouldn't consider that the norm.

> It boils down to what do you consider local vs global. You'd probably have
> to
> put a limit on the AS path length of the longer prefixes.
>
> I guess this all can be negotiated with transit and peers, but it's good
> to share views on this so that we end up with consistent policies
> wherever that's possible.

Well, the consistent global policy is that prefixes up to the minimum-allocation size
of the RIRs are accepted.

Regards,
Chris


mkorourke at gmail

Jun 21, 2012, 2:30 PM

Post #6 of 11 (640 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

> > advertising
>
>> more specifics.
>

- Single provider or enterprise allocated a /32
- Multiple independent global locations eg. PNG, India, New Zealand, US
- Each site advertising out a /36
- Requirement for each site is too large for a /48 allocation.
- Advert of a covering may have some very undesirable results


- Most networks it will work today will they'll accept the routes in the
above approach.
- The approach has some parallels IPv4. People are going to do this and
take v4 practice and apply to v6 if within general community guidelines -
and why not, why re-invent the wheel?
- Networks likes yours be they teir2/3/4 that don't accept a full table
in the v4 world would have a covering route with ACLs potentially used for
bogons. Why not for v6?
- What's your suggestion as to BCP for the scenario?


>
> Well, the consistent global policy is that prefixes up to the
> minimum-allocation size
> of the RIRs are accepted.
>
> Can't say I agree with your statement.

Kind Regards,

Mick


nick at foobar

Jun 21, 2012, 2:54 PM

Post #7 of 11 (639 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

On 21/06/2012 22:30, Mick O'Rourke wrote:
> On 21/06/2012 17:23, Chris Welti wrote:
> Well, the consistent global policy is that prefixes up to the
> minimum-allocation size
> of the RIRs are accepted.
>
> Can't say I agree with your statement.

Doesn't matter whether _you_ agree with it or not. The point is that there
is a nontrivial although unspecified number of service providers who filter
along RIR allocation sizes. Unless a supernet is advertised with
connectivity back to the each of the smaller subnets, connectivity to those
subnets will be arbitrarily spotty.

But - your network, your rules. If you want your customers to have woeful
ipv6 connectivity, this is an excellent way of achieving it.

Nick


mkorourke at gmail

Jun 21, 2012, 4:11 PM

Post #8 of 11 (651 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

Hi Nick,


> > Well, the consistent global policy is that prefixes up to the
> > minimum-allocation size
> > of the RIRs are accepted.
> >
> > Can't say I agree with your statement.
>
> Doesn't matter whether _you_ agree with it or not. The point is that there
> is a nontrivial although unspecified number of service providers who filter
> along RIR allocation sizes. Unless a supernet is advertised with
> connectivity back to the each of the smaller subnets, connectivity to those
> subnets will be arbitrarily spotty.
>

The point of the thread I've felt to be slightly different, that's where we
are yes - it's the current state of play.
I'd rather discuss can we enact change or work together as a collective to
find a suitable a generally agreed BCP middle ground? RIPE-532 seems to be
that BCP middle ground, yet there is disagreement around it's definition
and application - the result being what you've described.

Cheers

Mick


slz at baycix

Jun 21, 2012, 11:15 PM

Post #9 of 11 (632 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

Hi,


>
> >> I specifically said I don't see a valid use case for *globally*
> > advertising
> >> more specifics.
> • Single provider or enterprise allocated a /32
> • Multiple independent global locations eg. PNG, India, New Zealand, US
> • Each site advertising out a /36
> • Requirement for each site is too large for a /48 allocation.
> • Advert of a covering may have some very undesirable results
> • Most networks it will work today will they'll accept the routes in the above approach.
> • The approach has some parallels IPv4. People are going to do this and take v4 practice and apply to v6 if within general community guidelines - and why not, why re-invent the wheel?
> • Networks likes yours be they teir2/3/4 that don't accept a full table in the v4 world would have a covering route with ACLs potentially used for bogons. Why not for v6?
> • What's your suggestion as to BCP for the scenario?
>

i'm not sure if i understand your points in the first place, but why would an
ISP have three separate networks but only use one allocation, and why would and enterprise work with a PA allocation instead of PI assignments?

A single provider, if you mean an ISP has a single network, otherwise it's multiple ISPs by (my) definition, perhaps multiple local ISPs
sharing the same name but not being the same legal entity or AS number.
Each separate local/regional entity then would become member of the appropriate RIR and receive their own /32 or bigger allocation to
aggregate the local traffic.

A single enterprise is an end-user and doesn't aggregate assignments, so they can always apply for a separate PI assignment of the appropriate size from each responsible RIR, /48 or shorter.

One of the differences between IPv4 is that de-aggregating an IPv6 /32 or shorter into /48 is much worse than even de-aggregating even an IPv4 /16 into /24s - be it fat fingers or intentional Traffic Engineering shit.


But perhaps you can enlighten me where i misunderstood your scenario.


--
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect


mkorourke at gmail

Jun 22, 2012, 8:56 PM

Post #10 of 11 (624 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

Hi Sasha,

Sure, if you apply that definition that's another way to skin the cat; Cost
as a factor comes to mind on the below - obviously much cheaper to have a
single /32, yet being where we are and the lowest common denominator
tending to rule, obviously that just needs to be understood as a cost on
doing business, and as an architectural consideration for enterprises,
content providers or other.

One use-case that is valid globally for v6 TE and one I'm sure we're all or
will be impacted by - DDoS.
- Using TE to pull an impacted /48 or other /36 or /xy whatever is very
valid
- Getting that Chinese, Russian, USA or international traffic away from
your other customers to be cleaned
- It's a use-case commonly used globally for v4 DDoS TE ie. advert of a /24
or multiples of to pull impacted traffic into a cleaning centre
- Yes off-ramping and advert of a /32 and de-avert in other places will
work - assuming you have the capacity, it's just not a desirable scenario.
- Perhaps it's a moot issue and the TE use-case will simply work we'll
enough with the majority of the v6 world accepting /48's;

Thoughts?

Cheers

Mick

On Fri, Jun 22, 2012 at 4:15 PM, Sascha Lenz <slz [at] baycix> wrote:

> Hi,
>
>
> >
> > >> I specifically said I don't see a valid use case for *globally*
> > > advertising
> > >> more specifics.
> > • Single provider or enterprise allocated a /32
> > • Multiple independent global locations eg. PNG, India, New
> Zealand, US
> > • Each site advertising out a /36
> > • Requirement for each site is too large for a /48 allocation.
> > • Advert of a covering may have some very undesirable results
> > • Most networks it will work today will they'll accept the routes
> in the above approach.
> > • The approach has some parallels IPv4. People are going to do
> this and take v4 practice and apply to v6 if within general community
> guidelines - and why not, why re-invent the wheel?
> > • Networks likes yours be they teir2/3/4 that don't accept a full
> table in the v4 world would have a covering route with ACLs potentially
> used for bogons. Why not for v6?
> > • What's your suggestion as to BCP for the scenario?
> >
>
> i'm not sure if i understand your points in the first place, but why would
> an
> ISP have three separate networks but only use one allocation, and why
> would and enterprise work with a PA allocation instead of PI assignments?
>
> A single provider, if you mean an ISP has a single network, otherwise it's
> multiple ISPs by (my) definition, perhaps multiple local ISPs
> sharing the same name but not being the same legal entity or AS number.
> Each separate local/regional entity then would become member of the
> appropriate RIR and receive their own /32 or bigger allocation to
> aggregate the local traffic.
>
> A single enterprise is an end-user and doesn't aggregate assignments, so
> they can always apply for a separate PI assignment of the appropriate size
> from each responsible RIR, /48 or shorter.
>
> One of the differences between IPv4 is that de-aggregating an IPv6 /32 or
> shorter into /48 is much worse than even de-aggregating even an IPv4 /16
> into /24s - be it fat fingers or intentional Traffic Engineering shit.
>
>
> But perhaps you can enlighten me where i misunderstood your scenario.
>
>
> --
> Mit freundlichen Grüßen / Kind Regards
>
> Sascha Lenz [SLZ-RIPE]
> Senior System- & Network Architect
>
>
>
>
>


slz at baycix

Jun 22, 2012, 10:34 PM

Post #11 of 11 (616 views)
Permalink
Re: IPv6 BGP TE (was Couldflare routing problems) [In reply to]

Hi,

> Hi Sasha,
>
> Sure, if you apply that definition that's another way to skin the cat; Cost as a factor comes to mind on the below - obviously much cheaper to have a single /32, yet being where we are and the lowest common denominator tending to rule, obviously that just needs to be understood as a cost on doing business, and as an architectural consideration for enterprises, content providers or other.
>
> One use-case that is valid globally for v6 TE and one I'm sure we're all or will be impacted by - DDoS.
> - Using TE to pull an impacted /48 or other /36 or /xy whatever is very valid
> - Getting that Chinese, Russian, USA or international traffic away from your other customers to be cleaned
> - It's a use-case commonly used globally for v4 DDoS TE ie. advert of a /24 or multiples of to pull impacted traffic into a cleaning centre
> - Yes off-ramping and advert of a /32 and de-avert in other places will work - assuming you have the capacity, it's just not a desirable scenario.
> - Perhaps it's a moot issue and the TE use-case will simply work we'll enough with the majority of the v6 world accepting /48's;
>
> Thoughts?
>

Let's go back and see what you initially asked for:

> > • What's your suggestion as to BCP for the scenario?
> >

The BCP. Let me write that out: _best(!) current_ practice

But now you're making it about money and bad design choices due to money issues.
That's a totally different thing.

If you want to join the dark side, enable your CEO to brag about
how much money he saved by employing cheap network engineers, buying way to small internet pipes and
misuse RIR resources to other C-level guys at the golf course, then the same rules as in the IPv4 world do indeed apply:

There is no global routing police or central routing authority - if it works for you and you don't feel ashamed, so be it.
And of course things and policies can be changed in the future ( best _current_ practice ), no doubt about that.
For example there are discussions about to do away with the historic difference between PA and PI space in the RIPE region at least.
While still in infant stage, if the policy changes sometimes in the future, the BCP also might change.

--
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.