Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.
Document: draft-ietf-bess-dci-evpn-overlay-08
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 14-Feb-18
IETF LC End Date: 09-Feb-18
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved 
before publication.

Comments:
The document is well written, but understanding of both the EVPN technology 
(RFC 7432) and network virtualization basics are mandatory prerequisites for 
the readers. My personal expertise in both these areas is limited, and this may 
affect the quality of the review.

From my POV this draft complements the EVPN 
Overlay<https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-11> draft 
(already approved by the IESG for publication as an RFC): it  discusses 
interaction between the EVPN Overlay within the DC with some options that 
implement L2 connectivity in the WAN that provides the infrastructure for the 
DC interconnect.

I have identified two groups of specifications in the draft:

-          Specifications in the first group explain how the mechanisms already 
defined in other specifications (mainly in RFCF 7432) should be used to provide 
DCI Interconnect that uses EVPN as the overlay within the DC. One example can 
be found in Section 3.5.2 that recommends usage of ARP/ND Proxy cache in the DC 
Gateways to prevent flooding of ARP/ND messages within the DC, many other 
examples can be added

-          Specifications in the second group define new behavior. One example 
is the proposed (in Section 3.5.1) usage of the Unknown MAC Route (UMR) to 
prevent overwhelming the NVEs with the need to learn zillions of MAC addresses 
in the remote DCs.


As part of preparation of this review I have discussed my comments with the 
authors who have been most responsive and cooperative -  so much so that they 
have addressed some of my earlier comments in the latest (-08) version of the 
draft. As a consequence, I had to remove the already addressed comments from 
the final version of my review, and to ask the authors not to post a new 
version before posting of the review.  I would like to express my gratitude to 
the authors and, especially, to Jorge for excellent cooperation.

Major Issues: None found.

Minor Issues:

1.       From my POV this draft should be marked as updating RFC 7432 in its 
metadata. The update should refer to several aspects including at least the 
following:

a.       Use of Ethernet PWs (see Figure 1 in the draft) as an Ethernet 
Segment. RFC 7432 defines Ethernet Segment as a set of Ethernet links that 
connect a customer sit to one or more PEs.

b.       Use of the Unknown MAC Route (UMR). RFC 7432 only says that a PE may 
flood unicast frames with unknown destination MAC to all other PEs but does not 
have to do that, with the decision being a matter of local policy;  it neither 
defines any mechanisms that advertise a specific PE and a specific Ethernet 
Segment attached to this PE as the “default next Hop” for all unknown 
destination MAC addresses, nor prevents usage of such mechanisms.

2.       Definitions of VLAN-based and VLAN bundle-based Ethernet Segments in 
RFC 7432 do not cover the case of PW hand-off between the WAN and DC GW in the 
Decoupled model. While this looks like a straightforward extension, it should 
be clarified in the draft IMO.

3.       The UMR and its encoding (defined in Section 3.5 of this draft) 
already have been defined in RFC 
7543<https://ilptlppjir01:8443/secure/Dashboard.jspa>. I suggest to remove the 
UMR definition from the text and to replace it with a Normative reference to 
RFC 7543. At the same time RFC 7543 and this draft seem to use the UMR 
differently, and these differences should also be clarified in the draft.

4.       The draft presents two DC Interconnect models (shown in Figure 1 and 
Figure 2 respectively): Decoupled Interconnect and Integrated Interconnect. 
These diagrams create an impression that the same model must be used in all the 
interconnected DCs – but this impression is wrong. Actually (clarified that 
with the authors) the model is a local issue between a specific DC GW and WAN, 
so that the same interconnect can use the Decoupled model in the GWs of some 
DCs and Integrated model in the GWs of other DCs.

5.       The EVPN Overlay draft defines two modes for implementing DC 
Interconnect: using DC GWs and using ASBRs. Both models (Decoupled and 
Integrated Interconnect) discussed in this draft are actually sub-models of the 
model of DC Interconnect that uses GWs. The draft actually mentions that, but 
quite late - in the Security Considerations section where I, for one, would not 
be looking for this kind of information at all. I would suggest moving this 
clarification to the Introduction section and only keeping the text that deals 
with the security benefits of the GW-based model in Section 5. (Aside: The 
draft has successfully passed the SecDir review, so I hope that such a change 
would not cause any issues.)

6.       In Section 4.2 the draft discusses Integrated DC interconnect that 
uses VPLS in WAN. It refers to RFC 4761, RFC 4762 and RFC 6074 for the 
definition of VPLS and says (in section 4.2.1) that “different route-targets 
for the DC and for the WAN are usually required.” Since BGP in general and RTs 
specifically are not relevant for VPLS based on RFC 4762, the corresponding 
exception should be added to the text.

7.       In section 4.2.1 the draft also says that “the GWs will be provisioned 
with I-ESI” where I-ESI stands for the Interconnect Ethernet Segment 
Identifier. But this is all about the Integrated Interconnect – so what 
represents  the Interconnect Ethernet Segment (to be identified by I-ESI) in 
this model?

8.       Both Section 4.2.1 and Section 4.4.6 mention a local Attachment 
Circuit (AC) on the DC GW (in the latter case – as one of the advantages of the 
DC Interconnect solution that uses EVPN-MPLS in the WAN). But such ACs are not 
shown in the diagram depicting the Integrated model. Some clarifying text would 
be helpful. In particular, it would be nice to explain why local ACs are 
considered as benefits of the Integrated DC Interconnect solution that uses 
EVPN-MPLS in the WAN if they are also possible in the Integrated DC 
Interconnect solution that uses VPLS (at least as implied by them being 
mentioned in section 4.2.1).

9.       Section 4.6 discussed the Integrated DC Interconnect solution that 
uses EVPN-VXLAN in the WAN. Other encapsulations (e.g., MPLS in GRE) are not 
discussed. It would be nice if the authors could clarify the reasons for 
including one encapsulation and excluding all others.



Nits:

I did not check the draft for typos. I would only like to mention that the 
draft mentions (in several places) “existing Technical Specifications” as if 
they were Royalty - looks a bit exaggerated to me.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   alexander.vainsht...@ecitele.com


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___________________________________________________________________________
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to