Updates on EVPN BUM Procedures
draft-ietf-bess-evpn-bum-procedure-updates-14

[Ballot comment]
Thanks for helping me understand that my previous discuss point is a non-issue!
My original COMMENT section is preserved, unchanged, below.

Section 1

  It is expected that audience is familiar with EVPN and MVPN concepts
  and terminologies.  For convenience, the following terms are briefly

Please provide references for EVPN and MVPN that would serve as entry
points for gaining such familiarity.  E.g., RFCs 7432 and 6513/6514.

  explained.

I suggest including PMSI Tunnel Attribute in this list, especially since
RFC 6514 does not actually use the PTA acronym.

Section 2.1

  There is a difference between MVPN and VPLS multicast inter-as
  segmentation.  For simplicity, EVPN will use the same procedures as
  in MVPN.  All ASBRs can re-advertise their choice of the best route.

While it is defensible to rely on the stated expectation that the reader
is familiar with EVPN and MVPN concepts (hmm, which does not actually
include VPLS concepts?), it would be appreciated to include some
indication of the nature of the difference, before stating which variant
EVPN will use.

  For inter-area segmentation, [RFC7524] requires the use of Inter-area
  P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting
  of "Leaf Information Required" L flag in PTA in certain situations.
  Either of these could be optional in case of EVPN.  Removing these

"Could be"?  It sometimes is and sometimes isn't?  When is it still
mandatory?

Section 2.1.1

  For example, an MVPN/VPLS/EVPN network may span multiple providers
  and Inter-AS Option-B has to be used, in which the end-to-end

Is this "option (b)" of §7.2 of RFC 7117?  Regardless, a specific
reference seems in order.

  Another advantage of the smaller region is smaller BIER sub-domains.
  In this new multicast architecture BIER [RFC8279], packets carry a

RFC 8279 was published just about four years ago.  Does that still
qualify as "new"?  (I honestly am not sure, given the distribution of
time from -00 to RFC.)

Section 3

  The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs
  starts with a type 1 RD, whose Administrator sub-field MUST match
  that of the RD in all non-Leaf A-D (Section 3.3) EVPN routes from the
  same advertising router for a given EVI.

Is the requirement really so specific as "everything except Leaf A-D"?
What if some new type is allocated that also doesn't start with an RD?
Is it safe to say that any type that does have an RD must meet this
criterion?

Section 4

  The optional optimizations specified for MVPN in [RFC8534] are also
  applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are
  used for EVPN selective multicast forwarding.

Are we going to need a
draft-ietf-something-bum-procedure-further-updates in another five years
to perform the same type of "gap filling" that this document is doing
for how RFC 7432 referred to the RFC 7117 procedures?

Section 5.1

  The above VPLS behavior requires complicated VPLS specific procedures
  for the ASBRs to reach agreement.  For EVPN, a different approach is
  used and the above quoted text is not applicable to EVPN.

What about the text we didn't quote, that places MUST-level requirement
on the "best route selection procedures" that determine whether a given
ASBR re-advertises the route within its own AS?

      "The PMSI Tunnel attribute MUST specify the tunnel for the segment.
      If and only if, in order to establish the tunnel, the ASBR needs to
      know the leaves of the tree, then the ASBR MUST set the L flag to
      1 in the PTA to trigger Leaf A-D routes from egress PEs and
      downstream ASBRs. It MUST be (auto-)configured with an import RT,
      which controls acceptance of leaf A-D routes by the ASBR."

It seems like we might want to make some further statement about what
scope that import RT is expected to limit acceptance of the route to.

Section 5.2

  considered as leaves (as proxies for those PEs in other ASes).  Note
  that in case of Ingress Replication, when an ASBR re-advertises IMET
  A-D routes to IBGP peers, it MUST advertise the same label for all
  those for the same Ethernet Tag ID and the same EVI.  When an ingress

This seems like an eminently reasonable thing to require.  I wonder if
it's worth saying a little more about why it is required, though -- what
breaks if you don't do this?

  PE builds its flooding list, multiple routes might have the same
  (nexthop, label) tuple and they MUST only be added as a single branch
  in the flooding list.

