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

From: Warren Kumari <[email-masked]>
Date: Sun, 16 Jan 2011 10:28:07 -0500

On Dec 30, 2010, at 12:37 PM, t.petch wrote:

> 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, .....

Cool, done!

> 
> 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'

Version -01 included some strengthened text, but I've just posted -02.
Please have a look and let me know if you think this is the correct strength -- it's basically what you provided, but reworded slightly to be a little more "formal".

W

> 
> 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
> 
> 
> 
> On Dec 8, 2010, at 4:16 AM, t.petch wrote:
> 
>> ----- 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
> 
> Doh. I said that I'd get to soon, but, well, I didn't.... Sorry.
> 
>> 
>> "The reductions  ...  is outweighed "
> 
> Good catch. Done.
> 
>> 
>> "Deprecate:  To mark ...  as obsolete"
>> **disagree obsolete and deprecate are quite different and I think deprecate
>> 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.
> 
> 
>> "RPKI"
>> ** 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.
> 
>> 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.
> 
> 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.
> 
>> 
>> 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.
> 
> 
> 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
> 
> 
>> 
>> 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.
> 
> 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..."
> 
>> 
>> Tom Petch
>> 
>>> 
>>> 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.
>>> 
>>> _______________________________________________
>>> Idr mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/idr
>> 
>

---

From: "t.petch" <[email-masked]>
Date: Mon, 17 Jan 2011 14:50:02 +0100

Should this I-D update RFC4271?

I first thought 'Yes it does' but then thought some more, that RFC4271 is the 
protocol and this is how to use the protocol, operations, a grow-ey sort of
thing, so it should not.

But then I thought, how will anyone know it exists? Having it as an update
to RFC4271 would flag to any user of the rfc-index that this is something
they should read, so for political rather than technical reasons, it would be
good to have it update RFC4271.  But then this is Informational so 
perhaps it can't.

Thoughts?

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Mon, 17 Jan 2011 14:55:08 +0100

Looks good to me.

I thought briefly that the language ought to be SHOULD or MUST but then
realised that this I-D is INFORMATIONAL so that those would not
really be appropriate.

Tom Petch

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Warren Kumari" <[email-masked]>; "idr" <[email-masked]>
Sent: Sunday, January 16, 2011 4:28 PM
Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00

Cool, done!

Version -01 included some strengthened text, but I've just posted -02.
Please have a look and let me know if you think this is the correct strength --
it's basically what you provided, but reworded slightly to be a little more
"formal".

W