Hi, Thanks for your deep level comments. Pls see my reply inline with [weiguo]. Thanks weiguo
________________________________________ 发件人: [email protected] [[email protected]] 代表 Robert Raszuk [[email protected]] 发送时间: 2014年7月8日 7:13 收件人: Haoweiguo 抄送: [email protected] 主题: Re: 答复: Solicit reviews and comments on draft-hao-l3vpn-inter-nvo3-vpn-00 Hi, > between the DC and WAN interfaces without performing an IP lookup. What's wrong with IP lookup per VPN on ASBR ? [weiguo]: This is a inter-as option between NVO3 and MPLS VPN network. When traffic from internal NVO3 network is forwarded to external MPLS VPN network, the ASBR(NVO3 Gateway) terminates into a VRF and performs IP lookup, MPLS encapsulation and then forwards the traffic to MPLS VPN network. This mechanism is called Option-A in the draft. Currently most of the commercial used NVO3 gateways support this solution. In extreme case, 16M VN/Tenants and several million end systems need to be supported in a data center, inter-as option-A solution has following drawbacks: 1.Up to 16 million (16M) gateway interfaces (virtual/physical) and 16M EBGP session(Option-AB can optimize this point to reduce EBGP session) need to exist between the ASBRs. 2.UP to 16M VRFs need to be supported on border routers. 3.Several million routing entries need to be supported on border routers. Are you sure you want to allocate as many VN_IDs as you have VPN prefixes in each VPN and inject all of those into end systems in the DC ? [weiguo]: Assuming the ASBR in NVO3 network is ASBR1, the ASBR in MPLS VPN network is ASBR2. 1. In external to internal DC direction, the route distribution procedures are as follows: On ASBR1, VN ID is allocated per MPLS VPN Label received from peer ASBR2 in MPLS VPN network. If remote PE in MPLS VPN network allocates MPLS VPN Label per VPN, there won't be so many MPLS VPN Label on ASBR2 and so many VN ID on ASBR1. NVEs need to know ASBR1's allocated VN ID to forward traffic data from internal to external DC. 2. In internal to external DC direction, the route distribution procedures are as follows: ASBR1 allocates MPLS VPN Label per NVE per VN(tenant), and then advertise the MPLS VPN Label to peer ASBR2 in MPLS VPN network. When ASBR1 receives traffic data from external to internal DC,ASBR1 looks up NVO3 encapsulation by MPLS VPN Label, then perform NVO3 encapsulation and sends the traffic to destination NVE. Moreover do you think there are advantages to continue to churn your Vn_IDs intra-dc advertisements at the same rate as your WAN L3VPN IP reachability changes say between any of the two PEs for multihomed VPN sites ? [weiguo]: Yes, frequent VPN Label and VN ID advertisements is a issue. To ensure no network fluctuations due to VPN IP prefix changes, MPLS VPN Label had better be allocated per VPN on each PE. In internal to external DC direction, MPLS VPN Label is allocated per VN per NVE, TS creation,deletion and motion won't cause MPLS VPN Label frequent allocation and revotion, or at least to mitigate this issue. I would consider that topology hiding is an advantage not a drawback. [weiguo]: Topology hiding is good, the drawback is the scalability of ASBR. Option-A is suitable to small or medium data center, option-B is more suitable to large scale data center. Note that DC facing ASBR may demux to a VRF on VN_ID basis per VPN (not per VPN prefix), perform again per VPN scoped IP lookup then follow with encapsulating in correct VPN label towards WAN. Pretty simple setup :) [weiguo]: This solution has already been described in the draft as Option-A solution. Thx, R. On Mon, Jul 7, 2014 at 3:23 AM, Haoweiguo <[email protected]> wrote: > Hi Robert, > > In inter-as option-B between NVO3 and MPLS/IP VPN network case, the DC > Gateway router(ASBR in NVO3 network) should perform translation between > VN-IDs and IP VPN labels while forwarding packets between the DC and WAN > interfaces without performing an IP lookup. This draft describes how to set > up VN-ID and MPLS Label mapping relationship on NVO3 network gateway(ASBR). > This is the new point of this draft, and has some difference from > traditional RFC4364 based inter-as option-B solution. > > Thanks > > weiguo > > > > ________________________________ > 发件人: Haoweiguo > 发送时间: 2014年7月2日 11:52 > 收件人: Robert Raszuk > 抄送: [email protected] > 主题: 答复: Solicit reviews and comments on draft-hao-l3vpn-inter-nvo3-vpn-00 > > Hi Robert, > > Currently there is no heterogeneous option-B inter-as solution between NVO3 > and MPLS L3VPN network, only option-A inter-as solution is provided in > mainstream NVO3 solution. This draft mainly discribes the procedures of NVO3 > distributed gateway integrated with inter-as option-B solution, it can > provide directions for open source or commercial implementations. > > Pls see my detail reply inline [weiguo]. > > Thanks > > weiguo > > ________________________________ > 发件人: [email protected] [[email protected]] 代表 Robert Raszuk > [[email protected]] > 发送时间: 2014年7月2日 1:21 > 收件人: Haoweiguo > 抄送: [email protected] > 主题: Re: Solicit reviews and comments on draft-hao-l3vpn-inter-nvo3-vpn-00 > > Hi Weiguo, > > I have read your document with interest expecting to see something new .. > well I have not seen anything which other L3VPN documents would not have > already covered. > > Section 4 lists 16 million number as issue of option A. Can you explain > where in option A architecture such number is stated ? > As to the number of sessions issue between ASBRs I would recommend lecture > of draft-mapathak-interas-ab-00.txt > [weiguo]:Because theoretically 16M VN are supported in a NVO3 network, if > centralized layer 3 gateway and inter-as option-A solution is used, then 16M > sub-interfaces should be supported on each ASBR. VPN traffic separation > still relies on VLAN. > In draft-mapathak-interas-ab-00,EBGP session can be greatly reduced, but I > don't know how can you separate different VPN's traffic? Does it still > relies on VLAN or sub-interface? > > Bottom line I am not finding anything new in this document which would not > be already well known or even shipping in open source or commercial > implementations. > [weiguo]: > > The difference from traditional RFC 4364 inter-as option-B are as follows: > > > > Internal DC to external DC direction routing distribution procedures: > > ASBR1 allocates MPLS VPN Label per tenant (VN ID) per NVE, the incoming > forwarding table on ASBR1 is as following: > > +--------------------+------------------+ > > | MPLS VPN Label | NVE + VN ID | > > +--------------------+------------------+ > > | 1000 | NVE1 + 10 | > > +--------------------+------------------+ > > | 2000 | NVE1 + 20 | > > +--------------------+------------------+ > > > > > > External DC to internal DC direction routing distribution procedures: > > ASBR1 allocates VN ID for each VPN Label receiving from ASBR2, The outgoing > forwarding table on ASBR1 is as follows: > > +------------------+--------------------+ > > | VN ID | Out VPN Label | > > +------------------+--------------------+ > > | 10000 | 3000 | > > +------------------+--------------------+ > > | 10001 | 4000 | > > +------------------+--------------------+ > > > > In this scenario, VN ID has local significance and is similar to MPLS Label, > it's different from VN usage in NVO3 network, in NVO3 network VN has network > wide globally significance. > > > > Also, NVO3 support NVE-NVA architecture, in this architecture, NVA should > support inter-as option-B function, the forwarding table on ASBR and NVEs > are downloaded through NVA. > > > Best regards, > R. > > > On Tue, Jul 1, 2014 at 3:29 AM, Haoweiguo <[email protected]> wrote: >> >> Hi all, >> We submit a new draft of "Inter-AS Option B between NVO3 and BGP/MPLS IP >> VPN network", please review it and warmly appreciate your comments and >> suggestions. >> Thanks >> weiguo > > >
