Subject: [Idr] Fwd: New Version Notification for draft-wkumari-deprecate-as-sets-00

From: John Scudder <[email-masked]>
Date: Wed, 8 Sep 2010 13:29:03 -0700

[bcc to GROW mailing list]

Folks,

FYI.  I'd be interested in discussion of this topic.

For your clicking pleasure, http://tools.ietf.org/html/draft-wkumari-deprecate-as-sets-00

--John

Begin forwarded message:
> From: IETF I-D Submission Tool <[email-masked]>
> Date: August 31, 2010 9:26:21 PM EDT
> Subject: New Version Notification for draft-wkumari-deprecate-as-sets-00 
> 
> 
> A new version of I-D, draft-wkumari-deprecate-as-sets-00.txt has been successfully submitted by Warren Kumari and posted to the IETF repository.
> 
> Filename:	 draft-wkumari-deprecate-as-sets
> Revision:	 00
> Title:		 Deprecation of BGP AS_SET.
> Creation_date:	 2010-08-31
> WG ID:		 Independent Submission
> Number_of_pages: 10
> 
> Abstract:
> This document deprecates the use of the AS_SET type of the AS_PATH in
> BGPv4.  This is done to simply the design and implementation of the
> BGP protocol and to make the semantics of the originator of a route
> more clear.
> 
> 
> 
> The IETF Secretariat.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 8 Sep 2010 17:43:02 -0400

A bit of background:

In the SIDR WG we have been discussing AS_SETs and how they interact with the RPKI -- part of the issue is that it muddles the definition of what it means to originate a route (and what credentials the originator should use, etc).

While it should be possible to include special processing and rules that will deal with AS_SETs (like having multiple-signatures, assuming that the first AS_SEQUENCE in the path is the originator, etc.), this gets very messy and leads to poorly exercised code.

From looking at publicly available stores of default free zone routing data (routeviews/ ris / global bgp data, etc) it appears that AS_SETs that are correctly formed and contribute useful information are almost never used.

There are numerous paths that contain things like "1 2 3 {65534, 65533}" and / or "1 2 3 {3}" and similar, but very very few where the  AGGREGATOR did not match the AS next to (just left of) the AS_SET and further the ASN in the AGGREGATOR field was a non-private ASN.

There is a presentation from Sriram Kotikalapudi that breaks this down here: http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf

In fact, the only entry where the right-most AS-sequence entry did not match the aggregator and were not private that we could find was:
Prefix: 62.120.0.0/16
AS-Seq: 3549 8966 35819 34400
AS-Set 34400
Aggr: 35819 86.51.2.0

I believe that AS_SETs (and aggregation in general) was a great idea, but unfortunately in the real world they are not being used properly (and, because of business / political reasons are not likely to be used) and that the increase in complexity, etc. outweighs the decrease in table size....

W

On Sep 8, 2010, at 4:29 PM, John Scudder wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Tony Li <[email-masked]>
Date: Wed, 8 Sep 2010 18:15:47 -0700

Support.

Tony

On Sep 8, 2010, at 1:29 PM, John Scudder wrote:

> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Paul Jakma <[email-masked]>
Date: Mon, 13 Sep 2010 11:09:31 +0800 (CST)

> For your clicking pleasure, http://tools.ietf.org/html/draft-wkumari-deprecate-as-sets-00

While not disagreeing with the observations in the draft:

1. Acknowledging that many /public/ uses today aren't very
    helpful - without sets then /no/ BGP implementation can ever
    record AS traversal information without having to lie about path
    length.

2. How helpful is it to have a standalone draft deprecating AS_Sets?
    You can never rely on this draft generally being supported. It
    would perhaps be more usfeful for the SIDR work to not support
    AS_Sets - then it will always be true that SIDR implementations do
    not support sets.

On that basis, not support.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Every man thinks God is on his side.  The rich and powerful know that he is.
 		-- Jean Anouilh, "The Lark"

---

From: John Scudder <[email-masked]>
Date: Mon, 13 Sep 2010 08:08:02 -0700

A definition of "deprecate" may be useful.  Here's one, from http://www.thefreedictionary.com/deprecation

3. Computer Science: To mark (a component of a software standard) as obsolete to warn against its use in the future so that it may be phased out.

That's the sense being used in this case, IMO.

>    record AS traversal information without having to lie about path

I don't understand.  Can you elaborate/rephrase?

>    You can never rely on this draft generally being supported. It

Just thinking out loud here, but regarding "standalone draft", if the WG wanted to progress this I would expect the document status to be "updates RFC 4271".  Regarding "can never rely" I think the draft gets the general gist of "deprecates" right, which is to say a feature that is deprecated can be expected to continue working for some time into the future, but eventually after some extended period of deprecation may be moved to unsupported.  

So, progressing this draft or some related work would be the first step to eventually removing AS_SETs from the standard and possibly, from implementations.

>    AS_Sets - then it will always be true that SIDR implementations do

That is exactly why it seems to me as though it would be useful to deprecate AS_SETs.  Either they are a first-class part of the protocol, in which case we'd like extensions to support them, or they are on their way out, in which case it's OK for extensions not to be overly bothered with them.  The definition of "deprecate" I quoted above seems in line with what you describe here.

