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

[Alvaro Retana]

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 (
alexander.vainsht...@ecitele.com) 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

 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...
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Alexander Vainshtein]

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
Email:   alexander.vainsht...@ecitele.com

From: Alvaro Retana [mailto:aretana.i...@gmail.com]
Sent: Wednesday, February 21, 2018 3:04 PM
To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; Rabadan, Jorge 
(Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Cc: draft-ietf-bess-dci-evpn-overlay@ietf.org; rtg-...@ietf.org; 
rtg-...@ietf.org; bess@ietf.org
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) 
(jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>) 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.
[JORGE] I marked it as updating RFC7432 and explained why in section 2.


___

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

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

[Alvaro Retana]

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) (jorge.raba...@nokia.com) 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.

[JORGE] I marked it as updating RFC7432 and explained why in section 2.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Alexander Vainshtein]

Hi all,
I’ve looked the -09 version of the draft and it addresses all the issues raised 
in my RTG-Dir Telechat review.

Lots of thanks to the authors for excellent cooperation.

Regards,
Sasha

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

From: Alexander Vainshtein
Sent: Wednesday, February 14, 2018 11:03 AM
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; 'draft-ietf-bess-dci-evpn-overlay@ietf.org' 
; 'bess@ietf.org' 
Subject: RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay

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

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

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 
Date: Wednesday, February 14, 2018 at 10:02 AM
To: "rtg-...@ietf.org" 
Cc: "rtg-...@ietf.org" , 
"draft-ietf-bess-dci-evpn-overlay@ietf.org" 
, "bess@ietf.org" 
Subject: RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay
Resent-From: 
Resent-To: , , 
, , , 
, , 
, , , 

Resent-Date: Wednesday, February 14, 2018 at 10:02 AM

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