[bess] RFC 8317 on Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)

[rfc-editor]

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


RFC 8317

Title:  Ethernet-Tree (E-Tree) Support in Ethernet 
VPN (EVPN) and Provider Backbone Bridging 
EVPN (PBB-EVPN) 
Author: A. Sajassi, Ed.,
S. Salam,
J. Drake,
J. Uttaro,
S. Boutros,
J. Rabadan
Status: Standards Track
Stream: IETF
Date:   January 2018
Mailbox:saja...@cisco.com, 
ssa...@cisco.com, 
jdr...@juniper.net, 
ju1...@att.com, 
sbout...@vmware.com,
jorge.raba...@nokia.com
Pages:  23
Characters: 53519
Updates:RFC 7385

I-D Tag:draft-ietf-bess-evpn-etree-14.txt

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

DOI:10.17487/RFC8317

The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service
known as Ethernet-Tree (E-Tree).  A solution framework for supporting
this service in MPLS networks is described in RFC 7387, "A Framework
   
for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label   
   
Switching (MPLS) Network".  This document discusses how those
functional requirements can be met with a solution based on RFC 7432,
"BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a
description of how such a solution can offer a more efficient
implementation of these functions than that of RFC 7796,
"Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)".
This document makes use of the most significant bit of the Tunnel Type
field (in the P-Multicast Service Interface (PMSI) Tunnel attribute)
governed by the IANA registry created by RFC 7385; hence, it updates
RFC 7385 accordingly.

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] WG Last Call (including implem status) for draft-ietf-bess-evpn-ac-df

[Satya Mohanty (satyamoh)]

Yes, this will be consistent with the existing framework.

Thanks,
—Satya

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Wednesday, January 31, 2018 at 12:55 AM
To: "jdr...@juniper.net" 
>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" >, 
"Van De Velde, Gunter (Nokia - BE/Antwerp)" 
>, 
"bess@ietf.org" >, 
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
 
>
Subject: Re: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Hi John,

Speaking as doc shepherd for the ac-df draft, I agree that this make sense and 
this will provide more backward compatibility with the behavior defined in 
RFC7432.

Brgds,

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Tuesday, January 30, 2018 17:17
To: Rabadan, Jorge (Nokia - US/Mountain View); Van De Velde, Gunter (Nokia - 
BE/Antwerp); LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: RE: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Hi,

The HRW DF election draft defines a new extended community, the DF Election 
Extended Community 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-03#section-7), 
which contains a DF election type registry.  Why don’t we define a value for 
AC-based DF election and have the PEs supporting it advertise the extended 
community w/ that value and either  include a normative reference to the HRW 
draft or move the extended community and the text describing its usage to the 
AC-based election draft?

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Tuesday, January 30, 2018 10:28 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
>; 
stephane.litkow...@orange.com; 
bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: Re: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Hi Gunter,

Thanks for the feedback.
About this:
I was wondering why this document, even though being backward compatible with 
RFC7432, is Informational track, and not standard track.

I just sent an email providing the initial reasoning discussed among the 
authors. If we still think Standards Track is more appropriate, I think it is 
ok to change it.

Thank you.
Jorge



From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
>
Date: Tuesday, January 30, 2018 at 10:46 AM
To: "stephane.litkow...@orange.com" 
>, 
"bess@ietf.org" >, 
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
 
>
Subject: RE: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df
Resent-From: >
Resent-To: >, 
>, 
>, 
>, 
>, 
>
Resent-Date: Tuesday, January 30, 2018 at 10:46 AM

I support progress and publish as RFC.

The document is well written and resolves with a reasonable approach logical 
failures or human errors, that would otherwise result in significant service 
problems.
I was wondering why this document, eventhough being backward compatible with 
RFC7432, is Informational track, and not standard track.

G/

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, January 29, 2018 09:27
To: bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: [bess] WG Last Call (including implem status) for 

Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Eric C Rosen]

Thanks for delving into the details here.  This part of the writeup is 
very confusing (for which I have no one to blame but myself); I've tried 
to clarify in the -06 revision.


On 1/18/2018 9:51 PM, Xiejingrong wrote:


Issue clarification:

According to chap 5.2 of this document:

In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a 
Wildcard S-PMSI(*,*) route with PTA(flag), whose NLRI is 
donated as  SPMSI(type<0/1/2>RD,*,*,IngressPE).


This SPMSI route will be relayed by EgressABR to EgressPE with PTA 
flag untouched.




The flags are required to be left untouched only if the PTA specifies 
"no tunnel info".


Then EgressPE will generate ONE LeafAD route with 
NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT, and 
N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT.


Then according to chap 5.3  of this document:

EgressABR will only send a Leaf A-D route.

I guess, the said “a Leaf A-D route” should be the ONE of 
LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT.


Then how should EgressABR deal with the the N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT ?


It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which 
only clarify LeafAD route with type<0/1/2>RD.


Should such LeafAD route with type<16/17/18>RD be accepted and 
installed by EgressABR ?