I'm not entirely confident that I could implement this behavior for the
flooding list right now.  On the other hand, I also haven't written any
BGP code, so maybe it's expected that I couldn't implement it, but it
still seems like this might be glossing over some details.

Section 5.3

  o  An egress PE sends Leaf A-D routes in response to I-PMSI routes,
      if the PTA has the L flag set (by the re-advertising ASBRs).

I don't think I understand the parenthetical.  Which previous text is it
intending to refer to?

Additionally, while we mention in the first paragraph of §5.2 the RFC
7432 requirement to not set the L flag in IMET A-D routes, I don't see
where we lift that requirement for the segmented procedures.  The change
in §5.1 to let the ASBR set the L flag does not seem constructed in a
way that lifts the requirement from §11.2 of RFC7432.

  To address this backward compatibility problem, the following
  procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI
  A-D routes):

Can be used, but is in no way mandatory, not even to implement?  That's
rather surprising.

  o  The ASBRs in an AS originate per-region I-PMSI A-D routes and
      advertise to their external peers to advertise tunnels used to
      carry traffic from the local AS to other ASes.  Depending on the

This may or may not just be a grammar nit: *what* do the ASBRs advertise
to their external peers to advertise tunnels?  (Are we just missing
"them" for "advertise them"?)

Section 6.3

  [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs
  to change the BGP next hop when they re-advertise I/S-PMSI A-D routes

I failed to find any place where RFC 7524 used the string "S-NH-EC", and
suggest writing out "Segmented Next-Hop Extended Community" somewhere.

Section 9

I would posit that at least some of the security considerations from RFC
6513 are relevant here, in addition to the (already mentioned) 6514
considerations.

Section 12.1

I do not think that RFC 7988 needs to be classified as normative; we
reference it only once, in an example; RFCs 4875 and 6388 are used in
the same way for the same example, but are classified as informative.

Section 12.2

I don't see what's different between RFCs 6513 and 6514 to make the
latter normative while the former is informative -- they are referenced
in largely the same places, and often.

NITS

Abstract

  This document specifies procedure updates for broadcast, unknown
  unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

I'd suggest NEW:

This document specifies updated procedures for handling broadcast,
unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

Section 1

  o  IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D
      route.  The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route.

I would say that a de novo explanation is likely to be of more general
applicability than a dense MVPN reference.  Perhaps "Advertised by PEs
to enable reception of BUM traffic for a given VLAN" or similar?

  o  SMET A-D route [I-D.ietf-bess-evpn-igmp-mld-proxy]: Selective
      Multicast Ethernet Tag A-D route.  The EVPN equivalent of MVPN
      Leaf A-D route but unsolicited and untargeted.

Likewise, this might be something like "Advertised by PEs to indicate
that the indicated BUM traffic should be sent to the advertising PE."

Section 2

  [RFC7117] specifies procedures for Multicast in Virtual Private LAN
  Service (VPLS Multicast) using both inclusive tunnels and selective
  tunnels with or without inter-as segmentation, similar to Multicast
  VPN (MVPN) procedures specified in [RFC6513] and [RFC6514].

s/to Multicast/to the Multicast/

Section 2.1.1

  Segmentation can also be used to divide an AS/area to smaller
  regions, so that control plane state and/or forwarding plane state/

s/to smaller/into smaller/

Section 4

  of egress PEs for selective forwarding with BIER).  An NVE proxies
  the IGMP/MLD state that it learns on its ACs to (C-S,C-G) or
  (C-*,C-G) SMET routes and advertises to other NVEs, and a receiving

I think s/and/that it/

  NVE converts the SMET routes back to IGMP/MLD messages and send them

s/send/sends/

Section 5.3

  o  An ingress PE uses the Next Hop instead of Originating Router's IP
      Address to determine leaves for the I-PMSI tunnel.

It was not previously required to use Originating Router's IP Address,
so maybe s/instead of/and not use/.

