Hi Robert,
Your illustration is very clear. Your model is centralized NVO3 gateway +
Inter-as Option-B, our model in the draft is distributed NVO3 gateway +
Inter-as Option-B.
Your model is very good and easy to be deployed, it will be a great
complementary to this solution.
In your model PE2 have all VRFs of the data center. For the traffic data from
NVO3 side to MPLS VPN side, VRF is selected based on VN ID. For the traffic
data from MPLS VPN side to NVO3 side, VRF is selected based on MPLS VPN Label
instead of sub-interface between ASBRs.
In our model , gateway is located on each NVE instead of on the PE2/ASBR, VRF
is located on each NVE, only VN ID and MPLS VPN Label switching table exists on
the ASBR, VRF don't need to be setup on the ASBR.It is more similar to vanilla
inter-as Option-B.
Thanks
weiguo
________________________________________
发件人: [email protected] [[email protected]] 代表 Robert Raszuk [[email protected]]
发送时间: 2014年7月8日 20:56
收件人: Haoweiguo
抄送: [email protected]
主题: Re: 答复: 答复: 答复: Solicit reviews and comments on
draft-hao-l3vpn-inter-nvo3-vpn-00
Hi Weiguo,
> In this email, your model are clearly described
I don't think so based on your reply. Your interpretation is
completely unrelated to my model :) Sorry.
Let me try to illustrate:
Data Center
WAN
VMs/namespaces
hypervisor + kernel (PE1)
compute node
|
|
--------------------- PE2/ASBR --- option B --- ASBR
------------- PE3
I am describing PE2/ASBR network element where you combine plain
option B with the VRF select based on VN_ID PE.
DC can be operated by any provider so can WAN. Those are completely
not related to each other except agreement to establish L3VPN option B
peering session between corresponding ASBRs.
PE2 is acting as WAN side aggregator on a per VRF basis. There is no
option A in this model anywhere.
L3 VPN architecture does not provide such model hence perhaps you were
trying to map it to something which does not really exist in any RFC
document and this was the src of your confusion.
I suggest if you want to build scalable interconnect between DC based
virtualized resources and arbitrary WAN you use this model. Of course
for completenss such mode must also provide independent access from
Internet either plain or over IPSec, but I assume this is obvious and
here we are only focusing on hybrid L3 VPN interconnect case.
PE1 may be just a data plane or it could be also control plane and
data plane. The choice there is flexible.
Hopefully with the picture this is more clear now.
Regards,
R.
On Tue, Jul 8, 2014 at 12:11 PM, Haoweiguo <[email protected]> wrote:
>
> Hi Robert,
> Thanks for your clear description.
>
> In this email, your model are clearly described, it's different from the
> model in our draft. In your model, NVO3 gateway and PE are integrated in a
> single device. In our model, NVO3 gateway and PE are two independent devices.
> If data center network and MPLS VPN WAN network belongs to two different
> companies (for example, data center network belongs to Microsoft, MPLS VPN
> network belongs to AT&T), NVO3 gateway and PE function normally are splitted
> into two devices instead of integrating into single device. In this case,
> inter-as solution between NVO3 gateway and PE should be used, there are two
> solutions of Option-A and Option-B. In this draft, Option-B solution is
> described in detail.
>
> Pls see my other replies inline with [weiguo].
>
> Then the draft is wrong as Option-A does not use any MPLS encapsulation.
> [weiguo]. Sorry, it's a slip of the pen. Yes, Option-A has no MPLS
> encapsulation, native IP forwarding is used between ASBRs. Every VPN people
> should know the procedures.
> The correct description is:
> 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, then forwards the traffic to
> peer ASBR. This mechanism is called Option-A in the draft.
>
> You are confusing on which side of ASBR VRFs sit. I am describing the
> model where ASBR is an option-B ASBR with in the same time integrated
> PE towards the DC side. There is no option A.
> [weiguo]: I understand what's your meaning now, we are not discussing the
> same scenario. In your description, PE and NVO3 gateway are integrated in a
> single device, so no Option-A here. If MPLS VPN network and data center
> network belongs to same company(such as AT&T, china telecom, and etc), your
> model are suitable, PE and NVO3 gateway are integrated on same device, VN ID
> is bounded to a VRF on the device.
> In our draft, PE and NVO3 gateway are splitted into two devices, PE belongs
> to carrier network(such as china telecom, AT&T,and etc), NVO3 gateway belongs
> to data center(such as Facebook, Microsoft, Tencent, and etc), in this case
> inter-as Option-A or Option-B solution should be used. In this case, NVO3
> gateway in data center is ASBR1, PE in carrier network is ASBR2. If
> sub-interface is used to separate VPN traffic between ASBR1 and ASBR2, the
> solution is Option-A. If MPLS VPN Label is used to separate VPN traffic
> between ASBR1 and ASBR2, it is Option-B solution, the procedures is described
> in detail in this draft.
>
> Note also for clarity that packets are arriving at such PE from DC
> side not traditionally based on bounding to interface to a VRF but
> based on VN_ID bounding to a VRF. Some vendors call this "vrf select"
> mode.
> [weiguo]: Yes, in your model, bounding interface to VRF isn't needed, only VN
> ID bounding to VRF exists.
>
> Sorry if this model/architecture was not clear in my former mail.
> [weiguo]: I understand your model now, your model are different from the
> model described in our draft.
>
> Thanks
> weiguo
> ________________________________________
> 发件人: [email protected] [[email protected]] 代表 Robert Raszuk
> [[email protected]]
> 发送时间: 2014年7月8日 17:06
> 收件人: Haoweiguo
> 抄送: [email protected]
> 主题: Re: 答复: 答复: Solicit reviews and comments on
> draft-hao-l3vpn-inter-nvo3-vpn-00
>
> Hi Weiguo,
>
>
>> 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.
>
>
> Then the draft is wrong as Option-A does not use any MPLS encapsulation.
>
>
> You are confusing on which side of ASBR VRFs sit. I am describing the
> model where ASBR is an option-B ASBR with in the same time integrated
> PE towards the DC side. There is no option A.
>
> Note also for clarity that packets are arriving at such PE from DC
> side not traditionally based on bounding to interface to a VRF but
> based on VN_ID bounding to a VRF. Some vendors call this "vrf select"
> mode.
>
> Sorry if this model/architecture was not clear in my former mail.
>
>
>> 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:
>
> I am not talking about option A so the following list does not apply.
> Moreover each solution needs to scale and I would not put any hard
> limit regardless what it is.
>
> So if particular box reaches its capacity you add another box to act
> as a gateway. That's it.
>
>
>> On ASBR1, VN ID is allocated per MPLS VPN Label received from peer
>> ASBR2 in MPLS VPN network.
>
> That is very inefficient and I would argue that architecturally wrong.
> This puts all the WAN churn and load towards all compute nodes which
> just does not belong there and brings no value.
>
>> If remote PE in MPLS VPN network allocates MPLS VPN Label per VPN,
>
> There is no such a thing. At best you can allocate a VPN label per PE
> per VRF, but this would require a lot of reconfiguration of the entire
> WAN L3VPN network which may not be welcome by number of providers.
>
> Best regards,
> R.
