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

[Edward Crabbe <[e-mail]>]

Support.

  -ed

On Wed, Dec 5, 2012 at 9:00 AM, Jay Borkenhagen <[e-mail]> wrote:

> 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
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>