Essentially, if newer work on the protocol doesn't support AS_SETs, we are de-facto deprecating them.  Documenting this just seems like good hygiene.  

Regards,

--John

---

From: John Scudder <[email-masked]>
Date: Mon, 13 Sep 2010 08:13:37 -0700

I should also have pointed out that I don't mean to take a position right now regarding whether we should, or should not, deprecate AS_SETs.  I just want to point out what the consequences are.  To spell it out a little more completely, I think there are two internally-consistent approaches:

- Deprecate AS_SETs [*].  This allows new extensions to omit consideration of AS_SET support.
- Do not deprecate AS_SETs.  The logical consequence of this decision is that the WG wants new extensions to support AS_SETs.

IMHO,

--John

[*] Either as proposed in the current draft, or otherwise.

---

From: Enke Chen <[email-masked]>
Date: Mon, 13 Sep 2010 10:58:44 -0700

Hi, John:

While we are at it, we should deprecate the AS_SET_CONFED as well.

-- Enke

---

From: John Leslie <[email-masked]>
Date: Mon, 13 Sep 2010 14:24:43 -0400

John Scudder <[email-masked]> wrote:
> 
> A definition of "deprecate" may be useful.  Here's one, from
> http://www.thefreedictionary.com/deprecation
> 
> 3. Computer Science: To mark (a component of a software standard) as
> obsolete to warn against its use in the future so that it may be
> phased out.

   That's probably as good a definition as we can hope for... Nonetheless,
in practice, the phasing-out tends not to happen. :^(

>>    You can never rely on this draft generally being supported.
> 
> Just thinking out loud here, but regarding "standalone draft", if the
> WG wanted to progress this I would expect the document status to be
> "updates RFC 4271".

   Indeed, I'd guess Paul was expecting that too...

> Regarding "can never rely" I think the draft gets the general gist of
> "deprecates" right, which is to say a feature that is deprecated can
> be expected to continue working for some time into the future, but
> eventually after some extended period of deprecation may be moved to
> unsupported.  

   Emphasis on the "may". I don't necessarily expect to live that long.

> So, progressing this draft or some related work would be the first step
> to eventually removing AS_SETs from the standard and possibly, from
> implementations.

   This strikes me as overly optimistic.

   Shy of a way of _safely_ removing an AS-set from a path (have I
missed one? I see only "MAY quietly ignore updates" containing them.),
we're kind-of stuck with them until no existing router can generate
them.

   And, frankly, I'm not too happy with "MAY quietly ignore"...

>>    It would perhaps be more usfeful for the SIDR work to not support
> That is exactly why it seems to me as though it would be useful to
> deprecate AS_SETs.  Either they are a first-class part of the protocol,
> in which case we'd like extensions to support them, or they are on
> their way out, in which case it's OK for extensions not to be overly
> bothered with them

   I'm not sure the universe divides quite that cleanly.

   SIDR can quite reasonably say it can't validate paths containing
an AS-set -- after all, there are lots of things it can't validate.
And it's certainly reasonable to prefer routes which SIDR _can_
validate to routes it can't. For other kinds of extensions, the
tradeoffs would be quite different...

> Essentially, if newer work on the protocol doesn't support AS_SETs,
> we are de-facto deprecating them. Documenting this just seems like
> good hygiene.  

   Regardless, I believe all extensions will need to make statements
about what happens to AS-sets within an AS_PATH; and I'm nervous
about saying "quietly ignore" anything for an extension we haven't
even started to design.

--
John Leslie <[email-masked]>

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 13 Sep 2010 14:37:03 -0400

>   And, frankly, I'm not too happy with "MAY quietly ignore"...

how about: "Should not expect to be verified in the SIDR world' ?

One of the reasons for this draft (I think) is that in the SIDR world
it isn't obvious how you would verify or validate a route with an
AS_SET, even in the case of purely Origin-Validation only. Later on
I'd hope we can get to 'Origin + path' validation, in which case the
AS_SET is even more complicated :(

So, if SIDR doesn't have to address AS_SET, and the end result (in
origin only or origin+path) is a route marked (inside a router) as:
'validated', 'unvalidated', 'unknown' one with AS_SET will show as
'unknown'. Ideally this gets translated in your decision process (via
localpref/med/etc changes triggered from policy the operator controls)
into a less/more preferred route, where 2 routes of same path/prefix
length have different preferences, hopefully with the 'validated'
route preferred over unknown or unvalidated.

-Chris

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 13 Sep 2010 14:58:06 -0400

How should this point in section 9.2.2.2 rfc4271 be modified?

           - set the type of the rest of the tuples from the AS_PATH
             attributes of the routes to be aggregated to AS_SET, and
             append them to the aggregated AS_PATH attribute.

Appendix F.6. b) also needs modification:

         b) The aggregated AS_PATH attribute consists of ASes identified
            in (a), in exactly the same order as they appear in the
            AS_PATH attributes to be aggregated.  If two consecutive
            ASes identified in (a) do not immediately follow each other
            in both of the AS_PATH attributes to be aggregated, then the
            intervening ASes (ASes that are between the two consecutive
            ASes that are the same) in both attributes are combined into
            an AS_SET path segment that consists of the intervening ASes
            from both AS_PATH attributes.  This segment is then placed
            between the two consecutive ASes identified in (a) of the
            aggregated attribute.  If two consecutive ASes identified in
            (a) immediately follow each other in one attribute, but do
            not follow in another, then the intervening ASes of the
            latter are combined into an AS_SET path segment.  This
            segment is then placed between the two consecutive ASes
            identified in (a) of the aggregated attribute.