Section 6.1

  changes the next hop to its own address and changes PTA to specify
  the tunnel type/identification in the neighboring region 3.  Now the

I'm not sure that we ever explicitly named the region.  We implicitly do
in the following figure that says "segment 3", but the number and string
"region" don't seem paired anywhere directly.

Section 6.2

  propagated to other regions.  If multiple RBRs are connected to a
  region, then each will advertise such a route, with the same route
  key (Section 3.1).  Similar to the per-PE I-PMSI A-D routes, RBRs/PEs

Mention of route key seems to be in §3.3, not 3.1.

Section 6.3

  NH-EC.  The advantage of this is that neither ingress nor egress PEs
  need to understand/use S-NH-EC, and consistent procedure (based on
  BGP next hop) is used for both inter-as and inter-region
  segmentation.

s/consistent/a consistent/

Section 7

  including Ingress Replication.  Via means outside the scope of this
  document, PEs know that ESI labels are from DCB and existing multi-
  homing procedures work as is, whether a multi-homed Ethernet Segment
  spans across segmentation regions or not.

I'm not sure this is a well-formed sentence.  Is it supposed to be a
list?  Or just two things that PEs know OOB: (ESI labels are from
existing multi-homing procedures work as is) and (whether or not a
multi-homed Ethernet Segment spans across segmentation regions)?

[Ballot discuss]
This should be an easy thing to resolve, but I'm confused about the IANA Considerations section.  First, it should name the registry it's updating.  For instance:

OLD:

  IANA has temporarily assigned the following new EVPN route types:

NEW:

  IANA has temporarily made the following entries into the EVPN Route Types registry:

However, the second part of this section makes an entry in the "EVPN Multicast Flags Extended Community" which I can't find on IANA's site or via a search engine.  If you're referring to the EVPN Extended Community Sub-Types sub-registry of the BGP Extended Communities registry, this document should say that.  Or did you mean something else?

[Ballot comment]
The shepherd writeup is over two years old.  I wonder if it would be worth reviewing.  Also, questions 7 and 8 have the same answer, but they're asking different things.

Terms like "MVPN" and "ASBR" are commonly used.  I realize Section 1 says:

  It is expected that audience is familiar with EVPN and MVPN concepts
  and terminologies.

Still, I think it's conventional to expand key acronyms upon first use.  EVPN is expanded in the Abstract, for example.  I think this would be helpful to some readers a little foreign to the topic.

"SMET A-D" is defined in Section 1, but then not used anywhere in this document.

[Ballot discuss]
I'm not sure whether the Leaf A-D route (route type specific field) as
specified by this document is guaranteed to have a unique
interpretation (§3.3).  It's supposed to start with the "route key",
which is just the route-type-specific field of the PMSI route that
triggered the Leaf A-D route.  That makes the route key variable length
(as stated), and this variation is clearly achieved given that even the
Per-Region I-PMSI A-D route and S-PMSI A-D route defined in this
document have different length and layout.  I'm not sure what
information is expected to be available to bound and determine the
length of this "route key" field, other than "not the rest of the
stuff".  "The rest of the stuff" is the originator's address and length
thereof, but the length is in the middle of the structure, so even if we
start parsing from the back we still can't distinguish reliably between
a 4-byte IPv4 address and a 16-byte IPv6 address.  It seems that the
Originator's Addr Length would need to be the last field in order to
provide a unique interpretation, with "parse backwards" used to extract
the Originator's Address, and "the rest of the stuff" being the route
key that can be matched to the triggering PMSI route.  Is there some
other procedure or contextual information available that ensurs a unique
interpretation of this data?  Looking at RFCs 6514 and 7117, it does not
seem like this document has some key change that renders it
fundamentally different in this regard, so I mostly assume that the
received route can be disambiguated somehow; I just don't know what that
way is.

[Ballot comment]
Section 1

  It is expected that audience is familiar with EVPN and MVPN concepts
  and terminologies.  For convenience, the following terms are briefly

Please provide references for EVPN and MVPN that would serve as entry
points for gaining such familiarity.  E.g., RFCs 7432 and 6513/6514.

  explained.

