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

["Daniel Cohn" <[e-mail]>]

Hi Wes and Rob,

First of all thanks for writing this draft, it does a great job of
compiling L3VPN scalability issues in one place and I think it will be
very helpful for developers and operators.

Few questions/comments:

- I understand/agree with the general assertion that BGP is inherently
more scalable than IGPs, also in PE-CE application. But I don't
understand the statement that "(IGPs) invoke additional processes on the
router when compared to simply using BGP (which is already going be
running on a router using MP-BGP for VPNs"). This is because even if BGP
is already running on the router as PE-PE protocol, using BGP as PE-CE
protocol will also typically required "additional processes" in the
router as each BGP instance will typically run on a separate BGP
process. Barring specification implementations, I don't see how BGP and
IGPs as PE-CE differ in this aspect.

- In the following paragraph: 

"Where it may be possible to assign a single RD per L3VPN instance, and
hence achieve some level of route aggregation on BGP speakers within the
solution, this has some consequences for both convergence in the VPN
(due to BGP convergence being relied upon) and in its potential to
exacerbate geographic distance between PE and Route-reflector and is
therefore undesirable in some circumstances"

Are you referring to multiple-homed CE scenario, where the same NLRI
will be advertised with different BGP next hops if the same RD is used?
If yes, I think it should be clarified. If not, can you please explain
to which scenario you refer?
Also, what do you mean by "exacerbate geographic distance"? I don't
understand the meaning of this expression nor the problem it describes.

- 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,
e.g.: what do you expect PE-CE and PE-PE protocols should do with routes
they receive after the limit has been reached? Should these routes be
stored and installed at the VRF when the route count goes below the
limit (plus some hysteresis threshold of course)? Or should they also be
discarded by the PE-CE/PE-PE routing protocols? If discarded, how will
you resync with the neighbors/peers once the route count goes below the
limit?

Regards,

Daniel


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of George, Wes
Sent: Tuesday, March 06, 2012 11:27 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: updated draft-gs-l3vpn-scaling & agenda request

Hello all -

Rob and I have completed a revision of our draft discussing L3VPN
scaling considerations. We've made some changes to the document
structure to make it flow better, and we think that we've added enough
of the body that it is ready for discussion during a WG meeting.
However, since L3VPN is not meeting during IETF in Paris, we're
wondering if we should perhaps ask for time in the Routing area open
meeting/RTGAREA WG instead?

Either way, comments are still very welcome, especially if you can help
us bolster the currently weak section on multicast VPN scale.

Abstract

   This document discusses scaling considerations unique to
   implementation of Layer 3 (IP) Virtual Private Networks, discusses a
   few best practices, and identifies gaps in the current tools and
   techniques which are making it more difficult for operators to cost-
   effectively scale and manage their L3VPN deployments.

http://tools.ietf.org/html/draft-gs-vpn-scaling-01

Thanks,

Wes George


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.