Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Dec 2010 12:10:46 -0500

From the lack of slings and arrows, I'm going to have to assume that this document is just *perfect* and cannot be improved at all....

Go, prove me wrong (please?)

W

On Nov 19, 2010, at 11:26 AM, Warren Kumari wrote:

> Hi all,
> 
> Now that the submission window has reopened, I have posted draft-ietf-idr-deprecate-as-sets-00 (nee draft-wkumari-deprecate-as_sets).
> 
> This draft already has comment from multiple folk incorporated, but could still do with some work, and hopefully a bit of strengthening of the language / recommendation.
> 
> Anyway, please take another look (because I'm sure that, having just gotten back from Beijing, reading yet another draft sounds like a barrel of fun) and send comments, or better yet, text :-p
> 
> W
> 
> 
> ------
> A new version of I-D, draft-ietf-idr-deprecate-as-sets-00.txt has been successfully submitted by Warren Kumari and posted to the IETF repository.
> 
> Filename:	 draft-ietf-idr-deprecate-as-sets
> Revision:	 00
> Title:		 Deprecation of BGP AS_SET, AS_CONFED_SET.
> Creation_date:	 2010-11-18
> WG ID:		 idr
> Number_of_pages: 5
> 
> 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.

---

From: "t.petch" <[email-masked]>
Date: Wed, 8 Dec 2010 10:16:56 +0100

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "Warren Kumari" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 07, 2010 6:10 PM
Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00

> From the lack of slings and arrows, I'm going to have to assume that this
document is just *perfect* and cannot be improved at all....
> Go, prove me wrong (please?)

Easy peasy

"The reductions  ...  is outweighed "

"Deprecate:  To mark ...  as obsolete"
**disagree obsolete and deprecate are quite different and I think deprecate
correct here (but see below).

"RPKI"
** not expanded, explained or referenced, nor mentioned in the introduction.
For me, RPKI is the driving force for this I-D - I know of no other reason for
it to exist so more is needed here.

"simplified..  "

Is there an exposure from systems that will refuse to process AS-SET when
receiving one, eg a black hole?  I don't know, but think it needs exploring.

And, just what is being recommended?  Deprecate is a weasel word and I think
needs elucidating ie spell out whatever it is we are recommending.  I take it as
do not generate any new AS_SET and look to eliminate any that are currently
being generated, but think that that needs saying explicitly.

Tom Petch

> > Now that the submission window has reopened, I have posted
draft-ietf-idr-deprecate-as-sets-00 (nee draft-wkumari-deprecate-as_sets).
> >
> > This draft already has comment from multiple folk incorporated, but could
still do with some work, and hopefully a bit of strengthening of the language /
recommendation.
> >
> > Anyway, please take another look (because I'm sure that, having just gotten
back from Beijing, reading yet another draft sounds like a barrel of fun) and
send comments, or better yet, text :-p
> >
> > W
> >
> >
> > ------
> > A new version of I-D, draft-ietf-idr-deprecate-as-sets-00.txt has been
successfully submitted by Warren Kumari and posted to the IETF repository.
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Dec 2010 17:08:14 -0500

>> Go, prove me wrong (please?)

Doh. I said that I'd get to soon, but, well, I didn't.... Sorry.

> "The reductions  ...  is outweighed "

Good catch. Done.

> correct here (but see below).

Yes, I agree. This is horrid, but I wasn't able to find a better definition of "deprecate" anywhere... 
I have spent a while looking at various definitions and have munged a few of them together into one :-)
Hopefully this is a reasonable, otherwise, if you happen to be able to wordsmith a better one I'd really appreciate it.

> ** not expanded, explained or referenced, nor mentioned in the introduction.

Bah! I didn't want to have the document held up while waiting for draft-ietf-sidr-arch-11 (or similar) to be published, so I tossed in "RPKI", intending to find a good reference before posting it, but then forgot... 

I have reworded things to avoid using the term RPKI, hopefully this is still specific enough.

> it to exist so more is needed here.

While RPKI is the reason closest to my heart as well, it is not the only reason -- AS_SETs have caused both confusion and issues, for example:
http://www.merit.edu/mail.archives/nanog/msg14479.html

This is (IMO) both because the code is not well exercised and because the relevant bits of the RFC are, um, confusing. AS_SETs also seem to cause confusion to many operators -- if I see:
*> 192.0.2.0/24     1  12  22  9  6 i
I know exactly who to talk to about issues with 192.0.2.0. If I see:
*> 192.0.2.0/24     1 12 {22 9 6} i
who should I talk to? AS12? AS6? All of them, none of them?

