Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

[Jay Borkenhagen <[e-mail]>]

Hi,

My thoughts on this issue have been best expressed by Jared in his
messages here, including the one repeated below.  Likewise, I do not
support advancing this draft.

Jared also wrote in another message:

 > remove-private-as

 > Will there be remove-private-as
 > [oh-yeah-and-that-extended-space-too] ?  How will this be
 > incrementally deployed and used?

To spell this out a bit more explicitly, suppose:

1) this draft proceeds, and a new block of private ASNs is allocated. 

2) someone starts using a private ASN from the new block, not
recognizing that their routers (or their upstream provider's routers)
have 'remove-private-as' configured but are running older code that
recognizes & removes only the old block.  still they get their
connectivity to work somehow.

3) later, they (or their upstream provider) upgrades routers to a
version that adds the new private ASN block to 'remove-private-as'
treatment, and suddenly connectivity breaks or traffic patterns shift
in some unwanted way.


Yes, this sort of problem with incremental deployment happens all the
time.  But we should limit the occasions where it happens to those
where the win is big enough.  In this case I don't think there is
enough of a win.


BTW, if this draft does proceed, it will provide me with more reasons
to encourage network designers I talk to to avoid using private ASNs
altogether.  Them: "But private ASNs must be great.  Look, they just
allocated a bunch more."  Me: "All the more reason never to use them."
:)

Thanks.
						Jay B.



On 28-Nov-2012, Jared Mauch writes:
 > Greetings,
 > 
 > Jon pointed me to this draft earlier today so please be kind (for the first 5 minutes after this is delivered in your mailbox.).
 > 
 > After reading the list history back a few months or so on this topic, I must express the same reservation that Randy and Geoff have raised.
 > 
 > I do not feel this is a problem space that needs to be addressed.  Vendors easily disable loop-detection in current running code, and rfc2270 seems to clearly apply in the problem space this is attempting to address.
 > 
 > The issue of ASN collisions were raised, and I feel can be dismissed easily by one party engaging with their local RIR for a nominal "cost of running BGP" threshold.  The recurring annual cost is likely a budgetary "rounding error" and is not a barrier to entry IMHO.
 > 
 > I have other concerns should this move forward that would impact operations.  I will comment on them in private should folks desire.
 > 
 > I do not feel this draft can be supported.
 > 
 > - Jared
 > 
 > 
 > On Nov 29, 2012, at 11:40 AM, Tony Li wrote:
 > 
 > > 
 > > Support.
 > > 
 > > Editorial nit: I would find it MUCH more helpful if the constants were also expressed in hex.
 > > 
 > > Tony
 > > 
 > > 
 > > On Nov 28, 2012, at 1:26 PM, John Scudder <[e-mail]> wrote:
 > > 
 > >> Folks,
 > >> 
 > >> We have received a request for a working group last call on draft-ietf-idr-as-private-reservation-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00
 > >> 
 > >> Please send comments to the list by December 14. [*]
 > >> 
 > >> Thanks,
 > >> 
 > >> --John
 > >> 
 > >> [*] Unless the world ends on December 12, in which case send them by December 12.
 > >> _______________________________________________
 > >> Idr mailing list
 > >> [e-mail]
 > >> https://www.ietf.org/mailman/listinfo/idr
 > > 
 > > _______________________________________________
 > > Idr mailing list
 > > [e-mail]
 > > https://www.ietf.org/mailman/listinfo/idr
 > 
 > _______________________________________________
 > Idr mailing list
 > [e-mail]
 > https://www.ietf.org/mailman/listinfo/idr