Should we simply say that routes that would produce AS_SETs if aggregated
should not be aggregated?

--
Jakob Heitz.

---

From: Ilya Varlashkin <[email-masked]>
Date: Mon, 13 Sep 2010 21:44:25 +0200

> how about: "Should not expect to be verified in the SIDR world' ?

This sounds much better than merely 'ignore'. Usually I'm both hands for not having things which are burden from one PoV or another, but in this case legacy of BGP seems to overweight deprecation. Removing AS-SET would require also modification of the description for ATOMIC_AGGREGATE.

> AS_SET is even more complicated :(

I think from verification perspective AS_SET should simply fail the check because it in its nature AS_SET is just that - a route that doesn't describe any particular network and was advertised in an attempt to reduce RIB size by a third-party. And if AS_SET check is permitted to fail (in SIDR context), then there is no technical reason to remove AS_SET from BGP specs. So if there's need to have a separate document concerning AS_SET, then it could just say as Chris suggested - "AS_SET SHOULD NOT be used by network operators", but this is already at the border with policies of various network operator groups rather than protocol specification.

/iLya

---

From: Ilya Varlashkin <[email-masked]>
Date: Mon, 13 Sep 2010 21:45:52 +0200

/iLya

---

From: Tony Li <[email-masked]>
Date: Mon, 13 Sep 2010 13:20:46 -0700

>   Emphasis on the "may". I don't necessarily expect to live that long.

This may be true (and even more true for some of us than others ;-), but we have to start somewhere.  Until we tell people to stop using AS_SET, then we have to continue to support it.  

It's obviously not helping, and was a bad idea.  Mea culpa.  Now, can we please bury it before we have to spend more on it?

Tony

---

From: Paul Jakma <[email-masked]>
Date: Tue, 14 Sep 2010 11:25:38 +0800 (CST)

> http://www.thefreedictionary.com/deprecation

I was aware, but thanks. :)

> I don't understand.  Can you elaborate/rephrase?

The only way at present to indicate a route may follow a number of 
paths, without adding to the path length (which obv. is a metric of 
significance in the protocol) is to use sets.

E.g. any BGP implementation which did ECMP on eBGP received routes 
would, to be safe, have to effectively advertise the route's path as 
an aggregrate of some kind. Either as:

   ME_{A,B,C,D}

or even, say if the paths ECMP was done over were, say, A_C and 
B_D and you wanted to preserve the length.

   ME_{A,B}_{C,D}

Now, there may be other extensions that allow this to be done in 
other ways (e.g. ADD_PATH), but to advertise such a route to a 
speaker lacking such an extension requires advertising one route 
whose path contains all the ASes. It's also not clear yet just how 
widely those extensions will be supported and exactly how they will 
be used.

Without sets, you can't do that without making the path length 
potentially a lot longer than it would be otherwise.

There may not be much inter-AS use of ECMP routes today, and so the 
use of sets today may be limited to ye olde BGP-layer prefix 
aggregation, however we might see ECMP in the future - and sets then 
at that point could be a useful transition mechanism.

> deprecate AS_SETs.  Either they are a first-class part of the 
> protocol, in which case we'd like extensions to support them, or 
> they are on their way out, in which case it's OK for extensions not 
> to be overly bothered with them.  The definition of "deprecate" I 
> quoted above seems in line with what you describe here.

We don't know whether or not sets will be useful.

Rather than try to guess at the future and prescribe what we think it 
should be, why not let the future write itself? If SIDR chooses not 
to support sets, and if SIDR becomes a must-have feature for 
operators then sets will be naturally deprecated. If that doesn't 
happen, it still allows for future uses of sets (e.g. transition 
compatibility for ECMP).

I'm thinking we should wait and see what happens first.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
No group of professionals meets except to conspire against the public at large.
 		-- Mark Twain

---

From: Tony Li <[email-masked]>
Date: Mon, 13 Sep 2010 21:36:28 -0700

> We don't know whether or not sets will be useful.

15 years of experience and scant usage is a pretty convincing argument that they are not.  

> Rather than try to guess at the future and prescribe what we think it should be, why not let the future write itself? If SIDR chooses not to support sets, and if SIDR becomes a must-have feature for operators then sets will be naturally deprecated. If that doesn't happen, it still allows for future uses of sets (e.g. transition compatibility for ECMP).
> 

If we take that approach, then the poor folks who do use AS_SETs will find out that the rest of the Internet can't/won't talk to them.  This would be a massive disservice.

Tony

---

From: Paul Jakma <[email-masked]>
Date: Tue, 14 Sep 2010 16:30:53 +0800 (CST)

> argument that they are not.

For routing protocol layer prefix aggregation, sure, that's not been 
a widely used feature, as the RFC documents. We may wish to aggregate 
routes in other ways in the future, in a BGP-4 compatible way, 
though..

