Subject: RE: VPN solution - White flag ?

From: Jim Guichard <[email-masked]>
Date: Thu, 26 Oct 2000 13:42:49 +0100

Barry,

the answer is no. There are various ways to design Internet connectivity
within this environment, one of which is to carry full Internet routes on
the PE router. Other options include default routing from VPN sites to a
central site that has Internet connectivity, another is to offload the
Internet routes from the PE and run direct eBGP sessions from the VPN site
to the Internet exit point. Which option is actually taken will depend on
the specific design requirements. Jim

At 08:37 26/10/2000 -0400, Barry Hass wrote:
>Eric,
>
>Doesn't a PE router have to handle the full Internet routing
>table, plus VRFs for whatever VPNs it is supporting? I think
>that what some folks are suggesting is that BGP (not "the box",
>but BGP specifically) is already bumping up against scaling
>limits at 100,000 or so routes, and that burdening it with the
>additional responsibility of managing VPNs is not such a great
>idea. ("Some folks" please correct me if I'm wrong). Can you
>comment on that?
>
>By the way, I don't have enough information to have an opinion
>on this. I'm just trying to steer the discussion back to what
>I thought was an interesting technical question before the
>insults started to fly.
>
>> In the  NBVPN routing environment, it is  not true that 
>> anyone  in the world
>> needs to be  able to reach anyone else  in the world.  Each 
>> VPN  has its own
>> inter-connectivity  matrix,  much  smaller  than the  
>> Internet  connectivity
>> matrix.  Now if you add up all the VPN routes, summed over 
>> all VPNs, you may
>> indeed get  a much larger  number than the  number of 
>> Internet  routes.  But
>> there is no one box which needs  to hold them all.  Since an 
>> instance of BGP
>> runs in a particular box, and only  has to deal with the 
>> routes that need to
>> be in that box,  you don't run up against the same  box 
>> scaling problems you
>> run up  against in  the Internet routing  environment.  You 
>> can  design your
>> system to  have a given box  handle as many routes  or as few 
>>  routes as you
>> want.  
> 

Jim Guichard CCIE #2069
Network Design Consultant EMEA
Global Solutions Engineering 

+44 208 756 8806
Mobile: +44 7802 809763

---

From: Paul Doolan <[email-masked]>
Date: Thu, 26 Oct 2000 08:47:54 -0400

Jim,

>Other options include default routing from VPN sites to a
>to the Internet exit point.

  When you say 'VPN site' here are you suggesting that the CE router is
  running eBGP with/to the 'Internet exit point' ?

  pd

---

From: Jim Guichard <[email-masked]>
Date: Thu, 26 Oct 2000 15:56:21 +0100

yes, exactly this. By doing this, the CE is able to learn full Internet
routing information without the need to populate the PE with this
information. The Internet exit point address needs to be available via the
PE router and a default route within the PE VRF has to be available so that
any destination that is not covered by a VPN route can be routed based on
the default toward the exit point. From a CE perspective, all it needs to
do is be able to reach the exit point and advertise its BGP peering address
(next-hop) toward the PE router. Jim

Jim Guichard CCIE #2069

+44 208 756 8806
Mobile: +44 7802 809763

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Oct 2000 09:12:38 -0700

and which one will work for a large isp with lots of vpn customers and lots
of connections to other peer isps?

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Oct 2000 09:23:54 -0700

the problem is that an isp has *many* 'exits' to the internet, like dozens.

---

From: Jim Guichard <[email-masked]>
Date: Thu, 26 Oct 2000 17:30:09 +0100

depends. If I separate VPN and Internet access then I can propogate my
global Internet routing information between all Internet routers but VPN
information only between PE routers that need it. I could also direct my
traffic to an Internet router that has selected the best path based on all
peering points. Maybe I have customers that actually want access via a
specific ISP ? I can do this also by directed BGP session from the VPN site
to the exit point. I also may have requirements for NAT and Firewall
services where I need to direct my VPN customers to central services that
provide this functionality and also provide optimal BGP exit point routing
based on the best path selection. Maybe I don't want to exchange Internet
routes at all with the VPN provider in which case I will run iBGP sessions
directly between my sites and just exchange next-hops with the provider .. Jim

Jim Guichard CCIE #2069

+44 208 756 8806
Mobile: +44 7802 809763

---

From: Eric Rosen <[email-masked]>
Date: Thu, 26 Oct 2000 12:48:01 -0400

Randy> which one  will work for a large  isp with lots of  vpn customers and
Randy> lots of connections to other peer isps? 

This particular  scenario is  not the only  scenario in existence.   But for
this scenario, it  is probably best to keep the VPN  routes and the Internet
routes strictly separated, so that no  one edge router has them both.  There
are two obvious ways to do this:

- If  VPN  access and  Internet  access  are to  be  offered  over the  same
  interface, then  keep only the VPN routes  in the PE router  to which that
  interface  leads.  Packets  which  need to  go  to the  Internet then  get
  default-routed to an adjacent router which has the Internet routes.

- Use different interfaces for VPN access and Internet access, and have them
  lead to different edge routers. 

Of course, if one makes it a  requirement that the adoption of a VPN service
have no  impact on  the network  design, then the  RFC2547 solution  will be
ruled out in this scenario.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Oct 2000 10:09:19 -0700

> Then perhaps this is not the solution for you.  However, the fact
> that it is not applicable to your particular application does not
> make it worthless (this is to be differentiated from drafts
> documenting architectures that are applicable to no applications).
> 
> Is it inappropriate, in general, for SPs who need to maintain full
> Internet tables in their PEs?  Quite likely.
> 
> Is it inappropriate, in general, for SPs who have nothing but VPN
> customers, each of whom has very few prefixes?  Probably not.
> 
> I don't believe anyone has challenged either MOs or your ability to
> engineer ISP networks, but perhaps viewing everything through your
> ISP goggles is not the most effective way to judge the utility of
> all drafts.

so we agree it is not for isps.  cool.

so, if an enterprise wanting to deploy it is not an isp, then they'll
need their own layer 1 or2 connectivity between all endpoints.  so then
what is the advantage to them of this clever (a pejorative) approach to
old-style layer 2 vpns?

randy

---

From: Ben Black <[email-masked]>
Date: Thu, 26 Oct 2000 09:52:20 -0700

Ben

---

From: Ben Black <[email-masked]>
Date: Thu, 26 Oct 2000 10:10:59 -0700

I am not sure I understand your question.  Are we not debating
the merits of draft-rosen-rfc2547bis-02.txt, a layer 3 approach?

Ben

---

From: Eric Rosen <[email-masked]>
Date: Thu, 26 Oct 2000 13:25:38 -0400

Randy> if an enterprise wanting to deploy it is not an isp, then they'll
Randy> need their own layer 1 or2 connectivity between all endpoints. 

Just to be  clear, you are saying  that, to the best of  your knowledge, all
networks fall into one of the following two categories:

1. needs to carry all Internet routes to every edge

2. needs complete mesh of layer 2 connections between all endpoints. 

I had no  idea that all networks  fell into one of these  two categories!  I
don't know how I missed that ;-)

---

From: Vijay Gill <[email-masked]>
Date: Thu, 26 Oct 2000 14:04:04 -0400

[ folks, it doesn't hurt to trim headers ]

> 1. needs to carry all Internet routes to every edge

Having worked at one or two promising local ISPs, I assure you that the
plan of deploying two routers where one will do (and where one is just to
aggregate VPN customers) is something that will not fly very well.

This of course leads to a realistic scenario where you have the minimum
number of routers necessary to satisfy the business need at the edge and
since a couple of customers insist on having full routes, well....

I suspect this is where Randy is coming from. Given that routers _barely_
work as it is, we'd much rather wish this additional problem onto someone
else than have it sit in the ISP core, where routers crashing lead to SLA
violations and asosciated pain.

> don't know how I missed that ;-)

Just most _realistic_ ISP networks fall into case 1.

/vijay

---

From: Ben Black <[email-masked]>
Date: Thu, 26 Oct 2000 11:04:32 -0700

> Just most _realistic_ ISP networks fall into case 1.

Not all SPs are ISPs.  The audience for IETF documents is not restricted
to ISPs.

ISPs wishing to provide MPLS VPN services may find the L2 approach of the
Kompella draft more attractive.  Dedicated MPLS VPN SPs may find the L3
approach of the Rosen draft more attractive.  The difference in environments
for each dictates engineering preferences, but does not invalidate
preferences in other environments.

In summary: Can't we all just get along?

Ben

---

From: Jim Guichard <[email-masked]>
Date: Thu, 26 Oct 2000 20:28:58 +0100

Vijay,

I do not think that anyone is saying that this is the only option, it is
just one of several. If there are a few customers that wish to receive full
routes, and in my experience this is not a great number, then you can of
course offload the eBGP session from your PE router and let the customer
run directly with the internet exit point (or router that can establish the
best exit point). It is clear that not all PE routers will have VPN
customers attached that require internet access, or if they do, they do not
require full routing. So maybe the question should be what percentage of
VPN customers will want full routes, and where will these customer sites be
located ? if the answer to this is a small number with certain sites
requiring full routes then the answer may be dedicated Internet boxes,
multi-hop sessions or even restriction of VPN attachment to the PE holding
the full routes (with non-full route VPN customers perhaps located on other
PE routers within that POP) .. Jim

Jim Guichard CCIE #2069

+44 208 756 8806
Mobile: +44 7802 809763

---

From: Eric Rosen <[email-masked]>
Date: Fri, 27 Oct 2000 09:34:37 -0400

I think  Vijay's message reveals  a presupposition about the  business model
which  is worth  pointing out,  viz., that  Internet access  is  the primary
business and VPN service a side line.

All Internet routes  are brought to the edge because  "a couple of customers
insist on  having full routes".  And  one doesn't deploy  equipment "just to
aggregate VPN customers". 

If one's business were primarily VPN service, one would be a lot more likely
to say  "I'm not going  to bring full  routes to the  edge just for  the few
customers which  want them; those  customers are already running  EBGP, they
can just run it multi-hop". 

I'm sure someone will respond that there are no SPs who are primarily in the
VPN business and only secondarily in the Internet access business ;-)

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Oct 2000 09:42:17 -0700

> VPN business and only secondarily in the Internet access business ;-)

you're probably right.  the vpn-only provider will have to pay for the layer
1/2 circuits and compete in price with those who sell both vpns and ip.  so
they'll soon sell anything they can to try and survive.

randy

---

From: Eric Rosen <[email-masked]>
Date: Fri, 27 Oct 2000 12:54:06 -0400

At this point, I would say  there is adequate information in this thread for
everyone to form  an opinion as to who knows what  they're talking about and
who doesn't.