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

[Edward Crabbe <[e-mail]>]

I support the draft.

cheers,

 -ed

On Wed, Dec 5, 2012 at 9:56 AM, Christopher Morrow
<[e-mail]>wrote:

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