Hi Weiguo,
My apologies but I don’t get what you think I missed :-)
draft-rabadan-bess-dci-evpn-overlay describes a gateway solution that does not
match an RFC4364-“equivalent" model (*)
draft-ietf-bess-evpn-overlay-00 describes an Inter-AS solution that matches an
RFC4364-“equivalent” model-B.
(*) Model A means MAC-VRF to MAC-VRF connected through sub-interfaces, i.e.
attachment circuits. This is only the case in section 2.2 of the decoupled
model. The rest of the sub-models do not match this description. In particular,
one of the models: section 3.4 EVPN-MPLS interconnect for EVPN-Overlay
networks, uses EVPN at both sides:
* This is in no way model A, since a) MP-BGP is used at both sides, to the
DC RR and to the WAN RR and b) no sub-interfaces are used to get connected to
the WAN PEs.
* A MAC-VRF is instantiated in the GW due to the requirements explained in
the document.
* We are not comparing the scalability of this solution vs the Inter-AS
solution explained in draft-ietf-bess-evpn-overlay-00. We are just providing a
needed solution given the stated requirements.
* It is understood that this requires MAC lookup hence storing MACs in the
FIB, but has many other advantages over an inter-AS model B solution. For
instance:
* It provides protection/isolation to the DC (control over the
advertised MACs, proxy-ARP/ND, unknown-mac-route)
* Allows local ACs
* Label aggregation: in model B the GW advertises to the WAN a label per
NVE per MAC-VRF and the other way around (a label per PE per MAC-VRF to the
DC). In our model a single label is advertised per MAC-VRF to the WAN and the
other way around. So from the label perspective, it helps scaling the DC and
the WAN network more than model B.
* Also provides WAN and DC independency in terms of inclusive multicast
trees, MAC mobility and other procedures.
Some slides about it:
http://www.ietf.org/proceedings/89/slides/slides-89-l2vpn-2.pdf
Thanks.
Jorge
From: Haoweiguo <[email protected]<mailto:[email protected]>>
Date: Friday, November 14, 2014 at 3:14 PM
To: Jorge Rabadan
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: 答复: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00
Hi Joege,
Sorry, may be you missed it. Your discription is Option-A solution between NVO3
GW and EVPN PE, not Option-B solution. In option-B case, no MAC VRFs are
required on GW, only VN ID and MPLS VPN Label switching is needed, it has
bettter scalability than option-A.
Thanks
weiguo
________________________________
发件人: BESS [[email protected]<mailto:[email protected]>] 代表 Rabadan,
Jorge (Jorge)
[[email protected]<mailto:[email protected]>]
发送时间: 2014年11月15日 1:23
收件人: Haoweiguo; [email protected]<mailto:[email protected]>
主题: Re: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00
Weiguo,
In-line [JORGE2].
Thanks.
From: Haoweiguo <[email protected]<mailto:[email protected]>>
Date: Friday, November 14, 2014 at 1:08 AM
To: Jorge Rabadan
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: [bess] 答复: Comments on draft draft-rabadan-bess-dci-evpn-overlay-00
Hi Jorge,
Please see inline with [weiguo2].
Thanks
weiguo
________________________________
发件人: Rabadan, Jorge (Jorge)
[[email protected]<mailto:[email protected]>]
发送时间: 2014年11月13日 16:42
收件人: Haoweiguo; [email protected]<mailto:[email protected]>
主题: Re: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00
Hi Weiguo,
Please see in-line.
From: Haoweiguo <[email protected]<mailto:[email protected]>>
Date: Wednesday, November 12, 2014 at 11:09 PM
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: [bess] Comments on draft draft-rabadan-bess-dci-evpn-overlay-00
Hi Co-authors,
In today's BESS meeting, i have some comments, pls allow me to reiterate here.
1. EVPN supports mass MAC withdraw when local PE link failure occurs. If EVPN
is used for NVO3 network interconnecting, if a local NVE occurs node failure,
local DCI PE how to notify remote PEs to flush MAC table in mass mode, because
in this case, there maybe many TS's MAC attached to the local NVE, mass MAC
withdraw should be supported to provide MAC withdraw efficiecy.
[JORGE] If you are talking about the EVPN-MPLS interconnect model, if there is
a failure in one of the ESIs at an NVE, the NVE will withdraw the A-D per ESI
route and the DC GWs will do mass withdraw. That is perfectly supported. The
NVE ESI A-D route updates/withdraw don’t have to be exported to the WAN PEs.
[weiguo2]: Sorry, it's my mistake, too many similar drafts. In the draft no
this issue. in your draft data center network is NVO3+EVPN, control plane mac
learning is used. There is another draft, NVO3 uses data plane MAC learning, no
EVPN protocol is running within data center network, in this case NVE occurs
link or node failure, no MASS mac withdraw mechanism.
2. For EVPN multi-homing, DF is elected per I-ESI, can you ensure BUM traffic
load balancing among multiple PEs?
[JORGE] See the procedures in section 3.4.3.
[weiguo2]: Yes, It can realize per EVI loadbalancing.
3. If DC GW and WAN PE are separated device, Option-B solution should be
supprted to ensure scalability, Option-A (In your draft, it is called vlan
hand-off)has two much scalability limitations.
[JORGE] The decoupled model assumes separate admin entities in WAN and DC,
hence you need a clear demarcation hand off for security and QoS, etc. Of
course the decouple vs integrated model described in the draft have pros and
cons, but both are required. Option B is described in
http://tools.ietf.org/html/draft-sd-l2vpn-evpn-overlay-03
For unicast traffic, the DC GW should support VN ID and MPLS VPN Label
switching. VN ID and MPLS VPN Label at WAN PE assign machanism also should be
specified. For BUM traffic, the DC GW should stitch the multicast tree within
data center and the multicast tree in WAN network.
The description is too simple in your draft, in our previous drafts, the
option-B solution is described in detail, your reading are welcomed.
http://datatracker.ietf.org/doc/draft-hao-l2vpn-inter-nvo3-evpn/
http://ietfreport.isoc.org/idref/draft-hao-l3vpn-inter-nvo3-vpn/
[JORGE] If you refer to section 3.4, all the procedures which are *different
from EVPN* are described in the draft in my opinion. I don’t think EVPN
procedures have to be explained here, but let us know if there is something
specific that can be subject to different interpretations.
[weiguo2]: Option-B solution only applies for decouple model. I think the
solution in your referrence is not clear, if you have spare time, pls read the
above two drafts. VN ID and MPLS VPN Label assigning principle, how to stitch
service layer including unicast and multicast are all described in detail.
Thanks.
[JORGE2] To be clear, this draft does not talk about option B. That is
explained in the evpn-overlay draft. This draft defines a gateway function,
where a MAC-VRF is instantiated in the GW, i.e. a MAC lookup is required. As
such, stitching and translations VNI to VNI or VNI to MPLS label are all fully
supported. The VNIs or MPLS labels are locally allocated and there are no
dependencies because we always do a MAC lookup. Can you please let us know what
exactly is not clear?
Another comment: the decouple vs integrated thing is terminology of this draft
and it is not used anywhere else, and IMO it does not make sense when talking
about option B.
In my today's Option-C presentation, transport layer stitching mechanism is
described. Option-B solution should support service layer stitching, the
mechansim also should be fully described.
[JORGE] As discussed, personally I think I understand your solution but at the
moment I haven’t seen any use-case for such complex architecture. I have only
seen use cases for model B or for the GW model described in the
dci-evpn-overlay draft.
[weiguo2]: Currently NVO3 networks have not been widely deployed, so you
haven't seen any usecases for option-C. But maybe in the future, it will be
used, because it is a equivalent solution of vanilla option-C in RFC4364.
Thanks
weiguo
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
