[bess] RFC 8365 on A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8365

Title:  A Network Virtualization Overlay Solution 
Using Ethernet VPN (EVPN) 
Author: A. Sajassi, Ed.,
J. Drake, Ed.,
N. Bitar,
R. Shekhar,
J. Uttaro,
W. Henderickx
Status: Standards Track
Stream: IETF
Date:   March 2018
Mailbox:saja...@cisco.com, 
jdr...@juniper.net, 
nabil.bi...@nokia.com,
rshek...@juniper.net, 
utt...@att.com,
wim.henderi...@nokia.com
Pages:  33
Characters: 76766
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-bess-evpn-overlay-12.txt

URL:https://www.rfc-editor.org/info/rfc8365

DOI:10.17487/RFC8365

This document specifies how Ethernet VPN (EVPN) can be used as a
Network Virtualization Overlay (NVO) solution and explores the
various tunnel encapsulation options over IP and their impact on the
EVPN control plane and procedures.  In particular, the following
encapsulation options are analyzed: Virtual Extensible LAN (VXLAN),
Network Virtualization using Generic Routing Encapsulation (NVGRE),
and MPLS over GRE.  This specification is also applicable to Generic
Network Virtualization Encapsulation (GENEVE); however, some
incremental work is required, which will be covered in a separate
document.  This document also specifies new multihoming procedures
for split-horizon filtering and mass withdrawal.  It also specifies
EVPN route constructions for VXLAN/NVGRE encapsulations and
Autonomous System Border Router (ASBR) procedures for multihoming of
Network Virtualization Edge (NVE) devices.

This document is a product of the BGP Enabled Services Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [E] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[DelRegno, Christopher N (Nick)]

Matthew:

I support as co-author.  I am not aware of any IPR related to this draft.
Verizon has been using this capability in our network for some time now.

Thanks,

Nick



Christopher N. “Nick” Del Regno, Fellow

Verizon, Emerging Tech Platforms

700 Hidden Ridge, W02G94

Irving, TX  75038

972-457-5173


On Wed, Mar 28, 2018 at 7:50 AM, Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> This email begins a two-week working group last call for
> draft-ietf-bess-evpn-vpls-seamless-integ-01.txt
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently there is one IPR declaration against this document.
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
> We are also polling for any existing implementations.
>
> The working group last call closes on Wednesday 11th April.
>
>
>
> Regards,
>
> Matthew and Stéphane
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Alexander Vainshtein]

Hi all,
Please see below some technical and editorial comments/question on the draft.

Technical:

1.   Section 3 mentions that integration between VPLS and EVPN is “possible 
(but cumbersome)” even if the brownfield VPLS service instance has been set up 
without BGP-based auto-discovery. I wonder if such integration is possible even 
if the VPLS PEs do not support BGP-based VPLS auto-discovery at all. (Note that 
Section 3.1 says that the VPLS PEs “advertise the BGP VPLS AD route”)

2.   In Section 3.1, the draft says that, if the operator uses the same RT 
for  VPLS AD routes and EVPN routes, “when a (PBB-)VPLS PE receives the EVPN 
Inclusive Multicast route, it will ignore it on the basis that it belongs to an 
unknown SAFI”.  This statement raises two comments:

a.   Should not “will” here be “MUST”?

b.   What if SAFI used for the EVPN Inclusive MC route is known to the 
MP-BGP instance in the VPLS PE (e.g., because some EVPN instance with MAC-VRF 
in this PE has been already set)? I assume that the EVPN Inclusive MC route 
still MUST be ignored, but the basis for that would be that it is not 
understood by the VSI that represents the VPLS instance in this PE