And what exactly does AS_PATH 3561 3356 9031 {35821,35821,35821,35821} i mean? (http://www.gossamer-threads.com/lists/cisco/nsp/137647?do=post_view_threaded_

> "simplified..  "

Done.

> receiving one, eg a black hole?  I don't know, but think it needs exploring.

If someone is announcing an aggregate containing an AS_SET, and is not announcing the more specifics as well, then yes, this could happen -- I have not been able to find any cases of this though. I guess it is also possible that a more specific could go away, and the aggregator may have some backdoor route to a contributor, but a: this is getting into the pathological and b: we are advising folk to stop generating these anyway :-P

> being generated, but think that that needs saying explicitly.

Yup, that is it exactly. I have attempted to demustelate it -- I would like to make it even stronger[0], but think that this is now explicit enough, you?

W

[0]: Like "Warning: AS_SETs and AS_CONFED_SETs are going away. Please stop announcing them or some chappie with a big bat will come knocking..."

---

From: "t.petch" <[email-masked]>
Date: Thu, 30 Dec 2010 18:37:13 +0100

Warren

Top posting on deprecate since that seems the fuzzy issue.

I also work in network management, and so take for granted statements such as
" The value "current" means that the definition is current and valid.
   The value "obsolete" means the definition is obsolete and should not
   be implemented and/or can be removed if previously implemented.
   While the value "deprecated" also indicates an obsolete definition,
   it permits new/continued implementation in order to foster
   interoperability with older/existing implementations."

from SMIv2 [RFC2578] and which is almost unchanged in YANG [RFC6020]

"The "status" statement takes as an argument one of the strings
   "current", "deprecated", or "obsolete".

   o  "current" means that the definition is current and valid.

   o  "deprecated" indicates an obsolete definition, but it permits new/
      continued implementation in order to foster interoperability with
      older/existing implementations.

   o  "obsolete" means the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations."

I have always taken this to be IETF-wide so that when RFC4271 uses
'deprecated' without explanation, everyone knows what is meant.  As
such, I would suggest not including any definition thereof. If it is good enough
for RFC4271, .....

But I would still include explicit sentences along the lines of 'do not generate
any new ones, and stop using existing ones as soon as you can'

Tom Petch

ps you could include a reference to maidens praying, but that is probably
too much an SNMP in-joke.

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Warren Kumari" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 29, 2010 11:08 PM
Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00

Good catch. Done.

> correct here (but see below).

Yes, I agree. This is horrid, but I wasn't able to find a better definition of
"deprecate" anywhere...
I have spent a while looking at various definitions and have munged a few of
them together into one :-)
Hopefully this is a reasonable, otherwise, if you happen to be able to wordsmith
a better one I'd really appreciate it.

> ** not expanded, explained or referenced, nor mentioned in the introduction.

Bah! I didn't want to have the document held up while waiting for
draft-ietf-sidr-arch-11 (or similar) to be published, so I tossed in "RPKI",
intending to find a good reference before posting it, but then forgot...

I have reworded things to avoid using the term RPKI, hopefully this is still
specific enough.

> it to exist so more is needed here.

While RPKI is the reason closest to my heart as well, it is not the only
reason -- AS_SETs have caused both confusion and issues, for example:
http://www.merit.edu/mail.archives/nanog/msg14479.html

This is (IMO) both because the code is not well exercised and because the
relevant bits of the RFC are, um, confusing. AS_SETs also seem to cause
confusion to many operators -- if I see:
*> 192.0.2.0/24     1  12  22  9  6 i
I know exactly who to talk to about issues with 192.0.2.0. If I see:
*> 192.0.2.0/24     1 12 {22 9 6} i
who should I talk to? AS12? AS6? All of them, none of them?

And what exactly does AS_PATH 3561 3356 9031 {35821,35821,35821,35821} i mean?
(http://www.gossamer-threads.com/lists/cisco/nsp/137647?do=post_view_threaded_

Done.

> receiving one, eg a black hole?  I don't know, but think it needs exploring.

If someone is announcing an aggregate containing an AS_SET, and is not
announcing the more specifics as well, then yes, this could happen -- I have not
been able to find any cases of this though. I guess it is also possible that a
more specific could go away, and the aggregator may have some backdoor route to
a contributor, but a: this is getting into the pathological and b: we are
advising folk to stop generating these anyway :-P

> being generated, but think that that needs saying explicitly.

Yup, that is it exactly. I have attempted to demustelate it -- I would like to
make it even stronger[0], but think that this is now explicit enough, you?

W

[0]: Like "Warning: AS_SETs and AS_CONFED_SETs are going away. Please stop
announcing them or some chappie with a big bat will come knocking..."