I suggest including PMSI Tunnel Attribute in this list, especially since
RFC 6514 does not actually use the PTA acronym.

Section 2.1

  There is a difference between MVPN and VPLS multicast inter-as
  segmentation.  For simplicity, EVPN will use the same procedures as
  in MVPN.  All ASBRs can re-advertise their choice of the best route.

While it is defensible to rely on the stated expectation that the reader
is familiar with EVPN and MVPN concepts (hmm, which does not actually
include VPLS concepts?), it would be appreciated to include some
indication of the nature of the difference, before stating which variant
EVPN will use.

  For inter-area segmentation, [RFC7524] requires the use of Inter-area
  P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting
  of "Leaf Information Required" L flag in PTA in certain situations.
  Either of these could be optional in case of EVPN.  Removing these

"Could be"?  It sometimes is and sometimes isn't?  When is it still
mandatory?

Section 2.1.1

  For example, an MVPN/VPLS/EVPN network may span multiple providers
  and Inter-AS Option-B has to be used, in which the end-to-end

Is this "option (b)" of §7.2 of RFC 7117?  Regardless, a specific
reference seems in order.

  Another advantage of the smaller region is smaller BIER sub-domains.
  In this new multicast architecture BIER [RFC8279], packets carry a

RFC 8279 was published just about four years ago.  Does that still
qualify as "new"?  (I honestly am not sure, given the distribution of
time from -00 to RFC.)

Section 3

  The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs
  starts with a type 1 RD, whose Administrator sub-field MUST match
  that of the RD in all non-Leaf A-D (Section 3.3) EVPN routes from the
  same advertising router for a given EVI.

Is the requirement really so specific as "everything except Leaf A-D"?
What if some new type is allocated that also doesn't start with an RD?
Is it safe to say that any type that does have an RD must meet this
criterion?

Section 4

  The optional optimizations specified for MVPN in [RFC8534] are also
  applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are
  used for EVPN selective multicast forwarding.

Are we going to need a
draft-ietf-something-bum-procedure-further-updates in another five years
to perform the same type of "gap filling" that this document is doing
for how RFC 7432 referred to the RFC 7117 procedures?

Section 5.1

  The above VPLS behavior requires complicated VPLS specific procedures
  for the ASBRs to reach agreement.  For EVPN, a different approach is
  used and the above quoted text is not applicable to EVPN.

What about the text we didn't quote, that places MUST-level requirement
on the "best route selection procedures" that determine whether a given
ASBR re-advertises the route within its own AS?

      "The PMSI Tunnel attribute MUST specify the tunnel for the segment.
      If and only if, in order to establish the tunnel, the ASBR needs to
      know the leaves of the tree, then the ASBR MUST set the L flag to
      1 in the PTA to trigger Leaf A-D routes from egress PEs and
      downstream ASBRs. It MUST be (auto-)configured with an import RT,
      which controls acceptance of leaf A-D routes by the ASBR."

It seems like we might want to make some further statement about what
scope that import RT is expected to limit acceptance of the route to.

Section 5.2

  considered as leaves (as proxies for those PEs in other ASes).  Note
  that in case of Ingress Replication, when an ASBR re-advertises IMET
  A-D routes to IBGP peers, it MUST advertise the same label for all
  those for the same Ethernet Tag ID and the same EVI.  When an ingress

This seems like an eminently reasonable thing to require.  I wonder if
it's worth saying a little more about why it is required, though -- what
breaks if you don't do this?

  PE builds its flooding list, multiple routes might have the same
  (nexthop, label) tuple and they MUST only be added as a single branch
  in the flooding list.

I'm not entirely confident that I could implement this behavior for the
flooding list right now.  On the other hand, I also haven't written any
BGP code, so maybe it's expected that I couldn't implement it, but it
still seems like this might be glossing over some details.

Section 5.3

  o  An egress PE sends Leaf A-D routes in response to I-PMSI routes,
      if the PTA has the L flag set (by the re-advertising ASBRs).

