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

[Jared Mauch <[e-mail]>]

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?

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.

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").


> 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