Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN)

From: lidefeng <[email-masked]>
Date: Wed, 06 Nov 2002 12:39:38 +0800

Hi,all,

   In BGP/MPLS VPN area, we proposed a new idea as to resolve the bottleneck
of
the capacity of some PEs when deploy the huge size VPN,the whole idea is
detailed
in the attached draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the
Abstract
is as follows,we are appreciated for your review.

   In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should
   maintain all the VPN routes of the VPNs which it belong to.When there
   are many VPNs converged by a PE,and the capacity of PE is relevant
   limited,then the bottleneck will be encountered.Another problem is
   that the current BGP/MPLS VPN model is something of a "Plane Modle"
   where the demand of the performance of the PE device are all the
   same no matter which layer the PE device is belongs to.However,the
   typical network is "Core-Convergence-Access(Edge)" model,and the
   performance of the device is superior in Core Layer and inferior in
   Access Layer,and the scale of network is large in Access Layer and
   small in Core Layer,the routes are converged in every layer,so in
   current "Plane Modle",when PE device push to the edge layer,it has
   to maintain more VPN routes,this makes it difficult to extend the PE
   device to edge layer.This document defines an model of hiberarchy of
   Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider
   Edge Device can be composed of several device and every device take
   on the different part,partake the function of the former
   concentrative PE,we call this model "Hiberarchy Model",In this model
   the demand of performance in Routing and Switching is strict to the
   PE device in High layer,loose to the PE device in edge layer.

   One HoPE can be composed of a SPE and UPES connected to the SPE,
   or be composed of a high-level SPE and HoPEs connected the high
   level SPE and and build up a new HoPE.This build is called nesting
   of HoPE,and this kind of nesting can be done for many times.Thus the
   former HoPE connect to the high-level SPE as a role of UPE,and the
   new HoPE can connect a single UPE too.

Regards

Defeng Li

---

From: "Jim Guichard" <[email-masked]>
Date: Wed, 6 Nov 2002 13:58:31 -0500

I briefly ran through this draft and it looks like normal hub & spoke using
existing 2547 mechanisms - could you explain how this differs ? thanks,

> >-----Original Message-----
> >From: lidefeng [mailto:[email-masked]]
> >Sent: Tuesday, November 05, 2002 11:40 PM
> >To: [email-masked]
> >Cc: [email-masked]; Marco Carugi; [email-masked];
> >[email-masked]; [email-masked]; [email-masked];
> >[email-masked]; [email-masked]; [email-masked]; Fu Y.
> >Miao; [email-masked]; [email-masked]
> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE
> >Device in BGP/MPLS VPN)
> >
> >
> >Hi,all,
> >
> >in the attached
> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the
> >Abstract

---

From: 李斌 <[email-masked]>
Date: Thu, 07 Nov 2002 15:42:15 +0800

Hi, Guichard
The hub & spoke is the relationship between CEs, but SPE peer with UPE by MP-BGP, they are all PEs, and they all can admit VPN user.

Libin

-----原始邮件-----
发件人: Jim Guichard [mailto:[email-masked]]
发送时间: 2002年11月7日 2:59
收件人: lidefeng; [email-masked]
抄送: [email-masked]; Marco Carugi; [email-masked];
[email-masked]; [email-masked]; [email-masked]; lhj@huawei.
com; [email-masked]; [email-masked]; Fu Y. Miao; leh10814@huawei.
com; [email-masked]
主题: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device
inBGP/MPLS VPN)

---

From: "Jim Guichard" <[email-masked]>
Date: Thu, 7 Nov 2002 11:00:56 -0500

so can hub&spoke with 2547 - you basically export routes from the
CE-attached PEs to a hub PE that imports the routes. The hub PE exports
either a default or aggregates to attract traffic from other CE-attached PEs
and then performs a lookup to forward the packets to other CE-attached PEs
.. Jim

> >From: 李斌 [mailto:[email-masked]]
> >Sent: Thursday, November 07, 2002 2:42 AM
> >To: Jim Guichard
> >Cc: [email-masked]; [email-masked];
> >[email-masked]; [email-masked];
> >Miao; [email-masked]
> >Subject: 答复: Please Review: A new draft about PPVPN(Hiberarchy
> >of PE Device inBGP/MPLS VPN)
> >
> >
> >Hi, Guichard
> >The hub & spoke is the relationship between CEs, but SPE peer
> >with UPE by MP-BGP, they are all PEs, and they all can admit VPN user.
> >
> >Libin
> >
> >-----原始邮件-----

---

From: 李斌 <[email-masked]>
Date: Fri, 08 Nov 2002 09:53:30 +0800

I believe that 2547bis not mention the hub & spoke PE. I think my proposal is the supplement of rfc2547bis. On the otherwise, not only some UPEs can talk with each other by SPE, but also a HoPE can talk with other PEs in a MPLS domain like a normal PE.

-----原始邮件-----
发件人: Jim Guichard [mailto:[email-masked]]
发送时间: 2002年11月8日 0:01
收件人: à?±ó
抄送: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Fu Y. Miao; [email-masked]
主题: RE: 答复: Please Review: A new draft about PPVPN(Hiberarchy of PE
Device inBGP/MPLS VPN)

---

From: 苗福友 <[email-masked]>
Date: Fri, 08 Nov 2002 10:07:28 +0800

Hi, Jim:

This draft is not to replace 2547, but a supplement to it. Actually the
VPN in the draft is completely works under the mechanism of 2547. 