And then ‘relay’ back to IngressPE, and thus enable IngressPE explicit 
tracking inside the ingress “segmentation domain” ?




EgressABR originates Leaf A-D routes of its own if and when it knows 
that it has downstream receivers that are interested in receiving flows 
from IngressPE.  It may originate more than one Leaf A-D route if LIR-pF 
is set in the S-PMSI A-D route's PTA.



Question clarification:

(1)Should such LeafAD routes with type<16/17/18>RD be accepted and 
installed by EgressABR ? This draft does not describe this.




If such routes carry EgressABR's import RT, and if their NLRIs match the 
NLRI of an S-PMSI A-D route installed by EgressABR, the Leaf A-D routes 
will be accepted and installed by EgressABR.  They are also relayed 
upstream (after changing the RT), as described in section 5.3.


(2)If the said Leaf A-D routes (with RD type 16/17/18) be installed by 
EgressABR, then according to your answer, the Leaf A-D routes (with RT 
changed) will be ‘relay’ back to IngressPE. Right?  This draft does 
not describe this either.


(3)If the above two are correct, then We can use 

[bess] I-D Action: draft-ietf-bess-mvpn-expl-track-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Explicit Tracking with Wild Card Routes in Multicast 
VPN
Authors : Andrew Dolganow
  Jayant Kotalwar
  Eric C. Rosen
  Zhaohui Zhang
Filename: draft-ietf-bess-mvpn-expl-track-06.txt
Pages   : 16
Date: 2018-01-31

Abstract:
   The MVPN specifications provide procedures to allow a multicast
   ingress node to invoke "explicit tracking" for a multicast flow or
   set of flows, thus learning the egress nodes for that flow or set of
   flows.  However, the specifications are not completely clear about
   how the explicit tracking procedures work in certain scenarios.  This
   document provides the necessary clarifications.  It also specifies a
   new, optimized explicit tracking procedure.  This new procedure
   allows an ingress node, by sending a single message, to request
   explicit tracking of each of a set of flows, where the set of flows
   is specified using a wildcard mechanism.  This document updates
   RFC6625.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-06
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[bess] I-D Action: draft-ietf-bess-mvpn-expl-track-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Explicit Tracking with Wild Card Routes in Multicast 
VPN
Authors : Andrew Dolganow
  Jayant Kotalwar
  Eric C. Rosen
  Zhaohui Zhang
Filename: draft-ietf-bess-mvpn-expl-track-05.txt
Pages   : 16
Date: 2018-01-31

Abstract:
   The MVPN specifications provide procedures to allow a multicast
   ingress node to invoke "explicit tracking" for a multicast flow or
   set of flows, thus learning the egress nodes for that flow or set of
   flows.  However, the specifications are not completely clear about
   how the explicit tracking procedures work in certain scenarios.  This
   document provides the necessary clarifications.  It also specifies a
   new, optimized explicit tracking procedure.  This new procedure
   allows an ingress node, by sending a single message, to request
   explicit tracking of each of a set of flows, where the set of flows
   is specified using a wildcard mechanism.  This document updates
   RFC6625.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-05
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [bess] WG Last Call (including implem status) for draft-ietf-bess-evpn-ac-df

[stephane.litkowski]

Hi John,

Speaking as doc shepherd for the ac-df draft, I agree that this make sense and 
this will provide more backward compatibility with the behavior defined in 
RFC7432.

Brgds,

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Tuesday, January 30, 2018 17:17
To: Rabadan, Jorge (Nokia - US/Mountain View); Van De Velde, Gunter (Nokia - 
BE/Antwerp); LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: RE: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Hi,

The HRW DF election draft defines a new extended community, the DF Election 
Extended Community 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-03#section-7), 
which contains a DF election type registry.  Why don’t we define a value for 
AC-based DF election and have the PEs supporting it advertise the extended 
community w/ that value and either  include a normative reference to the HRW 
draft or move the extended community and the text describing its usage to the 
AC-based election draft?

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Tuesday, January 30, 2018 10:28 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
>; 
stephane.litkow...@orange.com; 
bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: Re: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Hi Gunter,

Thanks for the feedback.
About this:
I was wondering why this document, even though being backward compatible with 
RFC7432, is Informational track, and not standard track.

I just sent an email providing the initial reasoning discussed among the 
authors. If we still think Standards Track is more appropriate, I think it is 
ok to change it.

Thank you.
Jorge



From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
>
Date: Tuesday, January 30, 2018 at 10:46 AM
To: "stephane.litkow...@orange.com" 
>, 
"bess@ietf.org" >, 
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
 
>
Subject: RE: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df
Resent-From: >
Resent-To: >, 
>, 
>, 
>, 
>, 
>
Resent-Date: Tuesday, January 30, 2018 at 10:46 AM

I support progress and publish as RFC.

The document is well written and resolves with a reasonable approach logical 
failures or human errors, that would otherwise result in significant service 
problems.
I was wondering why this document, eventhough being backward compatible with 
RFC7432, is Informational track, and not standard track.