I don't think I understand the parenthetical.  Which previous text is it
intending to refer to?

Additionally, while we mention in the first paragraph of §5.2 the RFC
7432 requirement to not set the L flag in IMET A-D routes, I don't see
where we lift that requirement for the segmented procedures.  The change
in §5.1 to let the ASBR set the L flag does not seem constructed in a
way that lifts the requirement from §11.2 of RFC7432.

  To address this backward compatibility problem, the following
  procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI
  A-D routes):

Can be used, but is in no way mandatory, not even to implement?  That's
rather surprising.

  o  The ASBRs in an AS originate per-region I-PMSI A-D routes and
      advertise to their external peers to advertise tunnels used to
      carry traffic from the local AS to other ASes.  Depending on the

This may or may not just be a grammar nit: *what* do the ASBRs advertise
to their external peers to advertise tunnels?  (Are we just missing
"them" for "advertise them"?)

Section 6.3

  [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs
  to change the BGP next hop when they re-advertise I/S-PMSI A-D routes

I failed to find any place where RFC 7524 used the string "S-NH-EC", and
suggest writing out "Segmented Next-Hop Extended Community" somewhere.

Section 9

I would posit that at least some of the security considerations from RFC
6513 are relevant here, in addition to the (already mentioned) 6514
considerations.

Section 12.1

I do not think that RFC 7988 needs to be classified as normative; we
reference it only once, in an example; RFCs 4875 and 6388 are used in
the same way for the same example, but are classified as informative.

Section 12.2

I don't see what's different between RFCs 6513 and 6514 to make the
latter normative while the former is informative -- they are referenced
in largely the same places, and often.

NITS

Abstract

  This document specifies procedure updates for broadcast, unknown
  unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

I'd suggest NEW:

This document specifies updated procedures for handling broadcast,
unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

Section 1

  o  IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D
      route.  The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route.

I would say that a de novo explanation is likely to be of more general
applicability than a dense MVPN reference.  Perhaps "Advertised by PEs
to enable reception of BUM traffic for a given VLAN" or similar?

  o  SMET A-D route [I-D.ietf-bess-evpn-igmp-mld-proxy]: Selective
      Multicast Ethernet Tag A-D route.  The EVPN equivalent of MVPN
      Leaf A-D route but unsolicited and untargeted.

Likewise, this might be something like "Advertised by PEs to indicate
that the indicated BUM traffic should be sent to the advertising PE."

Section 2

  [RFC7117] specifies procedures for Multicast in Virtual Private LAN
  Service (VPLS Multicast) using both inclusive tunnels and selective
  tunnels with or without inter-as segmentation, similar to Multicast
  VPN (MVPN) procedures specified in [RFC6513] and [RFC6514].

s/to Multicast/to the Multicast/

Section 2.1.1

  Segmentation can also be used to divide an AS/area to smaller
  regions, so that control plane state and/or forwarding plane state/

s/to smaller/into smaller/

Section 4

  of egress PEs for selective forwarding with BIER).  An NVE proxies
  the IGMP/MLD state that it learns on its ACs to (C-S,C-G) or
  (C-*,C-G) SMET routes and advertises to other NVEs, and a receiving

I think s/and/that it/

  NVE converts the SMET routes back to IGMP/MLD messages and send them

s/send/sends/

Section 5.3

  o  An ingress PE uses the Next Hop instead of Originating Router's IP
      Address to determine leaves for the I-PMSI tunnel.

It was not previously required to use Originating Router's IP Address,
so maybe s/instead of/and not use/.

Section 6.1

  changes the next hop to its own address and changes PTA to specify
  the tunnel type/identification in the neighboring region 3.  Now the

I'm not sure that we ever explicitly named the region.  We implicitly do
in the following figure that says "segment 3", but the number and string
"region" don't seem paired anywhere directly.

Section 6.2

  propagated to other regions.  If multiple RBRs are connected to a
  region, then each will advertise such a route, with the same route
  key (Section 3.1).  Similar to the per-PE I-PMSI A-D routes, RBRs/PEs