> If we take that approach, then the poor folks who do use AS_SETs 
> will find out that the rest of the Internet can't/won't talk to 
> them.  This would be a massive disservice.

And they'll find out they won't be able to talk SIDR either. What's 
the problem, why not just let sleeping dogs lie? If we find the dog 
is dead when the next BGP update RFC is due, we can deal with it 
then.

I'd prefer we describe, not prescribe.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
A mushroom cloud has no silver lining.

---

From: Tony Li <[email-masked]>
Date: Tue, 14 Sep 2010 09:22:53 -0700

>> I'd prefer we describe, not prescribe.

Well, the whole point of writing standards is to be prescriptive: to comply with standard X you MUST do Y.

In any case, aren't we just being descriptive?  It's dead, Jim.

Tony

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 14 Sep 2010 14:56:45 -0400

> In any case, aren't we just being descriptive?  It's dead, Jim.

it seems to me that the use case Paul's bringing up (odd ebgp ecmp
marking of aggregation) isn't something that AS_SET's should describe
(it looks like Paul wants to mark what paths were used to exit your
ASN in a multipath scenario, NOT 'this prefix is an aggregate of
bunches seen from these X, Y, Z asns downstream of me), nor is it
something possible today.

This sort of thing will cause overload of the original AS_SET use,
that will be bad. If we want something else there ought to be a new
attribute, not re-use something else for that purpose.

-Chris
(aka, pls kill as-set)

---

From: Steve Padgett <[email-masked]>
Date: Tue, 14 Sep 2010 12:44:47 -0700

I agree.  We haven't found a good use for AS SETs in the last 15 years
(obvious by their lack of use), and we have a good use case for why
they're harmful in the continued development in SIDR -- so I support
their deprecation.

Steve

---

From: Ilya Varlashkin <[email-masked]>
Date: Tue, 14 Sep 2010 22:50:10 +0200

> they're harmful in the continued development in SIDR -- so I support

I don't think it's a good idea to deprecate anything that is still in use. According to the draft's report, there are AS_SETs in the public table (and although unlikely, might be still in private tables too). Until that AS_SET actually disappears it doesn't seem as a good idea to mark AS_SET as gone. I would suggest first to convince people who currently inject AS_SET to stop doing this, then we could progress with the draft. Until then it's too harsh to remove AS_SET support from the protocol. So for now I do not support the draft, but as soon as the last AS_SET disappears from the global table I will support it.

/iLya

---

From: John Scudder <[email-masked]>
Date: Tue, 14 Sep 2010 13:58:09 -0700

> I don't think it's a good idea to deprecate anything that is still in use. According to the draft's report, there are AS_SETs in the public table (and although unlikely, might be still in private t…

Actually what you have described is basically "deprecation".  See the definition I sent earlier.  In effect, marking a feature "deprecated" is a way of discouraging its use without actually removing it from the protocol (yet).

--John

---

From: Tony Li <[email-masked]>
Date: Tue, 14 Sep 2010 14:02:51 -0700

> I don't think it's a good idea to deprecate anything that is still in use. According to the draft's report, there are AS_SETs in the public table (and although unlikely, might be still in private t…

Until we deprecate it, then how do you justify people moving off of it?

Chicken and egg.  ;-)

Tony

---

From: Paul Jakma <[email-masked]>
Date: Wed, 15 Sep 2010 05:09:02 +0800 (CST)

On Tue, 14 Sep 2010, Christopher Morrow wrote:

> marking of aggregation) isn't something that AS_SET's should 
> describe (it looks like Paul wants to mark what paths were used to 
> exit your ASN in a multipath scenario, NOT 'this prefix is an 
> aggregate of bunches seen from these X, Y, Z asns downstream of 
> me), nor is it something possible today.
>

It's not overloading, it's a class of aggregation. Aggregated paths 
MUST contain all the traversed ASes in their AS_PATH for loop 
detection, if they are to be compatible with plain BGP-4 speakers. If 
you deprecate sets you no longer have a way to introduce ECMP paths 
in the future in a backwards-compatible way.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Ok, I'm just uploading the new version of the kernel, v1.3.33, also
known as "the buggiest kernel ever".
 	-- Linus Torvalds

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 14 Sep 2010 19:46:57 -0400

Agree with Tony.
To your knowledge - does anyone (non vendor) actually use AS_SET and has practical reasons to keep it?

Regards,
Jeff  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Tuesday, September 14, 2010 14:03
To: Ilya Varlashkin
Cc: [email-masked] List
Subject: Re: [Idr] Fwd: New Version Notification for draft-wkumari-deprecate-as-sets-00

Chicken and egg.  ;-)

Tony

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Sep 2010 06:52:19 +0000

>   consideration of AS_SET support.

Deprecation is not quite sufficient for that.  It may not be necessary
to have on-the-wire protocol support, but you still need to deal with
path attributes containing AS_SETs and what to do about them.

If you want to avoid the latter, you need something far more drastic.
You basically need to inhibit propagation of AS_SETs in the Internet
core.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: "t.petch" <[email-masked]>
Date: Wed, 15 Sep 2010 12:08:37 +0200