3.   The text in Section 4.2.1 says that if, following MAC move from an 
EVPN PE to a VPLS PE, it initiates BUM traffic, this traffic is flooded to both 
VPLS and EVPN PEs and “the receiving PEs update their MAC tables (VSI or 
MAC-VRF)”. However, Section 3.2 says that MAC addresses received by the EVPN PE 
via PWs from VPLS PEs are “not injected into (PBB-)EVPN MAC-VRF tables but 
rather they are injected into their corresponding (PBB-)VPLS VSI table”. These 
two statements look mutually contradictory to me. (See also my editorial 
comment about having both MAC-VRF and VSI MAC table in the EVPN PE).
Editorial:

1.   Section 2,  item 6 states that “The solution SHOULD support All-Active 
redundancy mode of multi-homed networks and multi-homed devices for (PBB-)EVPN 
PEs. In case of All-Active redundancy mode, the participant VPN instances 
SHOULD be confined to (PBB-)EVPN PEs only”. My reading of this is that 
All-Active redundancy mode is not compatible with seamless integration of VPLS 
and EVPN in the same service (hardly any surprises here). If my understanding 
is correct, All-Active redundancy mode seems to be out of scope for this draft.

2.   RT Constraint is mentioned in Section 3.1 without any references. I 
suggest to add an Informational reference to RFC 4684.

3.   The text about MAC learning from PWs in Section 3.2 seems to suggest 
that the service instance in an (PBB-)EVPN PE is represented by both a 
dedicated MAC-VRF and a dedicated VSI. However, this issue is not explicitly 
presented anywhere in the draft.  Some text and diagrams would be most welcome 
IMHO

4.   Section 3.3.1:  It seems that the title includes some of the content.

5.   Section 3.3.2 has a very long title and no content at all. (For 
comparison, parallel sections 4.3.2 and 5.3.2 have short titles and some 
content each).

6.   In section 4.2.1, a MAC address that moves from an EVPN PE to a VPLS 
PE is not qualified, but a MAC address that moved from a VPLS PE to an EVPN PE 
is referred to as a “host MAC address”. I suggest to align the terminology 
between these two cases.

7.   Abbreviation MHN and MHD appear in Section 6 without any expansion or 
definition. (Looking them up in the Web did not yield anything suitable either).

Hopefully, these comments will be useful, and the authors’ feedback would be 
highly appreciated.

Regards, and lots ofthanks in advance,
Sasha

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

From: Bocci, Matthew (Nokia - GB) [mailto:matthew.bo...@nokia.com]
Sent: Thursday, March 29, 2018 11:48 AM
To: Alexander Vainshtein ; Ali Sajassi 
(sajassi) 
Cc: bess-cha...@ietf.org; draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org; 
bess@ietf.org
Subject: Re: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Thanks for the quick turnaround.

Folks, please focus any further review and comments on the new v02 of the draft:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/

Regards

Matthew

From: Alexander Vainshtein 
>
Date: Thursday, 29 March 2018 at 06:55
To: "Bocci, Matthew (Nokia - GB)" 
>, "Ali Sajassi 
(sajassi)" >
Cc: "bess-cha...@ietf.org" 
>, 
"draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org"
 
>,
 

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

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

Support.
Not aware of any IPR relevant to this document.
Nokia SROS has an implementation of this draft for a few years now.
Thank you,
Jorge

_
From: Bocci, Matthew (Nokia - GB) 
Sent: Wednesday, March 28, 2018 13:50
Subject: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt
To: , 
Cc: 


This email begins a two-week working group last call for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently there is one IPR declaration against this document.
If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.
We are also polling for any existing implementations.
The working group last call closes on Wednesday 11th April.

Regards,
Matthew and Stéphane


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Bocci, Matthew (Nokia - GB)]

Thanks for the quick turnaround.

Folks, please focus any further review and comments on the new v02 of the draft:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/

Regards

Matthew

From: Alexander Vainshtein 
Date: Thursday, 29 March 2018 at 06:55
To: "Bocci, Matthew (Nokia - GB)" , "Ali Sajassi 
(sajassi)" 
Cc: "bess-cha...@ietf.org" , 
"draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org" 
, "bess@ietf.org" 

