Subject: [RTG-DIR] RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 14 Feb 2018 09:02:35 +0000

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:   [email-masked]

___________________________________________________________________________

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.
___________________________________________________________________________

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 20 Feb 2018 22:40:50 +0000

Hi Sasha,

Thank you very much for your thorough review.
Revision 09 (posted) addresses all your comments.
Please see in-line for more details.

Thx
Jorge

From: Alexander Vainshtein <[email-masked]>
Date: Wednesday, February 14, 2018 at 10:02 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, February 14, 2018 at 10:02 AM

Hello,

Summary:

Comments:

Minor Issues:

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.
[JORGE] I marked it as updating RFC7432 and explained why in section 2.

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.
[JORGE] I added the following at the end of section 3.3:

   If a PW-based handoff is used, the GW's AC (or point of attachment to
   the EVPN Instance) uses a combination of a PW label and VLAN IDs, as
   opposed to only VLAN IDs as in [RFC7432]. Therefore the [RFC7432]
   mapping definitions of VLAN-based, VLAN-bundle or VLAN-aware bundle
   service interfaces are updated in this document to include the PW
   label as follows:
   o VLAN-Based Service Interface: the AC mapping to the MAC-VRF is
     given by a unique combination of (PW label, optional inner VLAN
     ID). In this context "optional VLAN ID" means a unique combination
     of S/C-TAG or no tag at all. In case of no-tag, the point of
     attachment to the MAC-VRF is strictly based on the PW label and the
     service interface may be referred to as PW-Based Service Interface.
     The rest of the VLAN-Based service characteristics are as per
     [RFC7432].
   o VLAN-Bundle Service Interface: the AC mapping to the MAC-VRF is
     given by a unique combination of (PW label, VLAN ID range),
     where VLAN ID range represents the S/C-TAG values included in a
     range. The rest of the VLAN-Bundle service characteristics are as
     per [RFC7432].
   o VLAN-Aware Bundle Service Interface: the AC mapping to the Bridge
     Table is given by a unique combination of (PW VC label, VLAN ID).
     In this service interface, there are multiple Bridge Tables per
     MAC-VRF, and each point of attachment to a Bridge Table has a
     different (PW label, VLAN ID) combination. The rest of the VLAN-
     Aware Bundle service characteristics are as per [RFC7432].

[JORGE] Done:

<snip>

   The solution specified in this document uses the 'Unknown MAC Route'
   (UMR) which is advertised into a given DC by each of the DC's GWs.
   This route is defined in [RFC7543] and is a regular EVPN MAC/IP
   Advertisement route in which the MAC Address Length is set to 48, the
   MAC address is set to 0, and the ESI field is set to the DC GW's I-
   ESI.
<snip>

   It is worth noting that the UMR usage in [RFC7543] and the UMR usage
   in this document are different. In the former, a Virtual Spoke (V-
   spoke) does not necessarily learn all the MAC addresses pertaining to
   hosts in other V-spokes of the same network. The communication
   between two V-spokes is done through the DMG, until the V-spokes
   learn each other's MAC addresses. In this document, two leaf switches
   in the same DC are recommended to learn each other's MAC addresses
   for the same EVI. The leaf to leaf communication is always direct and
   does not go through the GW.

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.
[JORGE] added this in the introduction:

   The specified procedures are local to the redundant GWs connecting a
   DC to the WAN. The document does not preclude any combination across
   different DCs for the same tenant. For instance, a "Decoupled"
   solution can be used in GW1 and GW2 (for DC1) and an "Integrated"
   solution can be used in GW3 and GW4 (for DC2).

[JORGE] done.

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.
[JORGE] added.
Note that different route-targets for the DC and for the WAN are normally required (unless [RFC4762] is used in the WAN, in which case no WAN route-target is needed).

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?
[JORGE] added:
The I-ES in this case will represent the group of PWs to the WAN PEs and GWs.

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).
[JORGE] I clarified section 4.4.6 and mentioned that the figures don’t show supported ACs.

[JORGE] Done.

Nits:

[JORGE] ok, I changed it to simply specifications in some cases, or lower case “technical specifications”.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 21 Feb 2018 08:04:20 -0500

Hi!

I see that the change below has already been made in -09.  However, I don’t
think that an Update applies in this case.

In general, when Updating another document we’re basically saying: “change
what was specified there for what is specified in here”…which, in this
case, translates to rfc7432 implementations having to also be compliant
with this document (for all cases).  As far as I can tell, the extensions
defined in this document are specific to the DCI case and not general to
any EVPN scenario.  If that is correct then we shouldn’t be formally
Updating rfc7432.