----- Original Message -----
From: "Christopher Morrow" <[email-masked]>
To: "Tony Li" <[email-masked]>
Cc: <[email-masked]>; "Paul Jakma" <[email-masked]>
Sent: Tuesday, September 14, 2010 8:56 PM

<tp>

I agree. This is 'AS_SET Considered Harmful' (which they are,
at least from the point of view of the amount of effort consumed in sidr as
a result of them).

Let's get rid of them quickly, before any does find an unintended
use for them

Tom Petch
</tp>

-Chris
(aka, pls kill as-set)

---

From: John Leslie <[email-masked]>
Date: Wed, 15 Sep 2010 10:25:46 -0400

> You basically need to inhibit propagation of AS_SETs in the Internet

   +1

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Sep 2010 17:59:25 +0000

> For your clicking pleasure, http://tools.ietf.org/html/draft-wkumari-deprecate-as-sets-00

Comments in semi-random order:

[SIDR and sets]
As I remarked at last IETF in SIDR, yes, sets suck for SIDR purposes.  I
also remarked that I would expect that SIDR shouldn't bother to deal with
routes that have sets in them.  I'm sort of shocked that we're wasting this
much time worrying about it.

That said, the hack presented in SIDR looked like it worked for the cases
where one would want to deal with sets.

[Sets as an prefix aggregation feature]
The bulk of the Internet setttled on the Cisco-style "brief" aggregation a
long time ago.  That behavior ended up in RFC 4271.  I.e. instead of
generating a set, the path is truncated.  Some of the comments (and Andrew
may have them in his massive history draft) regarding sets during 4271
standardization were that they had some rather annoying properties:

 - Contributor flapping can cause churn in the path by churning set members.
   Churn == bad.
 - Contributors to the aggregate by definition can't get the aggregate due
   to membership in the set and AS_PATH loop detection.  They're expected to
   get all of the most specifics.

When brief aggregation is done by a prefix holder, say a Tier-N ISP who is
delegating address space to customers, no harm is done by excluding the
customer AS numbers from the aggregate path.  The presumption is that the
ISP is providing reachability to all members of the aggregate.  For SIDR
purposes, this would also likely match the case where the ISP "owns" the
prefix and would be expected to be the origin AS anyway.

The more interesting case is when more specific address space walks away and
is no longer serviced by the aggregate.  I think most people believe this is
in the "too bad" case.  It does, however, result in the holder of the less
specific getting noise traffic for the more specific.

[Sets and proxy aggregation]
In general, when people proxy aggregate, they don't send those aggregates
out into the net at large.  A somewhat historical example was 12/8 and the
cablecos.  For a while, the 12/8 space was very noisy and reputedly some
providers simply aggregated them at the edges and suppressed the more
specifics.

A consequence of deprecating the set feature would be to deprecate internal
proxy aggregation.  Providers who do this for their own reasons should pay
attention.

For SIDR purposes, no one would ever expect these routes to externally
validate anyway.

[BGP ECMP]
The topic gets attention once in a blue moon.  Consensus is that it's safe
to do when the AS_PATHs are identical.  Vendors permit ECMP when the paths
aren't identical, which is fine as long as the contributing paths are not
propagated externally.  Nothing controls this from happening besides policy
and there's no standardized operational guidance that I'm aware of regarding
this. 

E.g. if you use a given BGP route as contributor to ECMP and permit
non-identical paths, it should be marked as NO_EXPORT.

Failure to do something like this may result in forwarding loops.

One (currently) deployable solution to address this is to aggregate the
contributing AS_PATHs.  

Add-path is getting a lot more attention and one desired use for it involves
eBGP ECMP.  This will exacerbate this scenario.  This is partially why my
comment in SIDR was that "complex aggregation" may be required.

For SIDR purposes, such a complex aggregated path may still be verifiable.
Or at least it could until we decide we want to validate AS_PATH AS
adjacencies.

------

I didn't think we're to the point of voting to adopt this as a WG draft.  If
we were, my vote would currently be no.  The "this makes it easier for SIDR"
case is too weak IMO.  SIDR should just say "we are not going to consider
these routes valid" and go from there.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Sep 2010 18:16:56 +0000

[Correcting myself before someone else does.]

> [Sets and proxy aggregation]
[...]

> proxy aggregation.  Providers who do this for their own reasons should pay

... deprecate internal proxy aggregation resulting in AS_SETs.

Such proxy aggregates automatically get suppressed by the contributing ASes
due to BGP loop detection.  "brief" aggregation does not do this.

-- Jeff

---

From: John Scudder <[email-masked]>
Date: Wed, 15 Sep 2010 11:17:42 -0700

> path attributes containing AS_SETs and what to do about them.

I was insufficiently precise.  What I meant was that if AS_SETs are deprecated, IMO it would be OK for new work (for example, the SIDR stuff) to deal with AS_SETs in the easiest possible way, for example in the SIDR case by simply saying that such paths can't be evaluated and thus will never be considered "valid". 

> You basically need to inhibit propagation of AS_SETs in the Internet

Yes, it would be foolish for an extension to have some ugly failure mode in the face of AS_SETs, for the foreseeable future.

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Sep 2010 18:28:45 +0000