In the traditional 2547 VPN, only one type of PE is defined. When
deployment, PE will not has so many ports to attach many VPNs if the PE
is at the core layer of the network, because core router generally
doesn't have a lot of physically interfaces.  If the PE is at the edge
of the network, it will have a lot of interfaces, but now the botlleneck
is capacity of computation of the router.   

This draft is to solve the problem, UPE will provide abundant interface
to conenct sites to VPN and SPE will have enough CPU/Memory to process
routes. 

Regards
Miao

-----邮件原件-----
发件人: Jim Guichard [mailto:[email-masked]] 
发送时间: 2002年11月8日 0:01
收件人: à?±ó
抄送: [email-masked]; [email-masked]; Marco Carugi;
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Fu Y. Miao; [email-masked]
主题: RE: 答复: Please Review: A new draft about PPVPN(Hiberarchy of PE
Device inBGP/MPLS VPN)

so can hub&spoke with 2547 - you basically export routes from the
CE-attached PEs to a hub PE that imports the routes. The hub PE exports
either a default or aggregates to attract traffic from other CE-attached
PEs and then performs a lookup to forward the packets to other
CE-attached PEs .. Jim

> >Subject: 答复: Please Review: A new draft about PPVPN(Hiberarchy of
PE 
> >Device inBGP/MPLS VPN)
> >
> >
> >Hi, Guichard
> >The hub & spoke is the relationship between CEs, but SPE peer with 
> >UPE by MP-BGP, they are all PEs, and they all can admit VPN user.
> >
> >Libin
> >
> >-----原始邮件-----
> >lhj@huawei. com; [email-masked]; [email-masked]; Fu Y. Miao; 
> >leh10814@huawei. com; [email-masked]
> >主题: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE 
> >Device inBGP/MPLS VPN)
> >
> >
> >I briefly ran through this draft and it looks like normal hub & spoke

> >using existing 2547 mechanisms - could you explain how this differs ?

> >thanks,
> >> >[email-masked]; [email-masked]; [email-masked]; Fu Y. Miao;

> >> >[email-masked]; [email-masked]
> >> >   In BGP/MPLS VPN area, we proposed a new idea as to resolve the 
> >> >bottleneck of
> >> >Abstract is as follows,we are appreciated for your review.
> >> >

---

From: Ray Qiu <[email-masked]>
Date: Thu, 07 Nov 2002 18:46:28 -0800

Miao,

In this scenario, does it make more sense to just use the edge PE (MTU) just
as a L2 transport box?  For example, you could use a cheap L2 switch, and
assign each customer a separate VLAN, then 2547 PE will terminate the VLANs
and does the IP/MPLS forwarding based on VRF information.

- Ray

---

From: Miao Fuyou <[email-masked]>
Date: Fri, 08 Nov 2002 11:31:43 +0800

Ray:

I believe we must take most advantage of existing SP network to deploy
VPN. In most cases, the network is more possible to be a IP network
comprising routers. It's almost infeasible to make the SP setup a
totally new network under current telecom depression.  For example, the
accessing layer comprises of LAN switches and strong routers at core. 

Acttually we came out this solution when a SP wanted to provide MPLS VPN
service on its existing network, and it performed the function well and
cost less budget. There is no doubt that VLAN/sub-interface is a
solution to solve the problem mentioned, but it only works well under
specific environment. So I believe UPE/SPE are good alteration.

Regards
Miao