Mention of route key seems to be in §3.3, not 3.1.

Section 6.3

  NH-EC.  The advantage of this is that neither ingress nor egress PEs
  need to understand/use S-NH-EC, and consistent procedure (based on
  BGP next hop) is used for both inter-as and inter-region
  segmentation.

s/consistent/a consistent/

Section 7

  including Ingress Replication.  Via means outside the scope of this
  document, PEs know that ESI labels are from DCB and existing multi-
  homing procedures work as is, whether a multi-homed Ethernet Segment
  spans across segmentation regions or not.

I'm not sure this is a well-formed sentence.  Is it supposed to be a
list?  Or just two things that PEs know OOB: (ESI labels are from
existing multi-homing procedures work as is) and (whether or not a
multi-homed Ethernet Segment spans across segmentation regions)?

[Ballot comment]
Much thanks to Scott Bradner for the OpsDir review (-09), discussions and then re-review of -11. Jeffrey has agreed to change the SHOULD at the ned of S5.3.1 to a MUST (see OpsDir thread), and I'm balloting NoObj with the assumption that that will happen.


Thanks again to Scott and the authors; I think that the comments since -09 have noticeably improved the document.

[Ballot comment]
Thanks for working on this document. Thanks to Gorry Fairhurst for his TSVART review and to the authors for addressing the review comments.

Here, I strongly support Lars's discuss as I also have hard time understanding the relation towards the updates to RFC 7432 and to RFC 7117 and RFC 7524. The explanation given in the section 2 is not good enough.

Most of my confusions arose from the way updates/changes/clarifications done to RFC 7117 and RFC 7524 without describing their relation to RFC 7432 in this document. Hence to resolve this my suggestion will be to -

* list the updates made to RFC 7432
* describe the relation among RFC 7432, RFC7117, RFC 7524 in the respective sections where the changes/updates/clarifications are done. Section 5.2 is a good example for this.

I hope this helps.

[Ballot comment]
** I support Lars Eggert’s DISCUSS position.  I have come to the same conclusion as the GENART reviewer (Paul Kyzivat).  It isn’t clear what this document is updating.

-- The document header and abstract explicitly say that RC7432 is updated.  However, I can’t find a clear explanation of how the next in this documents updates RFC7432

-- Section 5.1. is titled as “Changes to Section 7.2.2 of [RFC7117]” and changes behavior in RFC7117, but RFC7117 is not being updated (according to the header and abstract).

** Section 9.
  They do not introduce new security concerns besides what have been
  discussed in [RFC6514], [RFC7117], [RFC7432] and [RFC7524].

Which parts of these security considerations specifically apply here.  For example, RFC7524 and RFC7432 makes references to MPLS mechanisms (which seem out of scope here).  Additionally, it appears some of the guidance across these documents is directed at securing generic EVPN technology – this is helpful, but please be clear about this case.  What specific guidance is relevant to the procedures for handling BUM traffic?

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Zheng Zhang for his shepherd's write-up about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 3 --

It is a little unclear whether the first list of values are applicable to the 'route type' field. The reader can only guess when reading the pre-amble to the 2nd list.

-- Section 5.1 --
The text in this section appears to also update RFC 7117: "The following bullet in Section 7.2.2.2 of [RFC7117]: ... s changed to the following when applied to EVPN:". Should this document also formally update RFC 7117 ?

