Subject: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets

From: John Scudder <[email-masked]>
Date: Wed, 30 Mar 2011 12:04:13 -0700

Folks,

This is to start a working group last call for draft-ietf-idr-deprecate-as-sets-02.  Please send comments by April 13, 2011.

http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-02

Thanks,

--John

---

From: Danny McPherson <[email-masked]>
Date: Wed, 30 Mar 2011 15:57:07 -0400

If you're looking for positive acks, I support publication of this document.

All minor nits and recommendations below.

-danny

---
S.1

s/multiple routes into a new route/multiple routes into a single new route/

s/route.  These can cause/route which can cause/

---
S.3

s/filtering routers that contain/filtering routes that contain/

Also, perhaps a more appropriate title for S.3 is "Recommendation 
to Network Operators"

---
S.3 

REPLACE: "Operators are strongly advised to not generate any new announcements
   containing AS_SETs or AS_CONFED_SETs and to withdraw any existing
   routes containing them as soon as possible."

WITH: "Operators are strongly advised to not generate any new announcements
   containing AS_SETs or AS_CONFED_SETs, and to remove any AS_SETS or 
   AS_CONFED_SETS from existing routes, should they exist."

---
S.5

s/RPKI/Resource PKI (RPKI)/ and add reference?  

Also, shouldn't all those references be Informative?

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Mar 2011 04:40:45 +0200

yes, please

randy

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 03:34:12 -0400

In message <[email-masked]>
John Scudder writes:
>  
> Folks,
>  
> This is to start a working group last call for
> draft-ietf-idr-deprecate-as-sets-02.  Please send comments by April
> 13, 2011.
>  

   This will also simplify the
   design, implementation and deployment of bonging work in the Secure
   Inter-Domain Routing Working Group.

Bonging work?  Yes sometimes it seems like SIDR has been passing the
bong, but somehow I suspect the word "ongoing" was supposed to go
here.

As someone involved in possibly the only major user of AS_SET and a
former strong advocate of AS_SET, I certainly don't have any evidence
that that usage still remains.  I have no objection to removing it at
this point if no one has indicated using it.

This leaves no mechanisms for route aggregation in BGP that preserves
the BGP AS loop suppression and it might be worth mentioning this in
the document.  One sentence might be enough.

Someone may want to solve that problem in the future, or maybe not,
but it is worth one sentence to note that the problem exists.

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 31 Mar 2011 08:54:01 +0000

> the document.  One sentence might be enough.

As someone who had to try to divine why some things were in the protocol
from it's functional behavior when I couldn't manage to get history from
some of the involved parties, here's some observations:

An AS_SET is less specific route being generated from a set of more
specific routes and implies:
- All contributing ASes do *not* get the aggregate (they're in the set after
  all)
- And thus must all have all contributing routes themselves OR
  are reaching each other via the aggregator via default or similar.

In order to reduce the information in the routing system, the more specific
contributors would be suppressed.

If we consider the case there may be different aggregating parties, we may
have different aggregate routes with different set contents.  This would
permit the contributors to potentially get the aggregates.  For this to be
more useful than default or the contributors within the AS region being
aggregated... I can't quite picture the use case.

> but it is worth one sentence to note that the problem exists.

The history of why the feature was useful might be in the archives but if
so I didn't have the persistence to find it.  When you find a moment, it
might be helpful to talk about the the history of the feature for posterity.

-- Jeff

P.S. At the time I was becoming involved in BGP standards, the archives were
somewhat divided between Merit and, I think ANS?

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 05:55:42 -0400

> might be helpful to talk about the the history of the feature for posterity.

The issue was AS-X and AS-Y agree to aggregate a common set of
prefixes.  A classis example from the past was ANS and Internet-MCI
aggregating different parts of CANET and saving a few thousand more
specific prefixes.  AS-X and AS-Y aggregate and pass the aggregates to
each other, optionally also sending the more specifics, leaving out
prefixes learned from the other in the aggregate.  On the way out to
any other party, AS-X puts both AS-X and AS-Y in the AS_SET along with
all the AS that made up their AS_SET.  And AS-Y does the same.

In this example, ANS and Internet-MCI where protecting the aggregated
prefix from partition in addition to aggregating to the outside world.
CANET fractured into many smaller AS due to privatizing the national
network among a number of entities that now had different AS numbers.

That was probably the largest use of AS_SET although it was used
widely at the time (~1995).

The issue was that two AS were configured to aggregate the same
prefix, though neither had connectivity to the whole thing.  Getting
the config right and the AS_SET made sure that neither advertised an
aggregate based only on the aggregate learned from the other at
another peering.  The alternative was a few thousand prefixes that
would have been bad for some of the routers taking global routes at
the time.

This provided a protocol based protection that you don't include
someone else's aggregate of the same prefix as a result of a "drop all
AS and reoriginate as your own" rule.  A rule that allows only more
specifics in an aggregate also fixes this.

> somewhat divided between Merit and, I think ANS?

I don't know that BGP discussion was ever archived at ANS, but it
might have been archived at Merit.

Curtis

---

From: Geoff Huston <[email-masked]>
Date: Thu, 31 Mar 2011 22:27:46 +1100

> http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-02

agreed - please ship it.

  Geoff

---

From: "Stephen D. Strowes" <[email-masked]>
Date: Thu, 31 Mar 2011 13:34:26 +0200

+1

-S.

On Thu, 2011-03-31 at 03:40 +0100, Randy Bush wrote:
> yes, please
> 
> randy
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 08:36:32 -0400

I'm OK with shipping as is.  Sorry to top post.

Curtis

In message <1301571266.31409.5.camel@ikeq>
"Stephen D. Strowes" writes:

+1

-S.