-----邮件原件-----
发件人: Ray Qiu [mailto:[email-masked]] 
发送时间: 2002年11月8日 10:46
收件人: 昪暉桭
抄送: [email-masked]
主题: Re: 氮蝋: 氮蝋: Please Review: A new draft aboutPPVPN(Hiberarchy

Miao,

In this scenario, does it make more sense to just use the edge PE (MTU)
just as a L2 transport box?  For example, you could use a cheap L2
switch, and assign each customer a separate VLAN, then 2547 PE will
terminate the VLANs and does the IP/MPLS forwarding based on VRF
information.

- Ray

On 11/7/02 18:07, "苗福友" <[email-masked]> wrote:

> Hi, Jim:
> 
> This draft is not to replace 2547, but a supplement to it. Actually 
> the VPN in the draft is completely works under the mechanism of 2547.
> 
> deployment, PE will not has so many ports to attach many VPNs if the 
> PE is at the core layer of the network, because core router generally 

> of the network, it will have a lot of interfaces, but now the 
> botlleneck is capacity of computation of the router.
> 
> This draft is to solve the problem, UPE will provide abundant 
> interface to conenct sites to VPN and SPE will have enough CPU/Memory 
> to process routes.
> 
> Regards
> Miao
> 
> -----邮件原件-----
> CE-attached PEs to a hub PE that imports the routes. The hub PE 
> exports either a default or aggregates to attract traffic from other 
> CE-attached PEs and then performs a lookup to forward the packets to 
> other CE-attached PEs .. Jim
> 
>>> [email-masked];
>>>>> bottleneck of the capacity of some PEs when deploy the huge size 
>>>>> VPN,the
>>> whole idea is
>>>>> detailed
>>>>> in the attached

---

From: Senthilkumar Rajasekharan <[email-masked]>
Date: Fri, 8 Nov 2002 05:28:56 -0500 (EST)

Hi Defeng Li,

Some questions on your draft ....

Section 2.1

<snip...>

   SPE advertised the VRF default route or aggregate routes(by which
   UPE transfer the VPN packet to SPE) to UPE,this default VRF route
   can be formed dynamically or configured statically.When formed
   dynamically,it can be filtered by the ORF mechanism mentioned above.

<...>

Is this procedure mandatory, i.e should the SPE always advertise a default
route or aggregate route to the UPE? And should that route be advertised
with an aggregated export target list of all the import route targets received via
an ORF Route Refresh message from the UPE?

Section 2.2

<snip...>

 (7) SPE replace the inner label distributed by UPE with another inner
  label distributed by SPE,then advertise this route to PE through
  MP-BGP with the new inner label attached;

<...>

I don't understand why the SPE would replace UPE distributed inner label
here ??

Section 7

<snip...>

In another case that SPE connect one UPE and one CE,CE connect to
   site1,UPE connect to site2,site1 and site2 belong to the same VPN.
   The forwarding procedure is as follows:When the packet with no
   label sent from site1 arrived to SPE through CE, SPE push the label
   distributed by UPE,forward it to UPE,UPE POP this label,then look up
   the VRF route table,PUSH the label distribute by UPE2 and forward it
   to UPE2,and UPE2 POP the label,forward it to site2.

<...>

What is UPE2 here .... may be this is a typo !!

Thanks & Regards,
-Senthil

---

From: "Jim Guichard" <[email-masked]>
Date: Fri, 8 Nov 2002 10:28:32 -0500

Hi Miao,

I understand that this is not a replacement to 2547. I also understand that
hierarchy is one of the tools we have to help scale networks. However, what
I am driving at is that 2547 provides all of the necessary mechanisms
already to run this type of topology - deployment of 2547 is a matter of
design and no new functionality is necessary to be able to run the topology
you are suggesting. We have many deployments worldwide that already use this
type of design to provide central services to their customers. This does not
mean however that the topology is appropriate for all 2547 customers. There
are a number of issues with the proposed topology that one might consider:

1. In most real world deployments the number of hops between UPE and SPE
will be > 1. This may introduce unacceptable latency and so on, especially
as the design is being used for transit traffic rather than central
services.
2. Using this method introduces additional IP address lookups between
ingress PE and egress PE, plus label disposition/imposition.
3. Unless the SPE is located locally to the UPE then the regional VPN
traffic will be concentrated toward certain points of the network, instead
of being distributed across the whole infrastructure.
4. If the SPE is located locally, then aggregates can be injected down to
the UPEs but this is assuming that the address space is designed in such a
way as to allow this aggregation. Most Enterprise networks today do not have
such a well structured addressing plan.
5. By injecting aggregates toward the CE site you change the customers
routing view which may actually require the injection of more specific
routes.
6. The SP has to keep track of the aggregation and configure it
appropriately at the SPE.
7. How do you take care of customers that want to run OSPF or ISIS on the
PE-CE links ? how would sham-links work for example ?
8. To deploy H&S designs one must use different RTs for the same VPN and
then apply policy to filter correctly. This may not be such a big deal but
is a further complication in the provisioning and management process.
9. If our goal is to offload the edge routers from having to carry VPNv4
routes or run MP-BGP sessions then perhaps we should use the L2-transport
functionality in MPLS to carry the edge traffic to an SPE. This has the
advantage that the CE can exchange routes directly with the SPE which is
useful for other applications.
10. How do you take care of customers that want to run Carrier's Carrier
architecture ?

regards,

> >From: 苗福友 [mailto:[email-masked]]
> >Sent: Thursday, November 07, 2002 9:07 PM
> >To: 'Jim Guichard'; 'à?±ó'
> >Cc: [email-masked]; 'Marco Carugi'; [email-masked];
> >[email-masked]; [email-masked]; [email-masked];
> >[email-masked]
> >Subject: 答复: 答复: Please Review: A new draft about
> >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN)
> >
> >
> >Hi, Jim:
> >

---

From: Miao Fuyou <[email-masked]>
Date: Sat, 09 Nov 2002 17:01:28 +0800

Hi, Jim:

Please find my commnets inline!

Regards
-----邮件原件-----
发件人: Jim Guichard [mailto:[email-masked]] 
发送时间: 2002年11月8日 23:29
收件人: ???￡ó?; '¨¤??à¨?'
抄送: [email-masked]; 'Marco Carugi'; [email-masked];
[email-masked]; [email-masked]; [email-masked]; lhj@huawei.
com; [email-masked]; [email-masked]; [email-masked]
主题: RE: 答复: 答复: Please Review: A new draft about PPVPN(Hiberarchy
of PE Device inBGP/MPLS VPN)

Hi Miao,

I understand that this is not a replacement to 2547. I also understand
that hierarchy is one of the tools we have to help scale networks.
However, what I am driving at is that 2547 provides all of the necessary
mechanisms already to run this type of topology - deployment of 2547 is
a matter of design and no new functionality is necessary to be able to
run the topology you are suggesting. We have many deployments worldwide
that already use this type of design to provide central services to
their customers. This does not mean however that the topology is
appropriate for all 2547 customers. There are a number of issues with
the proposed topology that one might consider:

Miao: Actually it's not a problem of topology, it's for the planning and
design of the network. If 2547 alone can work under for every network
and meet all the VPN requirement, why were VPLS, Martini VPN, Kompella
VPN and many others proposed?

1. In most real world deployments the number of hops between UPE and SPE
will be > 1. This may introduce unacceptable latency and so on,
especially as the design is being used for transit traffic rather than
central services. 