[Ballot discuss]
Entering a DISCUSS to make sure the authors respond to Paul Kyzivat's
Gen-ART review (https://mailarchive.ietf.org/arch/msg/gen-art/g5QZK_1U6boqzG8FjuJWhGG74RI),
and so that the IESG can discuss that review and (hopefully) any
responses to it.

[Ballot comment]
Thanks to Gorry Fairhurst for the TSVART review.

I see no transport issues. I'm trusting others on the non-transport aspects, as it's mostly opaque to me as a non-expert.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bess-evpn-bum-procedure-updates-09. If any part of this review is inaccurate, please let us know.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

[I-D.ietf-bess-evpn-igmp-mld-proxy]

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the EVPN Route Type registry located on the Ethernet VPN (EVPN) registry page located at:

https://www.iana.org/assignments/evpn/

three temporary registrations will be made permanent and their references changed to [ RFC-to-be ].

They are:

Value:9
Description: Per-Region I-PMSI A-D route

Value: 10
Description: S-PMSI A-D route

Value: 11
Description: Leaf A-D route

Second, in the EVPN Multicast Flags Extended Community registry to be created upon approval of [I-D.ietf-bess-evpn-igmp-mld-proxy], a new registration is to be made as follows:

Bit Name Reference
-----------------------+----------------------+---------------
[ TBD-at-Registration ] The router supports [ RFC-to-be ]
segmentation procedure
defined in
[ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-09-07):

From: The IESG
To: IETF-Announce
CC: Zheng Zhang , bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-bum-procedure-updates@ietf.org, martin.vigoureux@nokia.com, zzhang_ietf@hotmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Updates on EVPN BUM Procedures) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Updates on EVPN BUM Procedures'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies procedure updates for broadcast, unknown
  unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),
  including selective multicast, and provider tunnel segmentation.
  This document updates RFC 7432.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The procedure updates for BUM traffic in EVPN need to be standardised for interoperability, so the specification is on Standard Track as indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document specifies/clarifies/redefines certain/additional EVPN BUM procedures, with a salient goal that they're better aligned among MVPN, EVPN and VPLS.  For brevity, only changes/additions to relevant RFC 7117 and RFC 7524 procedures are specified, instead of repeating the entire procedures.  Note that these are to be applied to EVPN only, even though sometimes they may sound to be updates to RFC 7117/7524.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document went through few rounds of reviews, comments and revisions  and there is consensus in the WG to publish these documents.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is a stable document and supported for publication in the working group.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd:  Zheng Zhang  zzhang_ietf@hotmail.com
Area Director: Martin Vigoureux  martin.vigoureux@nokia.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This version draft-ietf-bess-evpn-bum-procedure-updates-06 need to address all the comments made on the mailing list.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No such concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Not required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

One IPR disclosures is confirmed: https://datatracker.ietf.org/ipr/3341/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

https://datatracker.ietf.org/ipr/3341/

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document was discussed very well, and went through few rounds of reviews, comments and revisions.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are some nits need to be solved.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The referenced document "ietf-bess-mvpn-expl-track" has been published as RFC8534.
The referenced document "draft-ietf-bess-evpn-df-election-framework" has been published as RFC8584.
These two references need to be updated.
The Bit-S definition relies on the proceeding of  the referenced document "ietf-bess-evpn-igmp-mld-proxy" which is working group draft now. So this draft need to wait for the standardization of "ietf-bess-evpn-igmp-mld-proxy".

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC7432 is being updated by this document.
No other RFCs are being obsoleted by this document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

All the extensions has been captured in IANA consideration section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

As per Shepherds understanding, no expert level review is required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Some nits need to be solved.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The procedure updates for BUM traffic in EVPN need to be standardised for interoperability, so the specification is on Standard Track as indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document specifies/clarifies/redefines certain/additional EVPN BUM procedures, with a salient goal that they're better aligned among MVPN, EVPN and VPLS.  For brevity, only changes/additions to relevant RFC 7117 and RFC 7524 procedures are specified, instead of repeating the entire procedures.  Note that these are to be applied to EVPN only, even though sometimes they may sound to be updates to RFC 7117/7524.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document went through few rounds of reviews, comments and revisions  and there is consensus in the WG to publish these documents.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is a stable document and supported for publication in the working group.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd:  Zheng Zhang  zzhang_ietf@hotmail.com
Area Director: Martin Vigoureux  martin.vigoureux@nokia.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This version draft-ietf-bess-evpn-bum-procedure-updates-06 need to address all the comments made on the mailing list.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No such concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Not required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

One IPR disclosures is confirmed: https://datatracker.ietf.org/ipr/3341/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