Subject: Re: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Ali and all,
I have looked up the -02 revision of the draft, and the texr looks much more 
mature now.
I will read it again and send technical comments (if any) next week as well as 
my position regarding its support.
Thumb typed by Sasha Vainshtein


From: Ali Sajassi (sajassi) 
Sent: Thursday, March 29, 2018 7:20:16 AM
To: Alexander Vainshtein; Bocci, Matthew (Nokia - GB)
Cc: bess-cha...@ietf.org; draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org; 
bess@ietf.org
Subject: Re: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Hi Sasha,

Thanks for your comments. I took care of them all in rev02 of the document that 
I just posted.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Wednesday, March 28, 2018 at 7:32 AM
To: "Bocci, Matthew (Nokia - GB)" 
Cc: "bess-cha...@ietf.org" , 
"draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org" 
, "bess@ietf.org" 

Subject: RE: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt
Resent-From: 
Resent-To: Cisco Employee , , 
, 
Resent-Date: Wednesday, March 28, 2018 at 7:32 AM

Matthew, and all,
I’ve looked up the -01 version of the draft and I have found 5 references to a 
future revision of the document (all dealing with either LSM or MAC Mobility 
handling).
These references are in the following sections:

  *   3.3.2  (LSM)
  *   4.2  (MAC mobility)
  *   4.3.2 (LSM)
  *   5.2  (MAC mobility)
  *   5.3.2 (LSM)

BTW, the abbreviation “LSM” is not expanded in the document, and I admit that 
do not know what it means in the context of this draft.

I wonder whether the document in this state is ready for the WG LC because, to 
me, these references indicate that the authors do not consider their work as 
complete.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha

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

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Wednesday, March 28, 2018 3:50 PM
To: draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

This email begins a two-week working group last call for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently there is one IPR declaration against this document.
If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.
We are also polling for any existing implementations.
The working group last call closes on Wednesday 11th April.

Regards,
Matthew and Stéphane

___

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

___

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 

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[stephane.litkowski]

Hi Ali,

This paragraph points that HRW and AC-DF may be USED independently, but this 
does say that a vendor OS may implement HRW or AC-DF or both.
I see two issues if it is not clarified:

-  When an operator pushes a RFP requesting support of this draft, both 
HRW and AC-DF support are defacto required

-  From a WG standpoint, to progress further the document we need an 
implementation that supports fully the draft so both HRW and AC-DF.

My point is really on the implementation side, not on the usage.


Brgds,


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Wednesday, March 28, 2018 18:44
To: LITKOWSKI Stephane OBS/OINIS; Rabadan, Jorge (Nokia - US/Mountain View); 
bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hi Stephane,

In section 2.3, it says that:

Both, HRW and AC-DF MAY be used independently or simultaneously.
 The AC-DF capability MAY be used with the default DF Election
 algorithm too.
Do you want further clarification? If so, please suggest text.

Thanks,
Ali

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Wednesday, March 28, 2018 at 12:50 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
>, 
"bess@ietf.org" >
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Jorge,

More inline

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, March 28, 2018 00:38
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Stephane,

Please see in-line.
Thanks.
Jorge

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Tuesday, March 27, 2018 at 8:48 AM
To: "bess@ietf.org" >
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Authors,

Speaking as a WG member, I have two comments:

-  As I have pointed during the BESS meeting, it would be good to have 
a clear definition of what is a DF type vs a capability.
[JORGE] yes, we can clarify this in the next rev along with any other comments 
made during this LC.


-  I think it would be good to have the draft telling that the 
implementation of HRW and AC-DF are optionals.
[JORGE] Is that necessary? Since the draft is not updating RFC7432, aren’t 
those options implicitly optional for RFC7432 implementations?
[SLI] I was more thinking about people implementing this draft (future RFC). 
Should they implement both HRW and AC-DF ? I don’t think so.


Brgds,

Stephane

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, March 26, 2018 16:21
To: bess@ietf.org
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently no IPR has been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.