> I was insufficiently precise.  What I meant was that if AS_SETs are deprecated, IMO it would be OK for new work (for example, the SIDR stuff) to deal with AS_SETs in the easiest possible way, for e…

*That* proposal I can get behind 100%.

Guidance to operators for SIDR purposes would roughly be "when you need to
aggregate BGP routes for a less specific that is part of your address space,
always use brief aggregation rules".

-- Jeff

---

From: Ilya Varlashkin <[email-masked]>
Date: Wed, 15 Sep 2010 21:12:14 +0200

> *That* proposal I can get behind 100%.

I support this approach too.

/iLya

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Sep 2010 16:08:29 -0400

> I support this approach too.

hurray! consensus-ish! I guess the language in the doc should be more
precise then? something like removing the chatter about SIDR, and just
"These are no longer used widely, the actual usage is flawed and for
complexity reasons it seems worthwhile to simply deprecate AS_SET in
AS_PATH" ??

-Chris

---

From: Ilya Varlashkin <[email-masked]>
Date: Wed, 15 Sep 2010 22:24:45 +0200

> complexity reasons it seems worthwhile to simply deprecate AS_SET in

Just need to make it clear in wording that new work doesn't have to support AS_SET, but it's not ok to remove recognition of AS_SET in ordinary implementations for as long as there are AS_SETs in use while operators should put an effort to getting rid of AS_SETs from the AS_PATH.

/iLya

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Sep 2010 16:42:17 -0400

> Just need to make it clear in wording that new work doesn't have to support AS_SET, but it's not ok to remove recognition of AS_SET in ordinary implementations for as long as there are AS_SETs in u…

ah, gotcha. thanks!
-chris

---

From: Paul Jakma <[email-masked]>
Date: Thu, 16 Sep 2010 16:14:23 +0100 (BST)

On Wed, 15 Sep 2010, Ilya Varlashkin wrote:

>> hurray! consensus-ish! I guess the language in the doc should be 
>> more precise then? something like removing the chatter about SIDR, 
>> and just "These are no longer used widely, the actual usage is 
>> flawed and for complexity reasons it seems worthwhile to simply 
>> deprecate AS_SET in AS_PATH" ??
>>

> Just need to make it clear in wording that new work doesn't have to 
> support AS_SET, but it's not ok to remove recognition of AS_SET in 
> ordinary implementations for as long as there are AS_SETs in use 
> while operators should put an effort to getting rid of AS_SETs from 
> the AS_PATH.

I'd support a "new BGP extensions need not support AS-sets" draft 
too, as long as we leave it alone in the core BGP protocol for now. 
If that wasn't clear already. ;)

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
furbling, v.:
 	Having to wander through a maze of ropes at an airport or bank
 	even when you are the only person in line.
 		-- Rich Hall, "Sniglets"

---

From: Danny McPherson <[email-masked]>
Date: Thu, 16 Sep 2010 18:01:30 -0400

> *That* proposal I can get behind 100%.

Me too..

I would also like to echo Enke's comment about AS_CONFED_SET 
being denoted as well.  I know the motivations of the draft are only 
concerned with SIDR but I'd prefer to address all cases of AS*SET.

-danny

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Sep 2010 17:58:14 -0400

On Sep 16, 2010, at 6:01 PM, Danny McPherson wrote:

>>> I was insufficiently precise.  What I meant was that if AS_SETs  
>>> are deprecated, IMO it would be OK for new work (for example, the  
>>> SIDR stuff) to deal with AS_SETs in the easiest possible way, for  
>>> example in the SIDR case by simply saying that such paths can't be  
>>> evaluated and thus will never be considered "valid".
>>

Cool -- and I'm *assuming* that you are also OK with text suggesting  
that operators not perform aggregation that results in the generation  
of AS_SETs, because they might not be considered valid by new work?
Basically rewriting section 3 and dropping the "Over time BGP  
implementations MAY no longer support generating them, and eventually  
implementations MAY quietly ignore updates with AS_SETs in them."  
sentence...

That way, in a few years time there won't be any AS_SETs and we can  
readdress the dumping them altogether?

> concerned with SIDR but I'd prefer to address all cases of AS*SET.

Actually, the motivations of the draft were not only concerned with  
SIDR -- SIDR was supposed to be just an example of a technology where  
AS_SETs cause issue -- I realize that I did an incredibly poor job of  
explaining that though :-).

I will happily mumble about AS_CONFED_SETs, I wanted to first see just  
how much pain I was opening myself to with just mentioning AS_SETs :-P

W

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire,  
and he'll be warm for the rest of his life." -- Terry Pratchett

---

From: Danny McPherson <[email-masked]>
Date: Sat, 18 Sep 2010 09:43:28 -0400

On Sep 17, 2010, at 5:58 PM, Warren Kumari wrote:

> 
> Cool -- and I'm *assuming* that you are also OK with text suggesting that operators not perform aggregation that results in the generation of AS_SETs, because they might not be considered valid by new work?
> Basically rewriting section 3 and dropping the "Over time BGP implementations MAY no longer support generating them, and eventually implementations MAY quietly ignore updates with AS_SETs in them." sentence...
> 
> That way, in a few years time there won't be any AS_SETs and we can readdress the dumping them altogether?