https://datatracker.ietf.org/ipr/3341/

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document was discussed very well, and went through few rounds of reviews, comments and revisions.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are some nits need to be solved.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The referenced document "ietf-bess-mvpn-expl-track" has been published as RFC8534.
The referenced document "draft-ietf-bess-evpn-df-election-framework" has been published as RFC8584.
These two references need to be updated.
The Bit-S definition relies on the proceeding of  the referenced document "ietf-bess-evpn-igmp-mld-proxy" which is working group draft now. So this draft need to wait for the standardization of "ietf-bess-evpn-igmp-mld-proxy".

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC7432 is being updated by this document.
No other RFCs are being obsoleted by this document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

All the extensions has been captured in IANA consideration section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

As per Shepherds understanding, no expert level review is required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Some nits need to be solved.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The procedure updates for BUM traffic in EVPN need to be standardised for interoperability, so the specification is on Standard Track as indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document specifies/clarifies/redefines certain/additional EVPN BUM procedures, with a salient goal that they're better aligned among MVPN, EVPN and VPLS.  For brevity, only changes/additions to relevant RFC 7117 and RFC 7524 procedures are specified, instead of repeating the entire procedures.  Note that these are to be applied to EVPN only, even though sometimes they may sound to be updates to RFC 7117/7524.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document went through few rounds of reviews, comments and revisions  and there is consensus in the WG to publish these documents.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is a stable document and supported for publication in the working group.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd:  Zheng Zhang  zzhang_ietf@hotmail.com
Area Director: Martin Vigoureux  martin.vigoureux@nokia.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This version draft-ietf-bess-evpn-bum-procedure-updates-06 addressed all the comments made on the mailing list and is ready for IESG publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No such concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Not required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that they are not aware of any undisclosed IPR on this draft.
Two contributors Junlin Zhang (Huawei Technologies), Zhenbin Li (Huawei Technologies) confirmed the IPR disclosures: https://datatracker.ietf.org/ipr/3341/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

https://datatracker.ietf.org/ipr/3341/

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document was discussed very well, and went through few rounds of reviews, comments and revisions and there is consensus in the WG to publish these documents.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The nits check result:

  ** There are 16 instances of too long lines in the document, the longest
    one being 3 characters in excess of 72.

  -- The draft header indicates that this document updates RFC7432, but the
    abstract doesn't seem to mention this, which it should.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

The referenced document "ietf-bess-evpn-igmp-mld-proxy" may need to be moved to informative part.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The referenced document "ietf-bess-mvpn-expl-track" has been published as RFC8534.
The referenced document "draft-ietf-bess-evpn-df-election-framework" has been published as RFC8584.
These two references need to be updated.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC7432 is being updated by this document.
No other RFCs are being obsoleted by this document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

All the extensions has been captured in IANA consideration section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

As per Shepherds understanding, no expert level review is required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

idnits 2.16.02

/tmp/draft-ietf-bess-evpn-bum-procedure-updates-06.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 16 instances of too long lines in the document, the longest
    one being 3 characters in excess of 72.

  -- The draft header indicates that this document updates RFC7432, but the
    abstract doesn't seem to mention this, which it should.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (June 17, 2019) is 22 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'RFC 7524' is mentioned on line 196, but not defined

  == Unused Reference: 'RFC2119' is defined on line 763, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC7432' is defined on line 773, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC7524' is defined on line 778, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC7988' is defined on line 784, but no explicit
    reference was found in the text

  == Unused Reference: 'I-D.ietf-bier-architecture' is defined on line 791,
    but no explicit reference was found in the text

  == Unused Reference: 'I-D.ietf-bier-evpn' is defined on line 797, but no
    explicit reference was found in the text

  == Unused Reference: 'RFC6513' is defined on line 802, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC6514' is defined on line 806, but no explicit
    reference was found in the text

  == Outdated reference: draft-ietf-bess-evpn-df-election-framework has been
    published as RFC 8584

  == Outdated reference: draft-ietf-bess-mvpn-expl-track has been published
    as RFC 8534

  == Outdated reference: draft-ietf-bier-architecture has been published as
    RFC 8279


    Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.