RE: updated draft-gs-l3vpn-scaling & agenda request

Daniel - thanks for the review and the comments.
Robert answered a lot of the questions, so thanks to him for that, a few additional points inline below.

Thanks,

Wes
[snip]
>
> [DC] I think this is getting too much into implementation-specific
> issues. What you write above is related to routing information
> structure, but this does not necessarily mandate implementation
> architecture. For example I am familiar with multi-instance OSPF
> implementations that run a single process/thread for all instances,
> while internally adding instance information to the LSDB.
>

[WEG] I meant it in a slightly more simplistic way... A standard PE will be running an IGP and BGP for PE-PE and PE-P route exchange. Adding VRFs to BGP will add memory state, but is not usually going to result in spawning completely separate BGP processes. The details are indeed implementation specific, but we thought that this was a reasonable assumption based on the common implementations. Contrast this with a PE that is doing EIGRP, OSPF, etc as PE-CE routing protocol. If IS-IS is the chosen IGP, you're now running another routing protocol when you fire up OSPF. Same is true if you're already running OSPF as your IGP and you fire up EIGRP for a customer. Even if you are running OSPF as IGP and only use OSPF as PE-CE (vs adding EIGRP, etc), you're likely starting up another instance. Yes, it is possible for optimizations that manage it more like BGP does (one instance, but VRF aware to separate things properly within that instance), but IMO that's almost worse, because now you've potentially gone and tied your core IGP convergence and scale limitations to the customer-facing routing machinery. Unless the implementation is intelligent enough to prioritize global table IGP first, and only after that is done proceed with PE-CE, you're now in a race condition, to say nothing about how it handles large networks with lots of elements which can challenge the scaling limitations of the implementation all by themselves. I'm not sure it makes sense to get into this within the document since it is so implementation specific, but I'm open to discussion one way or the other.
>
> > - Regarding the maximum number of routes per VRF limit, I think there
> > should be some discussion on the PE behavior when the limit is
> reached,
[snip]
>
> No matter how you put it this is a mess for a given VPN and rather VRF
> limit was designed to be used as red light protecting other VPNs on a
> PE. Perhaps along discussing VRF limit authors should also discuss BGP
> prefix limit as proper correlation of both seems helpful.
>
[WEG] This is an interesting distinction. We likely need to make it clearer in the document, because there are definitely differences in how one might set a max-prefix limit per-session vs how you set the route-limit for the VRF. There are probably some things to add to the gap discussion as well, since there isn't a good method for end-users to know that they have a problem with route-limits. At least with max-prefix exceeded, you get a session shutdown that is a good indicator to both peers that something is amiss. If routes just get dropped, the sending party has no way of knowing why until they call in a trouble ticket and/or the SP notices the alarms on route-limits being exceeded.


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.