Miao: I don't think hops > 1 brings more latency if a packet must go
from an ingress PE to an egress PE. Actually it follows almost the same
route that 2547 one will do if the network is not very careless
designed.

Miao: It's a ONCE-FOR-ALL work for a site, so the effort is trivial

3. Unless the SPE is located locally to the UPE then the regional VPN
traffic will be concentrated toward certain points of the network,
instead of being distributed across the whole infrastructure. 

Miao: UPE can process it locally in such case, no SPE involved

4. If the SPE is located locally, then aggregates can be injected down
to the UPEs but this is assuming that the address space is designed in
such a way as to allow this aggregation. Most Enterprise networks today
do not have such a well structured addressing plan. 

Miao: Refer item 3

Miao: No aggretes injected in HoPE actually

Miao: SPE will do

7. How do you take care of customers that want to run OSPF or ISIS on
the PE-CE links ? how would sham-links work for example ? 

Miao: Only default route is needed in HoPE at PE-CE links, so why to run
OSPF & IS-IS?

8. To deploy H&S designs one must use different RTs for the same VPN and
then apply policy to filter correctly. This may not be such a big deal
but is a further complication in the provisioning and management
process. 

Miao: Repeat, it's not a problem of topology, not to say H&S

9. If our goal is to offload the edge routers from having to carry VPNv4
routes or run MP-BGP sessions then perhaps we should use the
L2-transport functionality in MPLS to carry the edge traffic to an SPE.
This has the advantage that the CE can exchange routes directly with the
SPE which is useful for other applications. 

Miao: L2-transport is not always applicable. CEs don't always run MPLS. 

Miao: But, what is the problem?

regards,

> >Subject: 答复: 答复: Please Review: A new draft about
PPVPN(Hiberarchy of 
> >PE Device inBGP/MPLS VPN)
> >
> >
> >Hi, Jim:
> >

> >doesn't have a lot of physically interfaces.  If the PE is at the 
> >edge of the network, it will have a lot of interfaces, but now the 

of

> >> >lhj@huawei. com; [email-masked]; [email-masked]; Fu Y. 
> >> >Miao; leh10814@huawei. com; [email-masked]
> >> >> >Miao;
> >> >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of 
> >> >> >PE Device in BGP/MPLS VPN)
> >> >> >
> >> >> >
> >> >> >Hi,all,
> >> >> >
> >> >> >   In BGP/MPLS VPN area, we proposed a new idea as to resolve 
> >> >> >the bottleneck of the capacity of some PEs when deploy the huge

> >> >> >size VPN,the
> >> >> >   limited,then the bottleneck will be encountered.Another 
> >> >> > problem
> >is
> >> >> >   same no matter which layer the PE device is belongs 
> >> >> > to.However,
> >the
> >> >> >   Access Layer,and the scale of network is large in Access 
> >> >> > Layer
> >and
> >> >> >   small in Core Layer,the routes are converged in every 
> >> >> > layer,so
> >in
> >> >> >   current "Plane Modle",when PE device push to the edge 
> >> >> > layer,it
> >has
> >> >> >   Edge Device can be composed of several device and every 
> >> >> > device
> >take
> >> >> >   the demand of performance in Routing and Switching is strict

> >> >> > to
> >the
> >> >> >   former HoPE connect to the high-level SPE as a role of 
> >> >> > UPE,and
> >the

---

From: lidefeng <[email-masked]>
Date: Mon, 11 Nov 2002 11:11:57 +0800

Hi, Senthil,

        Sorry to answer you so late! I will answer all the questions on the
heels of them(you can find my answer as following ).
        BTW,I am ad hoc appreciated for your pointing out a big typo in this
draft,I have correct it and send you the right one, I am very glad to
discuss these questions with you!
       Keep in touch!

       Best Regards!

       Defeng Li

----- Original Message -----
From: "Senthilkumar Rajasekharan" <[email-masked]>
To: "lidefeng" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 08, 2002 6:28 PM
Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE Device
in BGP/MPLS VPN)

> an ORF Route Refresh message from the UPE?

Yes ,this procedure is mandatory,maybe from the point of view of working
principle,SPE can
run dynamic routing protocol with UPE and send all the routes in SPE to
UPE,then UPE should
store and maintain all the routes of  the VPN in HoPE,the dvantage of this
scheme will be forfeited,

The default route is advertised when UPE connected to only one SPE.

In the case of load balance where
one UPE connected to several SPE(this situation didn't denoted in the figure
of our draft) to balance the
load of some VPN,then different SPE should advertise the different
aggregated route to this UPE(the aggregated route
is created according the match export target list  received by the
respective SPE between of the import route targets of
different part of VPN in UPE )

> I don't understand why the SPE would replace UPE distributed inner label

In this case,It is SPE and not UPE that established MP-BGP with PE(the PE in
the remote point of HoPE),
so SPE must replace the inner label distributed by UPE with another inner
label distributed by SPE,otherwise,
when transfer the data packet from PE to VPN1 site1,ths data packet can't
reach UPE,it would dropped
at SPE for the reason that SPE didn't recognise the inner label attatched
with MP-IBGP NLRI between
SPE and PE.

> What is UPE2 here .... may be this is a typo !!

