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

[Jon Mitchell <[e-mail]>]

Inline some specific comments.. in no way meaning to change your
position on the draft.

On Thu, Nov 29, 2012 at 12:50:44PM -0500, Jared Mauch wrote:
> Robert,
> 
> On Nov 29, 2012, at 12:36 PM, Robert Raszuk wrote:
> 
> > I think this is yet one more case where the "Internet BGP" is trying
> > to fight with "Private_Use of BGP".
> > 
> > There are multiple applications BGP can serve and we have single
> > protocol and single resource pool of ASes used by that protocol. Leave
> > alone types of communities, attributes etc ...
> > 
> > Internet folks will say "Do not trash our environment"
> 
> As an operator, I feel this is a fair thing for me to say. :)
> 
> This isn't about private use of bgp vs public use of bgp.  It's about the engineering decisions that went into using BGP as the tool in the first place, and the implementation secondary.  The added requirement of a larger space isn't unreasonable, but looking for a reservation (and the side-effects this will have on vendor code, deployability, usability, etc..) are not insignificant and to be outright dismissed.
> 
> Picking on Cisco - The configuration directive is listed here:
> 
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f27.shtml
> 
> remove-private-as
> 
> Will there be remove-private-as [oh-yeah-and-that-extended-space-too] ?  How will this be incrementally deployed and used?

For some it will not need to be (they don't use the command today).  For
others, it will need to be updated ONLY IF they intend to allow transit
for prefixes from private ASNs in the new range.  This can easily be
enforced by having egress filters recognize the new range, which I have
yet to find a vendor that doesn't support AS_PATH filtering, although
maybe someone will correct me with their own personal implementation!
They worst case, which already happens today, is that a prefix
originating from the person taking the risk (using a Private ASN or a
new range Private ASN) does not have full Internet connectivity due to
downstream filtering.  I think something the folks for and against this
draft can all agree on is our lack of sorrow for them.

I don't expect to need multiple variants of remove-private-as, one
variant that recognizes both ranges is probably enough for the operator
community (although I can't speak for all of them).  BGP features are
being added everyday, I think this update is fairly minor as others have
pointed out.

> 
> If the goal is something like "I have 5000 racks of gear, want a top-of-rack-switch with a /64 on each of them", this is a solvable problem in current running code today.  You use rfc2270 and allow-as-in with the existing space outlined in rfc1930.

It's a bit more complex then this actually in practice, but generally
agreed that re-using private ASNs at some level with that vendor
specific knob and other vendor specific knobs makes this possible as
some of my colleagues have shared.

> 
> If the goal is to use the ASN as that identifier, eg: encoding the POP/ROW/RACK in the ASN, then I will be the first to say this is a misapplication of technology.  That should either be encoded in your addressing plan or your network documentation.  BGP can't be the place for each need to find the solution fulfilled. (note lowercase "need").

I think people have taken a leap to think that a BGP design used
internally to some MSFT DC's is the primary motivation of this draft
rather than unique number of sites (or organization/site) in a large
organization.  I don't have any forseeable plans to encode row and rack
location information into AS numbers and guarentee uniqueness for such
when this draft passes (although I'm not against the possibility or any
other use of private ASNs people may have WITHIN THEIR OWN NETWORK).

I think if you use BGP as a routing protocol many organizations are
creating an eBGP boundary per site or sub-organization for various
reasons related to implementing policy controls and creating segmented
routing domains, where using a single ASN at all sites does not provide
the necessary connectivity requirements (i.e. I need more than default)
depending on how these sites are interconnected w/o using a number of
complex routing tricks, many of which would require non-standarized
implementation specific features that vary.  I'd like to have a simpler
path forward in the long run...

Jon

> 
> 
> > Applications and services folks will say "We just find BGP useful to
> > our application, why not use it - we have nothing in common with big
> > I"
> > 
> > On that basis I see no harm in allowing some bigger AS space for personal use.
> > 
> > In fact I just looked at various RIR policies (some of them written by
> > Geoff ;) which say that given LIR can get only single AS number
> > allocation - even for experiments. Moreover RIRs get 1K AS pools from
> > IANA and there are clear rules where the subsequent pool can be
> > requested.
> 
> These policies are community driven, and could be changed.  I'm not saying they are right or wrong, but if you have collisions in numbering, you should get unique space to properly work around it vs using a hack.
> 
> > Yes Jared is right that RFC2270 or similar techniques can be used. In
> > fact I spoke with John offline today about one of such cases where
> > private as just get's stripped immediately. But those ideas are just
> > moving the issue and not really solving it - making the internal
> > network troubleshooting more complex.
> 
> I'm not convinced that the AS(4)_PATH is the right place to encode this information.  Numerous elements go into a network and site documentation.  If your premise rises or falls based on this individual element, perhaps it was poorly conceived in the first place?
> 
> - Jared
> 
> > 
> > Regards,
> > R.
> > 
> >> On Thu, Nov 29, 2012 at 5:53 PM, Jared Mauch <[e-mail]> wrote:
> >> 
> >> 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