Yes, as you may recall, that was my chief concern expressed in SIDR and beyond regarding deprecation.  We need to give folks that are using AS_SETs an incentive to justify investing in changing their current [standards-compliant] configurations, we can't just do things that break their connectivity.  

-danny

---

From: Paul Jakma <[email-masked]>
Date: Tue, 21 Sep 2010 12:59:37 +0100 (BST)

On Fri, 17 Sep 2010, Warren Kumari wrote:

> implementations MAY no longer support generating them, and 
> eventually implementations MAY quietly ignore updates with AS_SETs 
> in them." sentence...

Urg no. Why do that?

If implementations want to not generate sets, or if new extensions 
choose to not work with sets (but still, fail gracefully), that's one 
thing.

Why however gratuitously break people's routes just cause their 
implementations havn't updated to some post-BGP-4 RFC? Creating hard 
to notice and hard to fix problems for people. It's needless, don't 
put such language in please.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Heavier than air flying machines are impossible.
 		-- Lord Kelvin, President, Royal Society, c. 1895

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 21 Sep 2010 09:24:46 -0400

On Tue, Sep 21, 2010 at 7:59 AM, Paul Jakma <[email-masked]> wrote:
> If implementations want to not generate sets, or if new extensions choose to
> not work with sets (but still, fail gracefully), that's one thing.

'fail gracefully' in the sense of SIDR is most likely: "Your route can
not be validated/verified/crypto-happy, so it got dropped." (maybe it
gets dropped, maybe it gets down pref'd in another way, this part
isn't clear and looks to be operator selectable)

Is that 'graceful'? If so, how is that different from just not
accepting a route with an AS_SET ?

> implementations havn't updated to some post-BGP-4 RFC? Creating hard to
> notice and hard to fix problems for people. It's needless, don't put such
> language in please.
>
> regards,
> --

---

From: Paul Jakma <[email-masked]>
Date: Tue, 21 Sep 2010 14:35:16 +0100 (BST)

> accepting a route with an AS_SET ?

If you have a good reason, such as "My policy is to only accept 
routes I can validate with SIDR", then dropping it is not gratuitous. 
(Note that you could have SIDR but still accept unvalidated routes).

That's different from issuing a document to tell implementations to 
drop routes just cause they use sets.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Help!  I'm trapped in a Chinese computer factory!

---

From: John Leslie <[email-masked]>
Date: Tue, 21 Sep 2010 09:56:56 -0400

Christopher Morrow <[email-masked]> wrote:
>> choose to not work with sets (but still, fail gracefully), that's
>> one thing.
> 

   There's a big difference between dropped and down-pref'd. Drop is
very likely to get something black-holed.

> accepting a route with an AS_SET ?

   We want to retain reachability, despite sometimes very-limited-trust
in our peers or their peers. It's one thing to decide we know a "safer"
path; it's quite another to say we'll blackhole because we don't like
what some peer of a peer did -- which nonetheless is 100% compliant
with the appropriate RFCs at the time that implementation was written.

   "Be lenient in what you accept" is _very_ necessary here.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 21 Sep 2010 10:14:12 -0400

>   "Be lenient in what you accept" is _very_ necessary here.

yup, just looking for more consensus and documentation from folk
picking a direction.

thanks (to paul as well)
-chris

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Tue, 21 Sep 2010 16:23:42 +0200

> yup, just looking for more consensus and documentation from 
> folk picking a direction.
> 

I had impression that few posts earlier we have reached consensus that: 1) yes, it's ok to skip support for AS_SET in new features, but 2) it's not ok to drop AS_SET support in legacy BGP stuff as long as there are still AS_SETs advertised by anyone on the internet, and 3) from now on network operators are encouraged to stop announcing AS_SETs

/iLya

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Sep 2010 14:45:04 +0000

> very likely to get something black-holed.

Let me remind everyone that the Internet is a network of consenting adults
who choose what to accept and what not to accept.  People discard
reachability all the time.  For example, a favorite policy is "ignore
anything longer than /24".  If there's not an aggregate available, then
blackholing will occur.

Similarly, people might prefer to announce an aggregate and suppress more
specifics of any network in attempt to provide a weak attractor to those
networks covered by the aggregate.

You're absolutely right though - people can get blackholed if you suppress
anything.  But it's not the responsibility of every network to provide
transit to everyone.  BGP is mostly about policy.  Policy is mostly about
money.

(All IMO)

-- Jeff

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 21 Sep 2010 12:48:53 -0400

An alternative to dropping:
Reserve an AS number that means: this AS number replaces an AS_SET.
Whenever a "new" router receives an aspath with AS_SET's it will remove
each AS_SET and put one of these reserved AS numbers in its place.
That way, the as path length is preserved.

--
Jakob Heitz.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 21 Sep 2010 18:04:37 +0100 (BST)

> An alternative to dropping:

Let's just keep it simple.

Let future work on BGP extensions choose to not support sets (to 
whatever extent), if that's decided to be for the best. If that 
requires a doc from IDR to say that BGP implementations SHOULD try to 
avoid generating sets, fair enough.

Let's not go further than that for now - there's no need, there's no 
hurry.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Acceptance testing:
 	An unsuccessful attempt to find bugs.

