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

[Jon Mitchell <[e-mail]>]

David / Randy - thoughts inline...

On Fri, Nov 30, 2012 at 10:26:26PM -0600, David Farmer wrote:
> On 11/30/12 19:49 , Randy Bush wrote:
> >>the data center community has, for better or worse, decided that BGP
> >>is their protocol of choice.  Frankly, I find it mildly nauseating,
> >>but it's very clear that they are going to use BGP regardless of what
> >>you and I say.
> >
> >agreed
> >
> >but this is not what is in the ID or was not the discussion (that i
> >remember, with large caveats on my memory).  it has been about hiding
> >isp customers behind private asns, which we know how to do already.
> >
> >while nauseating, this is a more compelling argument.  and i note that
> >it does not have the merger problem the isp model has.  or, more
> >precisely, when it has the merger problem, it falls only on the fools
> >who made it.
> 
> I guess that's why we've been arguing past each other, for me its
> always been about enterprise and data centers use of BGP, not ISP
> customer access use of BGP.
> 
> I personally know of 2 or 3 large scale enterprises that are on the
> verge of having issues. They are currently just under a 1000 sites
> and would prefer to keep using unique (within their domain) ASNs for
> each site to avoiding the problems with loop detection hacks.  The
> burden for the hacks doesn't fall on the backbone SPs they fall on
> the customer edge sites.
> 
> Those hacks can be easily managed in a single backbone SP
> environment. However, when you start using multiple backbone SPs
> either for more cost effective reach or for redundancy, the topology
> can get complicated quickly.  There is a reason BGP has loop
> detection and in highly complicated environments those hacks can
> burn even the most experienced network engineers.  And in only
> moderately complicated environments, the junior engineers that many
> enterprises have are frequently in over their head with those hacks.
> 
> Large scale enterprise BGP-VPNs, Data Center BGP uses, and other
> newer applications of BGP that are not generally visible to the
> big-I topology are what is driving this, not ISP customer access
> BGP.
> 
> >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.

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.

Jon