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

[Christopher Morrow <[e-mail]>]

On Wed, Dec 5, 2012 at 12:12 PM, Edward Crabbe <[e-mail]> wrote:
> Support.
>

you support the draft of jay's non-support for support of the draft?

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