G/

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, January 29, 2018 09:27
To: bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df


Hello Working Group,



This email starts a Working Group Last Call on

draft-ietf-bess-evpn-ac-df-03 [1] which is considered mature and

ready for a final working group review.



Please read this document if you haven't read the most recent version

yet, and send your comments to the list, no later than *12th of February*.

Note that this is *not only* a call for comments on the document; it is

also a call for support (or not) to publish this document as an 
Informational

RFC.



In addition, we are also polling for knowledge of any IPR that

applies to draft-ietf-bess-evpn-ac-df, 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 a document Author or Contributor of the draft

please respond to this email and indicate whether or not you are aware

of any relevant IPR.



Note that, as of today, no IPR has been disclosed against this document

or its earlier versions.



We are **also polling for knowledge 

Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df

[stephane.litkowski]

Hi Jorge,

Thanks for your answers.
Pls find more inline [SLI2]


-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View) 
[mailto:jorge.raba...@nokia.com] 
Sent: Tuesday, January 30, 2018 16:20
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc: bess@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-evpn-ac-df

Hi Stephane,

Thank you for your review.
Please see in-line and let me know what you think.
Thanks.

Jorge

-Original Message-
From: "stephane.litkow...@orange.com" 
Date: Tuesday, January 30, 2018 at 10:35 AM
To: "draft-ietf-bess-evpn-ac-df.auth...@ietf.org" 

Cc: "bess@ietf.org" 
Subject: Shepherd's review of draft-ietf-bess-evpn-ac-df
Resent-From: 
Resent-To: , , 
, , , 

Resent-Date: Tuesday, January 30, 2018 at 10:35 AM

Hi,

As shepherd of this document, please find below my comments.

IMO, this is a very useful proposal. The document is quite easy to 
understand with a good illustrated example.

[JORGE] that's good, thanks.

Overall comments:
- I would encourage to have an acronym section containing all abbreviations 
and the associated expansion. That could be a good best practice.

[JORGE] ok, done.

- I'm wondering why this document intended status is Informational. It 
looks to fill a major (IMO) miss from the basic specification and I would be 
happy to see it as a standard track document. Even if there is no protocol 
extension involved, I think that standard track could make sense. Was this 
already discussed ?

[JORGE] the reasons why the authors thought of Informational were because a) it 
does not define any protocol extension and b) it is backwards compatible with 
RFC7432, in the sense that a PE supporting this document and a PE supporting 
RFC7432 could be put in the same Ethernet Segment and it would all work (no 
loops or packet duplication). That may not necessarily be the case with more 
than 2 PEs. Nevertheless the document does not recommend to do it in any case. 
I am personally happy to change it to Standards Track if the rest of the 
co-authors and the WG don't have any issues with it.

- I'm not sure that we can say that this procedure is backward compatible. 
I agree that there is no protocol extension involved but as it is mentioned, we 
cannot mix PEs running the new procedure and PE running the old procedure. This 
must be ensured by the operator. Wouldn't it be better to add a flag/attribute 
to announce that a PE is capable to run this procedure ? Thus, when PEs run the 
svc carving algo, if they know that all the PEs are capable of this procedure, 
and they can all run it automatically. If there is one or more PE in the set 
that is not capable, they fallback to the regular procedure.

[JORGE] As discussed above, we wanted to make it backwards compatible in a 
simple case. E.g. say PE1 and PE2 are in the same ES. PE1 supports this 
document and PE2 does not. In this case, link/node failures are covered by the 
baseline RFC7432. Logical AC failures don't change the RFC7432 overall 
behavior, for instance:
a) a logical AC failure on PE1, will not change the DF, just like in RFC7432.
b) a logical AC failure on PE2 makes PE1 take over, but, since PE2 can't 
forward traffic anyway, there are no loops/duplication and everything works. 
[SLI2] Being backward compatible on a simple case is IMO not enough to declare 
the solution as backward compatible. As you mentioned if more than two PEs are 
involved, we can fall into issues and human care are required. I don't consider 
this as backward compatible.



- I would be in favor of having of deployment considerations section that 
deals with the backward compatibility and how to deploy the solution.
[JORGE] We can add the section and the above example to clarify the "backwards 
compatibility" concept.
[SLI2] That's good thanks. We just need to agree on the content :)


- There are too much authors in the Author list. Would it be possible to 
reduce it ?

Problem statement: 
"an ES route withdrawn will make...".
[SLI] I have a doubt here, would it be "and ES route withdrawal will make" 
or "a withdrawn ES route" ?
[JORGE] fixed to "an ES route withdrawal". Thx.


Section 2.1
" After running the service-carving DF election algorithm"
[SLI] Could you mention that you refer to the existing algorithm from 
RFC7432 ?
[JORGE] done. Thanks.

Section 2.2/2.3:
- Would it be possible to collapse the two cases in a single procedure 
update ?
- I do not like to mix examples with a procedure update description. I 
would rather be in favor of focusing on what is changing compared to RFC7432. 
For instance, "The step 3 is