Yes,you are right,this is a big typo,It happenen when I add the page header
and page footer
to this draft after I finish this draft,I overlay the several lines of  page
header and page footer
to the original text by mistake,sorry to confuse you,I have made the
correction,the right one
should be as follows:

 " In another case that SPE connect one UPE and one CE,CE connect to
   site1,UPE connect to site2,site1 and site2 belong to the same VPN.
   The forwarding procedure is as follows:

   (1)When the packet with no label sent from site1 arrived to SPE
   through CE, SPE look up VRF route table,and push the label distributed
   by UPE,forward it to UPE,UPE POP this label,forward it to Site2.

   (2)When the packet originated from Site2 arrived to UPE,UPE transfer
   the packet to SPE on the basis of default or aggregate route,SPE then
   look up the VRF route table,POP the label,forward it to Site1 as an IP
   packet."

> >    In BGP/MPLS VPN area, we proposed a new idea as to resolve the
bottleneck

---

From: lidefeng <[email-masked]>
Date: Mon, 11 Nov 2002 11:14:13 +0800

Hi, Senthil,

       Best Regards!

       Defeng Li

----- Original Message -----
From: "Senthilkumar Rajasekharan" <[email-masked]>
To: "lidefeng" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 08, 2002 6:28 PM
Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE Device
in BGP/MPLS VPN)

> What is UPE2 here .... may be this is a typo !!

Yes,you are right,this is a big typo,It happened when I add the page header
and page footer
to this draft after I finish this draft,I overlay the several lines of  page
header and page footer
to the original text by mistake,sorry to confuse you,I have made the
correction,the right one
should be as follows:

bottleneck

---

From: "Jim Guichard" <[email-masked]>
Date: Mon, 11 Nov 2002 08:38:45 -0500

Hi Miao,

> >From: Miao Fuyou [mailto:[email-masked]]
> >Sent: Saturday, November 09, 2002 4:01 AM
> >To: 'Jim Guichard'; '¨¤??à¨?'
> >Cc: [email-masked]
> >Subject: 答复: 答复: 答复: Please Review: A new draft about

well VPLS, Martini and Kompella are talking about layer-2 application - we
are talking about layer-3 here which is a little different wouldn't you
agree ?

> >route that 2547 one will do if the network is not very careless

well I think it is fair to say that if you attract traffic to a particular
point of the network then the optimal path from an routing perspective is
more likely to be overlooked - this is not always the case but you cannot
assume in an architecture that all networks are built the same.

> >Miao: It's a ONCE-FOR-ALL work for a site, so the effort is trivial

maybe I misunderstood your description but if the hub has to route
inter-site traffic then we must remove the label stack, look at the IP
address and then send it back on its way - this is a per-packet exercise not
per-site.

> >Miao: UPE can process it locally in such case, no SPE involved

how can it if it does not have the routes ? if it has the routes then we
have 2547 no ?

> >do not have such a well structured addressing plan.

so item 3 says there is no aggregation and the scheme is rendered useless.

> >Miao: No aggretes injected in HoPE actually

well if it is just default route the same comment applies and is actually
even worse.

> >appropriately at the SPE.

how ? there are many ways to generate such an aggregate, each of which have
their own implications.

> >Miao: Only default route is needed in HoPE at PE-CE links, so why to run

default is not sufficient for most customers - a large subset of Internet
customers today want more than just default route. OSPF, ISIS, EIGRP and so
on were introduced so as to avoid changing the routing view of the end
customers - this is a desired requirement that HoPE does not service.

> >Miao: L2-transport is not always applicable. CEs don't always run MPLS.

CEs do not need to run MPLS to run L2-transport - the PEs do the
L2-transport.

> >Miao: But, what is the problem?

the problem is that you cannot run an end-to-end LSP to allow this type of
architecture to work ..

regards,

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 13 Nov 2002 16:38:12 +0800

Hi, Jim:

As per my understanding, your primary concern is routes. Actually the
problem is very similiar to the one in H&S topology, in which VPN
network views are not available at spoke site. Sure, the sites connected
by HoPE have not whole view of network, but the question is: really the
customer want to know that?  Anyway, for L3VPN, routing is an add-value
service provided by SP to customer.  Sometimes customer concerns VPN
topology, however, such function/service can be provided by Customer
Network Management, which is more convinient to customer.

Note that HoPE works under specific network environment to meet specific
requirement, it's not cure-all. However, it's happy to find that most
network are planned and setup with a hierachical topology, and where
HoPE can works best.

Regard
Miao

-----Original Message-----
From: Jim Guichard [mailto:[email-masked]] 
Sent: Monday, November 11, 2002 9:39 PM
To: Miao Fuyou; '?§?è??¨¤?§?'
Cc: [email-masked]
Subject: RE: 答复: 答复: 答复: Please Review: A new draft about

Hi Miao,

> >lhj@huawei. com; [email-masked]; [email-masked]; 
> >[email-masked]
> >I understand that this is not a replacement to 2547. I also 
> >understand that hierarchy is one of the tools we have to help scale 
> >networks. However, what I am driving at is that 2547 provides all of 
> >the necessary mechanisms already to run this type of topology - 
> >deployment of 2547 is a matter of design and no new functionality is 
> >necessary to be able to run the topology you are suggesting. We have 
> >many deployments worldwide that already use this type of design to 
> >provide central services to their customers. This does not mean 
> >however that the topology is appropriate for all 2547 customers. 
> >There are a number of issues with the proposed topology that one 
> >might consider:
> >
> >Miao: Actually it's not a problem of topology, it's for the planning 
> >and design of the network. If 2547 alone can work under for every 
> >network and meet all the VPN requirement, why were VPLS, Martini VPN,

> >Kompella VPN and many others proposed?