---

From: Ilya Varlashkin <[email-masked]>
Date: Tue, 21 Sep 2010 21:43:03 +0200

On Sep 21, 2010, at 19:04 , Paul Jakma wrote:

> Let future work on BGP extensions choose to not support sets (to whatever extent), if that's decided to be for the best. If that requires a doc from IDR to say that BGP implementations SHOULD try to avoid generating sets, fair enough.
> 
> Let's not go further than that for now - there's no need, there's no hurry.
> 

+1

/iLya

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Sep 2010 08:56:50 -0400

Posted a new version -- I'm hoping that the wording of this batter captures what people are looking for...

Filename:	 draft-wkumari-deprecate-as-sets
Revision:	 01
Title:		 Deprecation of BGP AS_SET, AS_CONFED_SET.
Creation_date:	 2010-09-19
WG ID:		 Independent Submission
Number_of_pages: 11

Abstract:
This document deprecates the use of the AS_SET and AS_CONFED_SET
types of the AS_PATH in BGPv4.  This is done to simplify the design
and implementation of the BGP protocol and to make the semantics of
the originator of a route more clear.

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

Would y'all mind letting more know if this is more acceptable?

W

---

From: Tony Li <[email-masked]>
Date: Thu, 23 Sep 2010 09:01:47 -0400

Works for me.

Tony

---

From: Paul Jakma <[email-masked]>
Date: Thu, 23 Sep 2010 17:39:10 +0100 (BST)

> captures what people are looking for...

No objections.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
"There is nothing new under the sun, but there are lots of old things
  we don't know yet."
  -Ambrose Bierce

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 23 Sep 2010 13:53:06 -0400

Looks good!

Regards,
Jeff  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Thursday, September 23, 2010 05:57
To: Ilya Varlashkin
Cc: John Leslie; [email-masked]
Subject: Re: [Idr] Fwd: New Version Notification fordraft-wkumari-deprecate-as-sets-00

Abstract:

W

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Sep 2010 17:03:21 -0400

YAY! Thanks :-)

W
On Sep 23, 2010, at 1:53 PM, Jeff Tantsura wrote:

>> I had impression that few posts earlier we have reached consensus  
>> that: 1) yes, it's ok to skip support for AS_SET in new features,  
>> but 2) it's not ok to drop AS_SET support in legacy BGP stuff as  
>> long as there are still AS_SETs advertised by anyone on the  
>> internet, and 3) from now on network operators are encouraged to  
>> stop announcing AS_SETs
>>
>> /iLya

--
"I think perhaps the most important problem is that we are trying to  
understand the fundamental workings of the universe via a language  
devised for telling one another when the best fruit is." --Terry  
Prachett

---

From: Warren Kumari <[email-masked]>
Date: Fri, 24 Sep 2010 11:05:08 -0400

> Would y'all mind letting more know if this is more acceptable?

So, it seems as though I have addressed the concerns of the folk who  
were unhappy with the original version, and that this version is much  
cleaner; thank you everyone for your review, support, input, etc.

I would like to get the group's view on having this become a WG item  
-- it does say that future BGP work *might* not support paths that  
contain AS_*SET, and so this looks to be the right venue for the work...

Thanks again for your time and consideration,
W

--
After you'd known Christine for any length of time, you found yourself  
fighting a desire to look into her ear to see if you could spot  
daylight coming the other way.

     -- (Terry Pratchett, Maskerade)t

---

From: Tony Li <[email-masked]>
Date: Fri, 24 Sep 2010 08:32:10 -0700

> I would like to get the group's view on having this become a WG item -- it does say that future BGP work *might* not support paths that contain AS_*SET, and so this looks to be the right venue for the work...

In favor.

Tony

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 27 Sep 2010 10:32:29 -0400

On Fri, Sep 24, 2010 at 11:05 AM, Warren Kumari <[email-masked]> wrote:
> So, it seems as though I have addressed the concerns of the folk who were
> unhappy with the original version, and that this version is much cleaner;
> thank you everyone for your review, support, input, etc.
>
> I would like to get the group's view on having this become a WG item -- it

this got hidden in my mail, i support this being on IDR's plate of
things to do :)

Thanks!
-Chris

> does say that future BGP work *might* not support paths that contain
> AS_*SET, and so this looks to be the right venue for the work...
>
>>> I had impression that few posts earlier we have reached consensus that:
>>> 1) yes, it's ok to skip support for AS_SET in new features, but 2) it's not
>>> ok to drop AS_SET support in legacy BGP stuff as long as there are still
>>> AS_SETs advertised by anyone on the internet, and 3) from now on network
>>> operators are encouraged to stop announcing AS_SETs
>>>
>>> /iLya
> fighting a desire to look into her ear to see if you could spot daylight
> coming the other way.
>

---

From: Keyur Patel <[email-masked]>
Date: Mon, 27 Sep 2010 13:34:16 -0700

> I would like to get the group's view on having this become a WG item -- 
> it does say that future BGP work *might* not support paths that contain 

Support.

-Keyur

---

From: [email-masked]
Date: Tue, 28 Sep 2010 14:13:20 +0000

Support.

-jim
Sent from my BlackBerry device on the Rogers Wireless Network