Subject: Re:RE:RE:RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN)

From: Du Wenhua <[email-masked]>
Date: Mon, 11 Nov 2002 15:34:41 +0800

Hi,Miao Fuyou,

   I appreciate this draft on account of the following reasons:
(1) Hold quite a big advantage over expansibility.
(2) There exist no cross-operation problems between diffrent vendors. It is not necessary to recompose the protocols between the equipment. The rework lies in the inner SPE, which does not affect the communication between the equipment. So as for the other PEs, SPE is a standard PE of RFC2547bis. 
(3). Do not need to recompose the data panel of the current equipment.
(4). Once recomposing the control panel, a PE equipment will become a SPE equipment. 
(5). It can construct many variable topologies by nest of HoPE, such as tree、partial mesh.

    Other methods can achieve the goal also, such as Hub&spoke, L2-transport.
    Hub&spoke is more simple, but it's topology is not flex enough(only surport two stages?) .
    In L2-transport, U-PE or MTU does not need BGP at all, it is low price, i.e ethernet switch. But,the data pannel of N-PE or SPE is more complicated. It must -route- IP packet over ethernet over PWE3, i.e L2TPv3, marteni-draft based tunnel. As I known, many devices can only  bridge PWs，can not route. 
    L2-tranport consume more cost of bandwith(a PWE3 header, a ethernet header, about 20-btye).
    In HoPE, it requre additional IP address lookups between ingress PE and egress PE, plus label disposition/imposition. IMHO, it is not a issue. Many device in the market can  pop 3 labeles, then look up IP long match, then push 4 labeles at wire speed.
    So,both can do, just like we need a sedan and a van.

Yours   
　　　　　　　　Du Wenhua
　　　　　　　　[email-masked]
　　　　　　　　　　2002-11-11

>-----Original Message-----
>From: Miao Fuyou <[email-masked]>
>Sent: 17:01:00,2002-11-09
>To: 'Jim Guichard' <[email-masked]>
>Subject: 答复: 答复: 答复: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN)

>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.
>
>2. Using this method introduces additional IP address lookups between
>ingress PE and egress PE, plus label disposition/imposition.
>
>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
>
>5. By injecting aggregates toward the CE site you change the customers
>routing view which may actually require the injection of more specific
>routes. 
>
>Miao: No aggretes injected in HoPE actually
>
>6. The SP has to keep track of the aggregation and configure it
>appropriately at the SPE. 
>
>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. 
>
>10. How do you take care of customers that want to run Carrier's Carrier
>architecture ?
>
>Miao: But, what is the problem?
>
>
>regards,
>
>
>> >-----Original Message-----
>> >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]; [email-masked]; [email-masked]; 
>> >[email-masked]
>> >Subject: 答复: 答复: Please Review: A new draft about
>PPVPN(Hiberarchy of 
>> >PE Device inBGP/MPLS VPN)
>> >
>> >
>> >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
>> >
>> >> >-----Original Message-----
>> >> >From: 李斌 [mailto:[email-masked]]
>> >> >Sent: Thursday, November 07, 2002 2:42 AM
>> >> >To: Jim Guichard
>> >> >Cc: [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]
>> >> >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
>> >> >
>> >> >-----原始邮件-----
>> >> >发件人: 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)
>> >> >
>> >> >
>> >> >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 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
>> >> >> >
>> >
>> >
= = = = = = = = = = = = = = = = = = = =