well VPLS, Martini and Kompella are talking about layer-2 application -
we are talking about layer-3 here which is a little different wouldn't
you agree ?

> >
> >1. In most real world deployments the number of hops between UPE and 
> >SPE will be > 1. This may introduce unacceptable latency and so on, 
> >especially as the design is being used for transit traffic rather 
> >than central services.
> >
> >from an ingress PE to an egress PE. Actually it follows almost the 
> >same route that 2547 one will do if the network is not very careless 
> >designed.

well I think it is fair to say that if you attract traffic to a
particular point of the network then the optimal path from an routing
perspective is more likely to be overlooked - this is not always the
case but you cannot assume in an architecture that all networks are
built the same.

maybe I misunderstood your description but if the hub has to route
inter-site traffic then we must remove the label stack, look at the IP
address and then send it back on its way - this is a per-packet exercise
not per-site.

> >
> >4. If the SPE is located locally, then aggregates can be injected 
> >down to the UPEs but this is assuming that the address space is 
> >designed in such a way as to allow this aggregation. Most Enterprise 
> >networks today do not have such a well structured addressing plan.
> >
> >Miao: Refer item 3

so item 3 says there is no aggregation and the scheme is rendered
useless.

> >
> >5. By injecting aggregates toward the CE site you change the 
> >customers routing view which may actually require the injection of 
> >more specific routes.
> >

well if it is just default route the same comment applies and is
actually even worse.

> >appropriately at the SPE.

how ? there are many ways to generate such an aggregate, each of which
have their own implications.

> >Miao: Only default route is needed in HoPE at PE-CE links, so why to 
> >run OSPF & IS-IS?

default is not sufficient for most customers - a large subset of
Internet customers today want more than just default route. OSPF, ISIS,
EIGRP and so on were introduced so as to avoid changing the routing view
of the end customers - this is a desired requirement that HoPE does not
service.

> >
> >8. To deploy H&S designs one must use different RTs for the same VPN 
> >and then apply policy to filter correctly. This may not be such a big

> >deal but is a further complication in the provisioning and management

> >9. If our goal is to offload the edge routers from having to carry 
> >VPNv4 routes or run MP-BGP sessions then perhaps we should use the 
> >L2-transport functionality in MPLS to carry the edge traffic to an 
> >SPE. This has the advantage that the CE can exchange routes directly 
> >with the SPE which is useful for other applications.
> >

> >
> >10. How do you take care of customers that want to run Carrier's 
> >Carrier architecture ?
> >

the problem is that you cannot run an end-to-end LSP to allow this type
of architecture to work ..

regards,

> >> >This draft is not to replace 2547, but a supplement to it. 
> >> >Actually the VPN in the draft is completely works under the 
> >> >mechanism of 2547.
> >> >
> >> >deployment, PE will not has so many ports to attach many VPNs if 
> >> >the PE is at the core layer of the network, because core router 
> >> >generally
> >

> >> >主题: RE: 答复: Please Review: A new draft about PPVPN(Hiberarchy
of
> >> >exports either a default or aggregates to attract traffic from 
> >> >other CE-attached PEs and then performs a lookup to forward the 
> >> >packets to other CE-attached PEs .. Jim
> >> >
> >> >> >with
> >> >> >I briefly ran through this draft and it looks like normal hub &

> >> >> >spoke

> >> >> >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy 
> >> >> >> >of PE Device in BGP/MPLS VPN)
> >> >> >> >
> >> >> >> >
> >> >> >> >Hi,all,
> >> >> >> >
> >> >> >> >   In BGP/MPLS VPN area, we proposed a new idea as to 
> >> >> >> >resolve the bottleneck of the capacity of some PEs when 
> >> >> >> >deploy the huge
> >
> >> >> >> >size VPN,the
> >> >> >whole idea is
> >> >> >> >detailed
> >> >> >> >in the attached 
> >> >> >> >   that the current BGP/MPLS VPN model is something of a 
> >> >> >> > "Plane
> >> >Modle"
> >> >> >> >   where the demand of the performance of the PE device are 
> >> >> >> > all
> >> >the
> >> >> >> >   typical network is "Core-Convergence-Access(Edge)" 
> >> >> >> > model,and
> >> >the
> >> >> >> >   One HoPE can be composed of a SPE and UPES connected to 
> >> >> >> > the
> >> >SPE,
> >> >> >> >   or be composed of a high-level SPE and HoPEs connected 
> >> >> >> > the
> >high
> >> >> >> >   level SPE and and build up a new HoPE.This build is 
> >> >> >> > called
> >> >nesting

---

From: "Jim Guichard" <[email-masked]>
Date: Thu, 14 Nov 2002 19:10:23 -0500

Hi Miao,

> >Sent: Wednesday, November 13, 2002 3:38 AM
> >To: 'Jim Guichard'; '?§?è??¨¤?§?'
> >customer want to know that?

and the answer is, sometimes yes, sometimes no. The point is that H&S can
provide this topology if really required, and is indeed deployed in several
networks that I have worked on.

  Anyway, for L3VPN, routing is an add-value
> >Network Management, which is more convinient to customer.

sorry, but I do not get the point you are making ?

> >requirement, it's not cure-all.

exactly.

 However, it's happy to find that most
> >network are planned and setup with a hierachical topology, and where

I would suggest that most networks are NOT built this way - hierarchy in
general is a good thing, I would not argue against this. However, the type
of hierarchy you are describing is most advantageous to the SP and not the
customer as it introduces a number of complications as I described in my
prior email .. Jim