Having said that, Sasha is correct in pointing out that there are several
differences with respect to rfc7432.  That is properly captured in the text
at the end of Section 2 (for the DCI scenario), without the need for the
formal Update.

Thanks!

Alvaro.

On February 20, 2018 at 5:40:59 PM, Rabadan, Jorge (Nokia - US/Mountain
View) ([email-masked]) wrote:

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.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 21 Feb 2018 13:17:02 +0000

Alvaro,
PWs as an a “virtual ES” are also used in conjunction with EVPN in the scenarios that are not directly related to DCI. One example (actually pointed to me by Jorge during the review process) is the EVPN Virtual Ethernet Segment<https://tools.ietf.org/html/draft-sajassi-bess-evpn-virtual-eth-segment-02> draft (now expired).

It is, of course, up to you to decide whether this justifies marking the draft I’ve reviewed as Updating RFC 7432 because it also defined PWs as a (virtual) ES for EVPN. Alternatively, it is possible to wait until the EVPN Virtual segment draft is resuscitated and progressed – but this can take quite some time...

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alvaro Retana [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 3:04 PM
To: Alexander Vainshtein <[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay

Hi!

I see that the change below has already been made in -09.  However, I don’t think that an Update applies in this case.

In general, when Updating another document we’re basically saying: “change what was specified there for what is specified in here”…which, in this case, translates to rfc7432 implementations having to also be compliant with this document (for all cases).  As far as I can tell, the extensions defined in this document are specific to the DCI case and not general to any EVPN scenario.  If that is correct then we shouldn’t be formally Updating rfc7432.

Having said that, Sasha is correct in pointing out that there are several differences with respect to rfc7432.  That is properly captured in the text at the end of Section 2 (for the DCI scenario), without the need for the formal Update.

Thanks!

Alvaro.

On February 20, 2018 at 5:40:59 PM, Rabadan, Jorge (Nokia - US/Mountain View) ([email-masked]<mailto:[email-masked]>) wrote:

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 21 Feb 2018 13:27:47 +0000

Alvaro,
On the same issue:

-          UMR as an EVPN construct has been first defined in RFC 7543

-          RFC 7543 has not been marked as updating RFC 7432, possibly its usage of UMR has been considered as not generic enough

-          Now the EVPN Overlay for DCI draft uses UMR in a context that is different from the original context of RFC 7543.
Taking all these inputs together, which of these documents should be marked as updating RFC 7432? The options are, IMHO:

-          None

-          RFC 7543 (retroactively, possibly following a Erratum report)

-          The EVPN Overlay for DCI draft (and the RFC to which it will hopefully be progressed)

-          Both - but this is clearly superfluous...
What do you think?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Wednesday, February 21, 2018 3:17 PM
To: 'Alvaro Retana' <[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay

Alvaro,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Alvaro Retana [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 3:04 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay

Hi!

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 22 Feb 2018 12:58:56 -0500

Hi!

Sasha: You make a good point: if here are things that this document Updates
rfc7432 on, which are not specific just to the DCI, then we should go ahead
with it.

The current related text reads:

   In particular, the document updates [RFC7432] on several aspects:

   o The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that
     can be associated not only to a set of Ethernet links, as in
     [RFC7432], but also to a set of PWs or other tunnels.

   o The use of the Unknown MAC route in a DCI scenario.

   o The processing of EVPN routes on Gateways with MAC-VRFs connecting
     EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-
     Overlay networks.

Jorge:  Are there extensions defined in this document that are not specific
to the DCI case and that should apply to any EVPN scenario?  If so, can we
update the text to only reflect items that are *not* just DCI-specific?

That is the only outstanding item as the document was otherwise approved by
the IESG today.

Thanks!

Alvaro.

On February 21, 2018 at 8:17:10 AM, Alexander Vainshtein (
[email-masked]) wrote:

PWs as an a “virtual ES” are also used in conjunction with EVPN in the
scenarios that are not directly related to DCI. One example (actually
pointed to me by Jorge during the review process) is the EVPN Virtual
Ethernet Segment
<https://tools.ietf.org/html/draft-sajassi-bess-evpn-virtual-eth-segment-02>
 draft (now expired).

It is, of course, up to you to decide whether this justifies marking the
draft I’ve reviewed as Updating RFC 7432 because it also defined PWs as a
(virtual) ES for EVPN. Alternatively, it is possible to wait until the EVPN
Virtual segment draft is resuscitated and progressed – but this can take
quite some time...