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

[David Farmer <[e-mail]>]

On 12/10/12 16:50 , Jon Mitchell wrote:
>
> David / Randy - thoughts inline...
>
...
>>> update the draft to make these arguments, i will support it, and i
>>> suspect other dissidents will as well.
>
> Actually Randy, to be fair, I think a number of dissendents will not
> over a philosophical objection to private use space, and I'm quite
> shocked at this development since previously I asked you specifically if
> there was anything in the wording that could be changed that would allow
> you to support it and you declined.  Trying to do a neutral re-reading
> of the draft (I think you naturally read it from an ISP providing
> Internet access point of view), I see the last sentence in the
> introduction which was meant to be a broad statement on why BGP has
> proliferated to so many organizations (which includes provider
> redundancy) could be confused to be meaning that "provider assigned asn"
> is the target of this draft.  In a general sense, I'd rather expose any
> issues with private use asns and then allow operators to make their own
> problems in so much as they don't affect others unnecessarily which you
> seem to agree with.  I'd be willing to delete that line if you think
> appropriate?
>
>>
>> In the first paragraph of the introduction there is already a
>> reference to BGP/MPLS IP VPNs [RFC4364], do you want Data Centers
>> explicitly added with reference to
>> draft-lapukhov-bgp-routing-large-dc too?  Are there other references
>
> Brian - As much as marketing is important, I don't think including a
> reference a draft that we haven't yet found a home for that documents
> Microsoft use of BGP within some DC's is a good idea for something that
> applies generically to multiple sites within a single organization.  I
> think many can agree they have seen DC's be in a seperate AS
> (public/private/confed) than the core networks which attach them, I have
> seen this as a normal configuration in multiple networks over the last
> 12 years personally....  I unfortunatley tried to capture this as large
> content providers and may have more generically said DC operators
> (either within or between DC's where they determine the connectivity),
> but I don't think one sentence in the introduction is worth re-opening
> the draft text during WGLC.  I'd be open to considering this past WGLC
> as a minor change however, along with striking the last sentence of the
> introduction if you both think this is appropriate.

In the introduction I believe you do a good job motivating that the uses 
of BGP have expanded significantly since RFC 1930 and this is what 
justifies the expansion.  I'm including the relevant text from the draft;

    ... Since the time when that range was
    reserved, BGP has seen much wider deployment in service provider,
    enterprise and content provider networks.  The places in these
    networks where private use ASNs are in use include networks that are
    attached to the Internet, utilizing implementation specific features
    to remove them upon advertisement to Internet peers, and networks
    that are not attached to the Internet.  The displacement of Frame
    Relay and ATM based VPNs by BGP/MPLS IP VPNs [RFC4364] has also
    increased the deployment of BGP to a larger number of sites,
    especially in networks with requirements for multi-homing or provider
    redundancy.

But I will note that large scale data center use of BGP is not 
explicitly mentioned, maybe it should be added, at least as another 
anticipated use case of more than 1023 ASNs within a single private use 
ASN domain, with or without a reference to the aforementioned draft. 
But, this is the only draft or RFC that I can find that explicitly 
motivates the need for more that 1023 private use ASNs, so not including 
the draft weakens the argument for why we need more that 1023 ASNs, in 
fact I would suggest explicitly referencing section 7.2.2 of the draft 
where the issue is discussed.

Also, I suggest including that BGP/MPLS IP VPNs [RFC4364] for 
enterprises with more than 1023 sites can't use the fairly common 
practice of assigning a private use ASN per site, and is another use 
case for more that 1023 private use ASNs.  A similar example is a large 
private BGP cloud, not necessarily using MBGP, with fairly complicated 
internal routing policy amongst a large number of sites.

I guess what I'm trying to get at is; You should add specific examples 
of where the current 1023 private use ASNs are not enough, to help 
motivate why more are needed.  This is not to say where private use ASNs 
should or shouldn't be used, but that there exist real world cases that 
justify more than 1023 private use ASNs.  Furthermore, these reasons are 
also motivations for some network operators to squat on public ASNs, if 
there is not a larger space of private use ASNs assigned.

Tony's argument was basically the Data Center guys are going to do this 
whether we want them to or not and that it is better for there to be an 
assigned a block than have them squat on public ASNs, I think that is 
the argument Randy is asking to be included in the draft.

I think this argument also applies to BGP/MPLS IP VPNs and internal 
enterprise use of BGP; I've had a couple enterprises ask me about more 
that 1023 private use ASNs and could/should they use some of the 4-byte 
ASN space.  I've told them to hold off and wait for this draft to assign 
a larger private use block from the 4-byte ASNs, rather than squat on 
public ASNs.  But, in the long-run they are going to squat on public 
ASNs, if there isn't a larger block of private use ASNs for them to use.

Also, even if we revise RFC 1930 and/or the RIR's revise their policies, 
to easily allow large publicly registered ASN blocks; There is a 
perception that many enterprises have that a private use block is better 
and more secure than a registered block.  It makes my head hut, and we 
can tell them all the reasons they are wrong, but that is their 
perception and it is their network they will be using them in.

> I'd like to re-iterate overall that the purpose the draft is primarly to
> make an IANA reservation, not to dictate or recommend to others what to
> do with it, except in the operational considerations lay out the changes
> to consider to continue to play nice with the broader Internet.

I agree we don't want to tell people where or where not to use private 
use ASNs in the draft.  However, it is not unreasonable to make sure we 
have a consensus on why 1023 private use ASNs are not enough, that there 
is justification to expand there numbers, and to document the reasons. 
And, from what I'm hearing this is what needs to be added to the Draft. 
  Especially, the data center argument above.

> Jon
>


-- 
================================================
David Farmer               Email: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================