---

From: Miao Fuyou <[email-masked]>
Date: Fri, 15 Nov 2002 09:35:06 +0800

Hi, Jim:

See my comments inline!

Regards

-----Original Message-----
From: Jim Guichard [mailto:[email-masked]] 
Sent: Friday, November 15, 2002 8:10 AM
To: Miao Fuyou; '??ì?¨¨???§?è??ì?'
Cc: [email-masked]
Subject: RE: 答复: 答复: 答复: Please Review: A new draft about

Hi Miao,

> >network views are not available at spoke site. Sure, the sites 
> >connected by HoPE have not whole view of network, but the question 
> >is: really the customer want to know that?

and the answer is, sometimes yes, sometimes no. The point is that H&S
can provide this topology if really required, and is indeed deployed in
several networks that I have worked on.

<Miao> In HoPE, the spoke is UPE, contrastively the spoke is site/CE in
H&S. It makes difference, even if the topologies are similiar. 

<Miao> I mean that routes of VPN are not necesssary to be known by each
sites

> >
> >Note that HoPE works under specific network environment to meet 
> >specific requirement, it's not cure-all.

exactly.

I would suggest that most networks are NOT built this way - hierarchy in
general is a good thing, I would not argue against this. However, the
type of hierarchy you are describing is most advantageous to the SP and
not the customer as it introduces a number of complications as I
described in my prior email .. Jim

<Miao>Agree, actually the solution is most suitable for huge network,
such as SP and gov network, and such networks are what we concern most. 

> >> >understand that hierarchy is one of the tools we have to help 
> >> >scale networks. However, what I am driving at is that 2547 
> >> >provides all of the necessary mechanisms already to run this type 
> >> >of topology - deployment of 2547 is a matter of design and no new 
> >> >functionality is necessary to be able to run the topology you are 
> >> >suggesting. We have many deployments worldwide that already use 
> >> >this type of design to provide central services to their 
> >> >customers. This does not mean however that the topology is 
> >> >appropriate for all 2547 customers. There are a number of issues 
> >> >with the proposed topology that one might consider:
> >> >
> >> >Miao: Actually it's not a problem of topology, it's for the 
> >> >planning and design of the network. If 2547 alone can work under 
> >> >for every network and meet all the VPN requirement, why were VPLS,

> >> >Martini VPN,
> >well VPLS, Martini and Kompella are talking about layer-2 application

> >- we are talking about layer-3 here which is a little different 
> >wouldn't you agree ?
> >
> >> >
> >> >1. In most real world deployments the number of hops between UPE 
> >> >and SPE will be > 1. This may introduce unacceptable latency and 
> >> >so on, especially as the design is being used for transit traffic 
> >> >rather than central services.
> >> >
> >> >Miao: I don't think hops > 1 brings more latency if a packet must 
> >> >go from an ingress PE to an egress PE. Actually it follows almost 
> >> >the same route that 2547 one will do if the network is not very 
> >> >careless designed.
> >

> >inter-site traffic then we must remove the label stack, look at the 
> >IP address and then send it back on its way - this is a per-packet 
> >exercise not per-site.
> >
> >> >

> >how can it if it does not have the routes ? if it has the routes then

> >we have 2547 no ?
> >> >designed in such a way as to allow this aggregation. Most 
> >> >Enterprise networks today do not have such a well structured 
> >> >addressing plan.
> >> >
> >> >Miao: Refer item 3
> >

> >how ? there are many ways to generate such an aggregate, each of 
> >which have their own implications.
> >
> >> >
> >> >7. How do you take care of customers that want to run OSPF or ISIS

> >> >on
> >> >Miao: Only default route is needed in HoPE at PE-CE links, so why 
> >> >to run OSPF & IS-IS?
> >
> >Internet customers today want more than just default route. OSPF, 
> >ISIS, EIGRP and so on were introduced so as to avoid changing the 
> >routing view of the end customers - this is a desired requirement 
> >that HoPE does not service.
> >
> >> >
> >> >8. To deploy H&S designs one must use different RTs for the same 
> >> >VPN and then apply policy to filter correctly. This may not be 
> >> >such a big
> >

> >> >SPE. This has the advantage that the CE can exchange routes 
> >> >directly with the SPE which is useful for other applications.
> >> >
> >the problem is that you cannot run an end-to-end LSP to allow this 
> >type of architecture to work ..
> >
> >regards,
> >
> >> >
> >> >
> >> >regards,
> >> >
> >> >
> >> >> >In the traditional 2547 VPN, only one type of PE is defined. 
> >> >> >When deployment, PE will not has so many ports to attach many 
> >> >> >VPNs if the PE is at the core layer of the network, because 
> >> >> >core router generally
> >> >
> >> >> >doesn't have a lot of physically interfaces.  If the PE is at 
> >> >> >the edge of the network, it will have a lot of interfaces, but 
> >> >> >now the
> >
> >> >> >so can hub&spoke with 2547 - you basically export routes from 
> >> >> >the CE-attached PEs to a hub PE that imports the routes. The 
> >> >> >hub PE exports either a default or aggregates to attract 
> >> >> >traffic from other CE-attached PEs and then performs a lookup 
> >> >> >to forward the packets to other CE-attached PEs .. Jim
> >> >> >

