Subject: [v6ops] Fwd: I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Oct 2014 22:39:27 +0200

I've written down my ideas for controlled deaggregation of enterprise LIR prefixes.

I'm sure everyone is going to love the second half where I talk about encoding GPS coordinates into BGP communities.  :-)

Please send me all your feedback.

I'd be happy to do a short presentation about this in v6ops and/or grow next month.

Iljitsch

> A New Internet-Draft is available from the on-line Internet-Drafts directories.

>        Title           : Controlled IPv6 deaggregation by large organizations
>        Author          : Iljitsch van Beijnum
> 	Filename        : draft-van-beijnum-grow-controlled-deagg-00.txt
> 	Pages           : 8
> 	Date            : 2014-10-22

> Abstract:
>   The use of IPv6 addresses by large organizations doesn't fit the
>   commonly used PA/PI dichotomy.  Such organizations may hold a large
>   address block which is deaggregated into subprefixes that are
>   advertised by subunits of the organization.  This document proposes a
>   set of best practices to allow this deaggregation to be controlled
>   through filtering so that on the one hand, the size of the IPv6
>   global routing table isn't unduly inflated, while on the other hand
>   organizations that seek to deaggregate a large IPv6 address block
>   don't see their reachability limited by remote filters.

> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-van-beijnum-grow-controlled-deagg/

> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-van-beijnum-grow-controlled-deagg-00

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 26 Oct 2014 13:17:19 -0700

Hi, 

Regarding controlling how far a more specific travels, I've attached 'no-export' to more specific routes for TE purposes when advertising them to an upstream provider to limit their reach. Of course the trouble is that 'no-export' has a very limited scope. This discussion reminded me of this draft, which encodes an AS level hop count that can be used to limit route propagation, perhaps it or something similar needs to be revived:

"The AS_HOPCOUNT Path Attribute

2.  Introduction

   A prefix that is injected into BGP [RFC1771] will propagate
   throughout the mesh of all BGP speakers unless it is explicitly
   blocked by policy configuration.  This behavior is necessary for the
   correct operation of BGP, but has some unfortunate interactions with
   current operational procedures.  Currently, it is beneficial in some
   cases to inject longer prefixes into BGP to control the flow of
   traffic headed towards a particular destination.  These longer
   prefixes may be advertised in addition to an aggregate, even when the
   aggregate advertisement is sufficient for basic reachability.  This
   particular application is known as "inter-domain traffic engineering"
   and is a well-known phenomenon that is contributing to growth in the
   size of the global routing table [RFC3221].  The mechanism proposed
   here allows the propagation of those longer prefixes to be limited,
   allowing some traffic engineering problems to be solved without such
   global implications."

https://tools.ietf.org/html/draft-ietf-idr-as-hopcount-00

Not covered in that draft, one thought would be that upstream operators could police something like this by only accepting more specifics of your aggregate with an AS_HOPCOUNT value of <= 10.

Regards,
Mark.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 26 Oct 2014 22:51:34 +0100

> Regarding controlling how far a more specific travels, I've attached 'no-export' to more specific routes for TE purposes when advertising them to an upstream provider to limit their reach. Of cours…

Setting an AS hop limit makes some sense if you assume the origin AS wants to limit propagation of the advertisement. However, in many cases the origin AS would probably like to see a deaggregate propagate as far as possible, as this allows for the shortest paths and the highest level of redundancy.

Third party ASes, on the other hand, may want to limit how many of those deaggregates they carry, but an AS hop limit wouldn't really give them any tools to do that.

But if you think that it makes sense to specify a community like this, perhaps it would be a good idea to combine that one and the ones I'm proposing here and possibly others into a single document. That would probably make reviewing the document(s) an implementing those communities easier.

Or maybe not...

---

From: Owen DeLong <[email-masked]>
Date: Mon, 27 Oct 2014 15:20:19 -0700

What would be nice would be to have a BGP knob from vendors that could be set on a per-peer basis (or per peer-group basis) that allowed us to discard covered specifics with identical attributes on ingress.

Owen

> On Oct 26, 2014, at 2:51 PM, Iljitsch van Beijnum <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 Oct 2014 23:42:58 +0100

Considering that it takes on average two years to develop, test and ship a
knob (not to mention that you need to write a check with sufficient amount
of zeros in it) I think much better option would be just to have a
parametrized policy language.

Good news is that if I am not mistaken some vendors already support what
you are asking today :) It just requires a little bit of in depth scripting
...

I am sure your vendor of choice will be happy to support you.

Cheers,
Robert.

On Mon, Oct 27, 2014 at 11:20 PM, Owen DeLong <[email-masked]> wrote:

> What would be nice would be to have a BGP knob from vendors that could be
> set on a per-peer basis (or per peer-group basis) that allowed us to
> discard covered specifics with identical attributes on ingress.
>
> Owen
>
> >> Regarding controlling how far a more specific travels, I've attached
> 'no-export' to more specific routes for TE purposes when advertising them
> to an upstream provider to limit their reach. Of course the trouble is that
> 'no-export' has a very limited scope. This discussion reminded me of this
> draft, which encodes an AS level hop count that can be used to limit route
> propagation, perhaps it or something similar needs to be revived:
> >
> > Setting an AS hop limit makes some sense if you assume the origin AS
> wants to limit propagation of the advertisement. However, in many cases the
> origin AS would probably like to see a deaggregate propagate as far as
> possible, as this allows for the shortest paths and the highest level of
> redundancy.
> >
> > Third party ASes, on the other hand, may want to limit how many of those
> deaggregates they carry, but an AS hop limit wouldn't really give them any
> tools to do that.
> >
> > But if you think that it makes sense to specify a community like this,
> perhaps it would be a good idea to combine that one and the ones I'm
> proposing here and possibly others into a single document. That would
> probably make reviewing the document(s) an implementing those communities
> easier.
> >
> > Or maybe not...

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 28 Oct 2014 20:47:47 +0000

>discard covered specifics with identical attributes on ingress.

https://tools.ietf.org/html/draft-white-grow-overlapping-routes

:-)

Alvaro.

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 Oct 2014 09:29:13 +0900

> https://tools.ietf.org/html/draft-white-grow-overlapping-routes

DRAGON: Distributed Route Aggregation on the Global Network.
João Luís Sobrinho, Laurent Vanbever, Franck Le, Jennifer Rexford.	
ACM CoNEXT 2014. Sydney, Australia (December 2014).
http://vanbever.eu/pdfs/vanbever_dragon_conext_2014.pdf

:)

randy