> >> >> >> >lhj@huawei. com; [email-masked]; [email-masked]; Fu 
> >> >> >> >Y. Miao; leh10814@huawei. com; [email-masked]
> >> >> >> >主题: RE: Please Review: A new draft about PPVPN(Hiberarchy
of
> >> >> >> >> >[email-masked]; [email-masked]; [email-masked]; Fu

> >> >> >> >> >Y.
> >> >> >> >> >Subject: Please Review: A new draft about 
> >> >> >> >> >PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN)
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >Hi,all,
> >> >> >> >> >
> >> >> >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and 
> >> >> >> >> >the Abstract is as follows,we are appreciated for your 
> >> >> >> >> >review.
> >> >> >> >> >
> >> >> >> >> >   maintain all the VPN routes of the VPNs which it 
> >> >> >> >> > belong
> >> >> >> >to.When there
> >> >> >> >> >   are many VPNs converged by a PE,and the capacity of PE

> >> >> >> >> > is
> >> >> >relevant
> >> >> >> >> >   limited,then the bottleneck will be 
> >> >> >> >> > encountered.Another problem
> >> >> >is
> >> >> >> >> >   where the demand of the performance of the PE device 
> >> >> >> >> > are all
> >> >> >the
> >> >> >> >> >   performance of the device is superior in Core Layer 
> >> >> >> >> > and
> >> >> >inferior in
> >> >> >> >> >   Access Layer,and the scale of network is large in 
> >> >> >> >> > Access Layer
> >> >> >and
> >> >> >> >> >   Provider Edge Device in BGP/MPLS VPN,where hiberarchy 
> >> >> >> >> > of
> >> >> >Provider
> >> >> >> >> >   Edge Device can be composed of several device and 
> >> >> >> >> > every device
> >> >> >take
> >> >> >> >> >   concentrative PE,we call this model "Hiberarchy 
> >> >> >> >> > Model",In
> >> >> >> >this model
> >> >> >> >> >   PE device in High layer,loose to the PE device in edge

> >> >> >> >> > layer.
> >> >> >> >> >
> >> >> >> >> >   One HoPE can be composed of a SPE and UPES connected 
> >> >> >> >> > to the
> >> >> >SPE,

---

From: Miao Fuyou <[email-masked]>
Date: Fri, 15 Nov 2002 11:52:56 +0800

Dear All:

Here I attached slides to adress the idea of hierarchical PE, wish it
will be helpful for you to understand it!

Best regards
Miao 

-----Original Message-----
From: lidefeng [mailto:[email-masked]] 
Sent: Wednesday, November 06, 2002 12:40 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Fu Y. Miao; [email-masked]; [email-masked]
Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE Device
in BGP/MPLS VPN)

Hi,all,

   In BGP/MPLS VPN area, we proposed a new idea as to resolve the
bottleneck of the capacity of some PEs when deploy the huge size VPN,the
whole idea is detailed in the attached
draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the Abstract is
as follows,we are appreciated for your review.

Regards

Defeng Li

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Nov 2002 12:39:32 +0100

Hi Miao,

Thx for 350 Kb attachment send to this alias :-). 

But it did not addressed the conclusion which I believe we have have
came up offline - so let me resend it to the list. 

The only difference which 2547bis Inter-as option b does not spell out
and what is in turn key to building your model is the installation by
SPE received from UPEs by ext community ORF RTs on the SPE inbound (to
filter from other PEs or vpnv4 RRs). 

I am not even sure why this would not be a vendor specifc knob not
requiring any protocol changes. I think it would be good if you could
spell out what new protocol changes are required before proceeding
further. 

Cheers,
R.

> Miao Fuyou wrote:

---

From: "Jim Guichard" <[email-masked]>
Date: Fri, 15 Nov 2002 18:54:42 -0500

Hi Miao,

> >Sent: Thursday, November 14, 2002 8:35 PM
> >To: 'Jim Guichard'; '??ì?¨¨???§?è??ì?'
> >Subject: RE:Please Review: A new draft about PPVPN(Hiberarchy of

H&S also has the concept of the spoke at the PE-router - each VRF that
attaches a spoke site is a member of the spoke topology. All one has to do
to achieve the required topology is export routes from the spoke VRFs with
an RT value that the hub will import (but not other spokes) and then export
a default/aggregate from the hub toward all spokes with a different RT -
there is nothing more complicated to it than that. Jim

---

From: lidefeng <[email-masked]>
Date: Tue, 19 Nov 2002 10:20:34 +0800

Because the cut-off for Internet-Draft submissions last time, the attached
draft is not included in the Internet Draft Directory，so I send it
again,there is little difference from
the last one except some wording.We hope you can review it.

Thanks & Regards

Defeng Li

----- Original Message -----
From: "Internet Draft Submission Manager" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 06, 2002 12:38 PM
Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE Device
in BGP/MPLS VPN)

> Greetings,
>
> We are sorry, but the cut-off for Internet-Draft submissions was Monday
> November 4 at 9AM ET. Your submission will not be retained (i.e. you
> need to resubmit) after November 17, 2002.
>
> If you receive this announcement, your submission will NOT be processed.
>
> Any submissions received prior to November 18, 2002 will not be retained;
> they must be resubmitted. Internet-Draft submissions received on or after
> November 18 will be processed. However, Internet-Draft announcements will
> not be sent until after the IETF Meeting in Atlanta.
>
> AS you may surmise, this is an extremly busy week. Be advised
> that it may take a number of days to process and announce your
> document. Our goal is to process and announce all valid
> Internet-Draft submissions by November 12 at the latest.
>
> Thank you for your understanding.
>
>
> IETF Secretariat