EVPN Virtual Ethernet Segment
draft-ietf-bess-evpn-virtual-eth-segment-15

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?

Internet Standard. Yes.

(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

This draft extends the Ethernet Segment (ES) concept of RFC7432 so that
an ES can be associated to a set of Ethernet Virtual Circuits (e.g., VLANs)
or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs).

Working Group Summary

Consensus achieved- even though most reviews/comments occurred at WGLC (i.e. late in process)

(Update from WG Co-Chair Matthew Bocci) Note that this document was sent back to the WG for a second WG last call following an original publication request on v07 of the draft. This was the result of a number of significant comments in AD and IESG review and there was a desire to confirm WG consensus on the new text to resolve these comments. There was working group consensus on this and v14 of the draft reflects this together with a number of editorial corrections. The response to an INTdir review was subsequently discussed on the BESS list but the consensus was that the draft should progress as-is.

Document Quality

There are several existing vendors' implementations of the draft.


Personnel

Document Shepherd: Luc André Burdet
Responsible Area Director: Andrew Alston

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

Careful review in light of three (3) known vendor implementations and interop.
Review raised quite a few nits/typos/ but more importantly 3 questions of substance-
1 which had already been raised on the alias before but I did not find any closure nor
was the document updated for it. Will follow-up with Authors.

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

There are many reviews from several individuals + vendors on the alias showing
good level of review & discussion of this draft.


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

No.

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

Raised as Shepherd review comment: the scale/convergence scheme proposed
is specific to PBB-EVPN. I believe it can be modified/extended to apply to EVPN as well,
and the draft almost implies that at one point. Asking authors to discuss this point explicitly.

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

Yes

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

Yes.
No WG discussion that I know of.

(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? 

Many individuals in WG have commented & agreed .

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

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

All NITS raised by the tool had been found during review & raised to authors' attention.

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

No.

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

Not in Rev-04, but comment to that effect raised in Review.

(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?

Normative to EVPN-IRB which is in Review.

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

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

No known.

(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 5226).

IANA allocation already made for new extended community subtype.

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

N/A.

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

No formal language sections.

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?

Internet Standard. Yes.

(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

This draft extends the Ethernet Segment (ES) concept of RFC7432 so that
an ES can be associated to a set of Ethernet Virtual Circuits (e.g., VLANs)
or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs).

Working Group Summary

Consensus achieved- even though most reviews/comments occurred at WGLC (i.e. late in process)

(Update from WG Co-Chair Matthew Bocci) Note that this document was sent back to the WG for a second WG last call following an original publication request on v07 of the draft. This was the result of a number of significant comments in AD and IESG review and there was a desire to confirm WG consensus on the new text to resolve these comments. There was working group consensus on this and v14 of the draft reflects this together with a number of editorial corrections. The response to an INTdir review was subsequently discussed on the BESS list but the consensus was that the draft should progress as-is.

Document Quality

There are several existing vendors' implementations of the draft.


Personnel

Document Shepherd: Luc André Burdet
Responsible Area Director: Andrew Alston

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

Careful review in light of three (3) known vendor implementations and interop.
Review raised quite a few nits/typos/ but more importantly 3 questions of substance-
1 which had already been raised on the alias before but I did not find any closure nor
was the document updated for it. Will follow-up with Authors.

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

There are many reviews from several individuals + vendors on the alias showing
good level of review & discussion of this draft.


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

No.

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

Raised as Shepherd review comment: the scale/convergence scheme proposed
is specific to PBB-EVPN. I believe it can be modified/extended to apply to EVPN as well,
and the draft almost implies that at one point. Asking authors to discuss this point explicitly.

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

Yes

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

Yes.
No WG discussion that I know of.

(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? 

Many individuals in WG have commented & agreed .

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

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

All NITS raised by the tool had been found during review & raised to authors' attention.

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

No.

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

Not in Rev-04, but comment to that effect raised in Review.

(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?

Normative to EVPN-IRB which is in Review.

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

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

No known.

(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 5226).

IANA allocation already made for new extended community subtype.

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

N/A.

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

No formal language sections.

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?

Internet Standard. Yes.

(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

This draft extends the Ethernet Segment (ES) concept of RFC7432 so that
an ES can be associated to a set of Ethernet Virtual Circuits (e.g., VLANs)
or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs).

Working Group Summary

Consensus achieved- even though most reviews/comments occurred at WGLC (i.e. late in process)

(Update from WG Co-Chair Matthew Bocci) Note that this document was sent back to the WG for a second WG last call following an original publication request on v12 of the draft. This was the result of a number of significant comments in AD and IESG review and there was a desire to confirm WG consensus on the new text to resolve these comments. There was working group consensus on this and v14 of the draft reflects this together with a number of editorial corrections. The response to an INTdir review was subsequently discussed on the BESS list but the consensus was that the draft should progress as-is.

Document Quality

There are several existing vendors' implementations of the draft.


Personnel

Document Shepherd: Luc André Burdet
Responsible Area Director: Andrew Alston

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

Careful review in light of three (3) known vendor implementations and interop.
Review raised quite a few nits/typos/ but more importantly 3 questions of substance-
1 which had already been raised on the alias before but I did not find any closure nor
was the document updated for it. Will follow-up with Authors.

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

There are many reviews from several individuals + vendors on the alias showing
good level of review & discussion of this draft.


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

No.

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

Raised as Shepherd review comment: the scale/convergence scheme proposed
is specific to PBB-EVPN. I believe it can be modified/extended to apply to EVPN as well,
and the draft almost implies that at one point. Asking authors to discuss this point explicitly.

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

Yes

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

Yes.
No WG discussion that I know of.

(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? 

Many individuals in WG have commented & agreed .

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

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

All NITS raised by the tool had been found during review & raised to authors' attention.

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

No.

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

Not in Rev-04, but comment to that effect raised in Review.

(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?

Normative to EVPN-IRB which is in Review.

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

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

No known.

(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 5226).

IANA allocation already made for new extended community subtype.

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

N/A.

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

No formal language sections.

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?

Internet Standard. Yes.

(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

This draft extends the Ethernet Segment (ES) concept of RFC7432 so that
an ES can be associated to a set of Ethernet Virtual Circuits (e.g., VLANs)
or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs).

Working Group Summary

Consensus achieved- even though most reviews/comments occurred at WGLC (i.e. late in process)

(Update from WG Co-Chair Matthew Bocci) Note that this document was sent back to the WG for a second WG last call following an original publication request on v12 of the draft. This was the result of a number of IESG comments and there was a desire to confirm WG consensus on the new text to resolve these comments. There was working group consensus on this and v14 of the draft reflects this together with a number of editorial corrections.

Document Quality

There are several existing vendors' implementations of the draft.


Personnel

Document Shepherd: Luc André Burdet
Responsible Area Director: Andrew Alston

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

Careful review in light of three (3) known vendor implementations and interop.
Review raised quite a few nits/typos/ but more importantly 3 questions of substance-
1 which had already been raised on the alias before but I did not find any closure nor
was the document updated for it. Will follow-up with Authors.

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

There are many reviews from several individuals + vendors on the alias showing
good level of review & discussion of this draft.


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

No.

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

Raised as Shepherd review comment: the scale/convergence scheme proposed
is specific to PBB-EVPN. I believe it can be modified/extended to apply to EVPN as well,
and the draft almost implies that at one point. Asking authors to discuss this point explicitly.

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

Yes

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

Yes.
No WG discussion that I know of.

(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? 

Many individuals in WG have commented & agreed .

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

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

All NITS raised by the tool had been found during review & raised to authors' attention.

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

No.

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

Not in Rev-04, but comment to that effect raised in Review.

(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?

Normative to EVPN-IRB which is in Review.

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

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

No known.

(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 5226).

IANA allocation already made for new extended community subtype.

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

N/A.

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

No formal language sections.

Due to numerous changes to this document as requested by both myself as the AD and other IESG members in their ballots, I felt it wise to return this to the WG for review and a subsequent last call in the WG before we proceed.

Awaiting feedback.  This document as of -11 has significant problems and needs heavy revision.  The working group has been asked to provide feedback on if they believe this will require another wg last call post revision or not due to the extent of the changes potentially required.  This may require a return to the working group dependent on feedback received.

[Ballot comment]
# Internet AD comments for draft-ietf-bess-evpn-virtual-eth-segment-11
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* It's not clear to me why this isn't just Informational.

### S3.3

* I get that this functionality is highly desirable, but is there some loss
  of interoperability among vendor equipment if it's not present?  In other
  words, why is this a MUST as opposed to SHOULD?

  Seems like the alternative is that the switching among neighbor EVCs is
  definitely less efficient, but could nevertheless be made to work.

### S3.4

* These don't seem like "requirements" to me, just service descriptions.

### S3.5

* R5a does not seem like a requirement.

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-bess-evpn-virtual-eth-segment-11
CC @jgscudder

(Thanks to Warren Kumari for pointing out that version 11 already removed the former Section 9. I apologize for the noise!)

I found this document hard to review, for various reasons, so I don't really consider this a complete review. In particular, I can't say with confidence that it would be possible to build an interoperable implementation using this spec. Because I currently don't have that confidence, but don't have a specific action plan to propose to remedy the situation, I am balloting ABSTAIN.

Despite that I have a number of comments I hope may be useful. Although I haven't currently chosen to make them a DISCUSS, I hope you will consider them, especially the ones that relate to elements of procedure that are unclear.

## COMMENTS

### Abstract + Section 1

Please expand "EVC" on first use in Section 1, and please simply write it out in words in the abstract (you could also include the "EVC" initialism if you think it's valuable to some readers; from my point of view it's not needed in the abstract though).

### Section 1.1

"ENNIs are commonly used to reach off-network / out-of-franchise customer sites via independent Ethernet access networks or third- party Ethernet Access Providers (EAP) (see Figure 1)."

As far as I can tell, Figure 1 doesn't elucidate this sentence. If it's supposed to, I think the figure needs more labeling. Nothing in the figure is labeled as an "independent Ethernet access network" or "EAP" and no context is provided to suggest what's considered off-network vs on-network (I see there's a box called "Carrier Ethernet Network" and another called "IP/MPLS Core Network" but those are technologies, not owners).

Given that the ENNI presumably is the demarcation between the SP and the third party, and from other context, I'm guessing the "Carrier Ethernet Network" is considered the third party in this case, and the IP/MPLS Core Network the SP. Probably it would be enough to add those notations to the figure.

### Section 1.1 and throughout

This document has specific numbers at various places, for example, in Section 1.1 we have "ENNIs can aggregate traffic from hundreds to thousands of vESes". Surely the exact number (even order-of-magnitude) is a moving target (unless it's bounded by some protocol constant, which it's not AFAICT).

Probably the numbers should either be made abstract, or qualified by something like "at time of writing".

### Section 1.1, off-networks

"As a result, ENNIs and their associated EVCs are a key element of SP off-networks"

What is an "SP off-network"? This isn't a well-known term of art.

### Section 1.1

"Figure 1 depicts two PE devices (PE1 and PE2) each with an ENNI where a number of vESes are aggregated on - each of which through its associated EVC."

AFAICT there is a many:one relationship between EVCs and vESes. Is that right? If so I think it's important to establish that context in this section, and in that case, the sentence needs a rewrite, as in,

NEW:
Figure 1 depicts two PE devices (PE1 and PE2) each with an ENNI that aggregates a number of vESes. Each vES is associated with an EVC, or in the case of the multi-homed vES connected to CE3, two EVCs.

(I've also fixed some unrelated grammatical errors.)

### Section 1.2 ES or vES?

Would it be more correct to rewrite "PW3 and PW5 would belong to ES-1, whereas PW4 and PW6 would be associated to ES-2" adding the "v" to "ES", as "PW3 and PW5 would belong to vES-1, whereas PW4 and PW6 would be associated to vES-2"?

It's hard enough to follow the abbreviations without casually using "ES" to mean different things in different places. :-( I'm relying on the definition of "ES" from the Abstract: "Ethernet Segment (ES), itself defined as a set of physical links".

### Section 1.2, EVI

Please expand EVI (or put it in your glossary but since you don't use it repeatedly, expanding it on use is better).

### Section 2

Shouldn't CE and PE be defined as "Customer Edge *Router*" and "Provider Edge *Router*"?

### Section 2

The following terms are used but never defined, please add definitions:

A-D, Ethernet A-D
BUM (although since this is used in only one place you could also just expand it on use)

The following definitions are never referenced and should be removed:

CFM
LACP

The following definitions are referenced only once and should probably just be expanded where used instead of defining them here:

BEB
DHD
AA

The following definitions are referenced only a few (2-3) times and should probably just be expanded where used:

DHN
MHD
MHN
SH
SA

### Section 3

There are a few actual requirements in this section, and a lot of things that I would characterize as aspirations, design principles, design goals, or simply elements of procedure. Ideally, one would cut the requirements down to only the things that are actually needed (if any), redistribute the elements of procedure to their respective sections, and maybe write a more casual section on design principles, but I realize that's not too likely.

There is one subsection that seems more problematic than the others, though, called out next.

### Section 3.2

I don't see how it is that these can be called "requirements", complete with RFC 2119 keywords, since they're couched in terms so imprecise it's not possible to say if an implementation is compliant or not. That is, "very large number" and "large number" are completely subjective. The examples given ("e.g. thousands") provide some context but are explicitly non-normative, and that's as it should be, since (as I mention in my comment on Section 1.1) these numbers are a moving target.

I don't see that this section is serving any useful purpose and suggest removing it. If you think that these really are "requirements" maybe you should think harder about how to write them down so that a third party could impartially evaluate whether they are met or not.

I do see that perhaps part of the goal here is to say "our design goal was to be able to support a lot of single-homed vESes, and we were ok with a lower scale of single-active and all-active vESes". That seems like something that could be mentioned in the introduction, or a subsection called something like "qualitative design goals". The line items about exactly how different service mixes are handled by different ports seem completely unnecessary; as far as I can tell the elements of procedure don't relate to these "requirements" at all.

In short, it seems to me this section can be removed. If you think it's important to the finished RFC, please explain why?

### Section 3.3, misuse of 2119 keyword

"For example, in Figure 1, PE1 MUST support". By definition a 2119 keyword doesn't make sense in an example. I guess s/MUST/has to/.

### Section 3.4

"However, there is no restriction on an EVC to carry more than one VLAN." and "there is no restriction on the PW to carry more than one VLAN if the PW is of type Raw mode."

I guess you mean "However, there is no restriction preventing an EVC from carrying more than one VLAN." and "there is no restriction preventing the PW from carrying more than one VLAN if the PW is of type Raw mode"? If my wording is incorrect, please explain what you did mean? If it's correct, I suggest adopting it or something like it.

### Section 3.7, misuse of 2119 keyword

"(R7d) Failure and failure recovery of an EVC for a Single-Active vES MAY only impact C-MACs associated with MHD/MHNs for that service instance. In other words, MAC flushing SHOULD be limited to single service instance (I-SID in the case of PBB-EVPN) and only C-MACs for Single-Active MHD/MHNs."

That first MAY seems misused. Did you mean it in the normal English sense, i.e. if I say "foo may only bar" I mean "foo must not do anything other than bar"? Because that's not how the 2119 MAY works at all. Probably the fix is just s/MAY/may/... although the "in other words" sentence tells us something different again, so I guess then the fix would be s/MAY/SHOULD/, as in

NEW:
(R7d) Failure and failure recovery of an EVC for a Single-Active vES SHOULD only impact C-MACs associated with MHD/MHNs for that service instance. In other words, MAC flushing SHOULD be limited to single service instance (I-SID in the case of PBB-EVPN) and only C-MACs for Single-Active MHD/MHNs.

I guess the SHOULD means that in the opinion of the authors, "there may exist valid reasons in particular circumstances to ignore" this requirement. Please elaborate on when it would be OK to do MAC flushing across multiple service instances in the context of this item? (If you think it is never OK then I guess this is actually MUST.)

### Section 4

Figure 3 is never referred to. Seems like it should be deleted.

Or, if you keep it, it seems like it would be good to connect it to the document somehow.

(If you delete the figure, you can also delete the definition of BEB since this is the only use.)

### Section 4.1

"For the sake of clarity and completeness, the default DF election procedure of [RFC7432] is repeated below:"

Did you mean "... is repeated below, **with necessary changes**:"? The procedure you show is of course NOT a direct quotation of the default DF election procedure of RFC 7432, and it's not even that procedure with s/ES/vES/g. For example,

RFC 7432:
  1. When a PE discovers the ESI of the attached Ethernet segment, it
      advertises an Ethernet Segment route with the associated ES-Import
      extended community attribute.

This draft:
  1.  When a PE discovers the vESI or is configured with the vESI
      associated with its attached vES, it advertises an Ethernet
      Segment route with the associated ES-Import extended community
      attribute.

The changes I see are:
- s/ESI/vESI/
- Addition of "or is configured with the vESI associated with its attached vES"

### Section 4.1

"In case of a Single-Active, when a service moves from one PE in the Redundancy Group to another PE as a result of DF re-election, the PE, which ends up being the elected DF for the service, SHOULD trigger a MAC address flush notification towards the associated vES."

What are examples of a circumstance where it would be OK for the PE to *not* trigger a MAC address flush notification?

Also, in "This can be done, for e.g. using IEEE 802.1ak MVRP 'new' declaration", when you write "for e.g." do you actually mean "for example" or "e.g."? Please rewrite as one, or the other, but not the mixed "for e.g.".

It seems like 802.1ak needs a reference.

### Section 4.1

"For LSP-based and PW-based vES, the non-DF PE SHOULD signal PW-status 'standby' to the Aggregation PE (e.g., AG PE in Figure 2),"

I don't see an "AG PE" in Figure 2. I see two AG boxes (AG1 and AG2) which the figure carefully does not refer to as PEs, and I see two boxes call PE1 and PE2. Please refer to the actual labels from the figure for clarity (so for example if you meant AG1 and AG2, you'd write "e.g., AG1 and AG2 in Figure 2").

### Section 4.1, EVI/BD

Please expand "EVI/BD" (or put it in your glossary but since you don't use it repeatedly, expanding it on use is better).

### Section 4.2.1, misused RFC 2119 keyword

"The ESI label extended community MAY not be added to Grouping Ethernet A-D per ES and SHOULD be ignored on receiving PE."

You don't mean "MAY not be", do you, you mean "MUST NOT be". Right?

Also, please give an example of when it is OK for the receiving PE to process the ESI label extended community instead of ignoring it.

### Section 4.2.1, ES vs vES

Since you've made a special point of introducing "vES" as something different from "ES", I am trying to parse out whether there's any special meaning to your uses of "ES" in this section. I think "ES route" just refers to a specific kind of route, which can carry a regular ES or a vES -- I wonder if it's worth saying anything about this?

But then we have

  The ESI label extended community (Section 7.5 of [RFC7432]) is not
  relevant to Grouping Ethernet A-D per ES.
 
and

  The ESI label extended community MAY not be added to Grouping
  Ethernet A-D per ES and SHOULD be ignored on receiving PE.

and

  This Grouping Ethernet A-D per ES is advertised with a list of Route
  Targets corresponding to the impacted service instances.
 
These all just say "per ES" and *not* "per ES route" or "per vES". Is there significance to that? Should it say something different?

### Section 4.2.1

Previous comment aside, I don't understand this:

"This Grouping Ethernet A-D per ES is advertised with a list of Route Targets corresponding to the impacted service instances. If the number of Route Targets is more than can fit into a single attribute, then a set of Grouping Ethernet A-D per ES routes are advertised."

I suppose by "single attribute" you mean "single BGP path attribute"? But a BGP path attribute is essentially unlimited in length -- the path attribute length field is up to two bytes wide, and the total BGP update message length is fixed at 4096 bytes, or 64k if extended messages are in use. So a single path attribute can occupy the entire update message if needed. So, I don't understand the "more than can fit" problem scenario.

"More than can fit" aside, I also find the paragraph terribly hard to make sense of at all. :-(

### Section 4.2.2

"For PBB-EVPN, especially where there here are large number of service instances (i.e., I-SIDs) associated with each EVC the PE MAY color each vES B-MAC route with an attribute representing their association to a physical port (e.g. ENNI)."

I think "where there here are" should just be "where there are" (remove "here"). In reading it I mentally deleted the "here". If that's NOT the correct fix, please explain.

### Section 5.3

"5. When this message is received, the remote PE MAY detect the special vES mass‑withdraw message by identifying the Grouping Ethernet A-D per ES route. The remote PEs MAY then access the list created in (1) of the vES's for the specified color, and initiate locally MAC address invalidating procedures for each of the vES's in the list."

Your use of MAY (twice) in the above implies that it's totally fine for the remote PE to *not* detect the special vES mass-withdraw, and/or to *not* then initiate MAC address invalidating procedures.

Is it true that this is completely fine, and that everything will still work (including performing in compliance with the "requirements" in Section 3) if the remote PE doesn't do step 5?

### Section 5.4

Similar question to the previous, with respect to step 4.

### Section 5.5

"This section assumes that the MAC flushing mechanism described in Section 5.4, bullet (1) is used"

There are no bullet items in Section 5.4. There are two numbered lists, so two things that could be considered item (1) in Section 5.4, so this reference isn't unambiguously resolvable. Please clarify/correct.

### Section 5.5

Similar to the previous two sections, everything in the procedures is MAY, which means the procedures are completely optional and in fact, that it would be technically permissible to implement (for example) only points 2 and 5 and not points 1, 3, 4, and 6. Is this intended? What is the result if some or all of the MAY are disregarded by an implementation?

### Section 5.5

Figure 5 is never referred to. Seems like it should be deleted.

Or, if you keep it, it seems like it would be good to connect it to the document somehow.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-bess-evpn-virtual-eth-segment-11
CC @jgscudder

I found this document hard to review, for various reasons, so I don't really consider this a complete review. In particular, I can't say with confidence that it would be possible to build an interoperable implementation using this spec.

Despite that I have a number of comments I hope may be useful. Although I haven't currently chosen to make them a DISCUSS, I hope you will consider them, especially the ones that relate to elements of procedure that are unclear.

## DISCUSS

### Section 9

I agree with Paul Wouters that Section 9 is unusual, to say the least. I am going to dial up Paul's suggestion that the section be removed, to a strong suggestion, and a request that if it's not removed, we have a conversation about why it is needed and what value it adds to the finished specification.

I would be curious to know why this section was added, to begin with, it's unique in my experience. But it's optional to provide the background -- the necessary part is to either remove it or explain why it's needed.

[Ballot comment]
## COMMENTS

### Abstract + Section 1

Please expand "EVC" on first use in Section 1, and please simply write it out in words in the abstract (you could also include the "EVC" initialism if you think it's valuable to some readers; from my point of view it's not needed in the abstract though).

### Section 1.1

"ENNIs are commonly used to reach off-network / out-of-franchise customer sites via independent Ethernet access networks or third- party Ethernet Access Providers (EAP) (see Figure 1)."

As far as I can tell, Figure 1 doesn't elucidate this sentence. If it's supposed to, I think the figure needs more labeling. Nothing in the figure is labeled as an "independent Ethernet access network" or "EAP" and no context is provided to suggest what's considered off-network vs on-network (I see there's a box called "Carrier Ethernet Network" and another called "IP/MPLS Core Network" but those are technologies, not owners).

Given that the ENNI presumably is the demarcation between the SP and the third party, and from other context, I'm guessing the "Carrier Ethernet Network" is considered the third party in this case, and the IP/MPLS Core Network the SP. Probably it would be enough to add those notations to the figure.

### Section 1.1 and throughout

This document has specific numbers at various places, for example, in Section 1.1 we have "ENNIs can aggregate traffic from hundreds to thousands of vESes". Surely the exact number (even order-of-magnitude) is a moving target (unless it's bounded by some protocol constant, which it's not AFAICT).

Probably the numbers should either be made abstract, or qualified by something like "at time of writing".

### Section 1.1, off-networks

"As a result, ENNIs and their associated EVCs are a key element of SP off-networks"

What is an "SP off-network"? This isn't a well-known term of art.

### Section 1.1

"Figure 1 depicts two PE devices (PE1 and PE2) each with an ENNI where a number of vESes are aggregated on - each of which through its associated EVC."

AFAICT there is a many:one relationship between EVCs and vESes. Is that right? If so I think it's important to establish that context in this section, and in that case, the sentence needs a rewrite, as in,

NEW:
Figure 1 depicts two PE devices (PE1 and PE2) each with an ENNI that aggregates a number of vESes. Each vES is associated with an EVC, or in the case of the multi-homed vES connected to CE3, two EVCs.

(I've also fixed some unrelated grammatical errors.)

### Section 1.2 ES or vES?

Would it be more correct to rewrite "PW3 and PW5 would belong to ES-1, whereas PW4 and PW6 would be associated to ES-2" adding the "v" to "ES", as "PW3 and PW5 would belong to vES-1, whereas PW4 and PW6 would be associated to vES-2"?

It's hard enough to follow the abbreviations without casually using "ES" to mean different things in different places. :-( I'm relying on the definition of "ES" from the Abstract: "Ethernet Segment (ES), itself defined as a set of physical links".

### Section 1.2, EVI

Please expand EVI (or put it in your glossary but since you don't use it repeatedly, expanding it on use is better).

### Section 2

Shouldn't CE and PE be defined as "Customer Edge *Router*" and "Provider Edge *Router*"?

### Section 2

The following terms are used but never defined, please add definitions:

A-D, Ethernet A-D
BUM (although since this is used in only one place you could also just expand it on use)

The following definitions are never referenced and should be removed:

CFM
LACP

The following definitions are referenced only once and should probably just be expanded where used instead of defining them here:

BEB
DHD
AA

The following definitions are referenced only a few (2-3) times and should probably just be expanded where used:

DHN
MHD
MHN
SH
SA

### Section 3

There are a few actual requirements in this section, and a lot of things that I would characterize as aspirations, design principles, design goals, or simply elements of procedure. Ideally, one would cut the requirements down to only the things that are actually needed (if any), redistribute the elements of procedure to their respective sections, and maybe write a more casual section on design principles, but I realize that's not too likely.

There is one subsection that seems more problematic than the others, though, called out next.

### Section 3.2

I don't see how it is that these can be called "requirements", complete with RFC 2119 keywords, since they're couched in terms so imprecise it's not possible to say if an implementation is compliant or not. That is, "very large number" and "large number" are completely subjective. The examples given ("e.g. thousands") provide some context but are explicitly non-normative, and that's as it should be, since (as I mention in my comment on Section 1.1) these numbers are a moving target.

I don't see that this section is serving any useful purpose and suggest removing it. If you think that these really are "requirements" maybe you should think harder about how to write them down so that a third party could impartially evaluate whether they are met or not.

I do see that perhaps part of the goal here is to say "our design goal was to be able to support a lot of single-homed vESes, and we were ok with a lower scale of single-active and all-active vESes". That seems like something that could be mentioned in the introduction, or a subsection called something like "qualitative design goals". The line items about exactly how different service mixes are handled by different ports seem completely unnecessary; as far as I can tell the elements of procedure don't relate to these "requirements" at all.

In short, it seems to me this section can be removed. If you think it's important to the finished RFC, please explain why?

### Section 3.3, misuse of 2119 keyword

"For example, in Figure 1, PE1 MUST support". By definition a 2119 keyword doesn't make sense in an example. I guess s/MUST/has to/.

### Section 3.4

"However, there is no restriction on an EVC to carry more than one VLAN." and "there is no restriction on the PW to carry more than one VLAN if the PW is of type Raw mode."

I guess you mean "However, there is no restriction preventing an EVC from carrying more than one VLAN." and "there is no restriction preventing the PW from carrying more than one VLAN if the PW is of type Raw mode"? If my wording is incorrect, please explain what you did mean? If it's correct, I suggest adopting it or something like it.

### Section 3.7, misuse of 2119 keyword

"(R7d) Failure and failure recovery of an EVC for a Single-Active vES MAY only impact C-MACs associated with MHD/MHNs for that service instance. In other words, MAC flushing SHOULD be limited to single service instance (I-SID in the case of PBB-EVPN) and only C-MACs for Single-Active MHD/MHNs."

That first MAY seems misused. Did you mean it in the normal English sense, i.e. if I say "foo may only bar" I mean "foo must not do anything other than bar"? Because that's not how the 2119 MAY works at all. Probably the fix is just s/MAY/may/... although the "in other words" sentence tells us something different again, so I guess then the fix would be s/MAY/SHOULD/, as in

NEW:
(R7d) Failure and failure recovery of an EVC for a Single-Active vES SHOULD only impact C-MACs associated with MHD/MHNs for that service instance. In other words, MAC flushing SHOULD be limited to single service instance (I-SID in the case of PBB-EVPN) and only C-MACs for Single-Active MHD/MHNs.

I guess the SHOULD means that in the opinion of the authors, "there may exist valid reasons in particular circumstances to ignore" this requirement. Please elaborate on when it would be OK to do MAC flushing across multiple service instances in the context of this item? (If you think it is never OK then I guess this is actually MUST.)

### Section 4

Figure 3 is never referred to. Seems like it should be deleted.

Or, if you keep it, it seems like it would be good to connect it to the document somehow.

(If you delete the figure, you can also delete the definition of BEB since this is the only use.)

### Section 4.1

"For the sake of clarity and completeness, the default DF election procedure of [RFC7432] is repeated below:"

Did you mean "... is repeated below, **with necessary changes**:"? The procedure you show is of course NOT a direct quotation of the default DF election procedure of RFC 7432, and it's not even that procedure with s/ES/vES/g. For example,

RFC 7432:
  1. When a PE discovers the ESI of the attached Ethernet segment, it
      advertises an Ethernet Segment route with the associated ES-Import
      extended community attribute.

This draft:
  1.  When a PE discovers the vESI or is configured with the vESI
      associated with its attached vES, it advertises an Ethernet
      Segment route with the associated ES-Import extended community
      attribute.

The changes I see are:
- s/ESI/vESI/
- Addition of "or is configured with the vESI associated with its attached vES"

### Section 4.1

"In case of a Single-Active, when a service moves from one PE in the Redundancy Group to another PE as a result of DF re-election, the PE, which ends up being the elected DF for the service, SHOULD trigger a MAC address flush notification towards the associated vES."

What are examples of a circumstance where it would be OK for the PE to *not* trigger a MAC address flush notification?

Also, in "This can be done, for e.g. using IEEE 802.1ak MVRP 'new' declaration", when you write "for e.g." do you actually mean "for example" or "e.g."? Please rewrite as one, or the other, but not the mixed "for e.g.".

It seems like 802.1ak needs a reference.

### Section 4.1

"For LSP-based and PW-based vES, the non-DF PE SHOULD signal PW-status 'standby' to the Aggregation PE (e.g., AG PE in Figure 2),"

I don't see an "AG PE" in Figure 2. I see two AG boxes (AG1 and AG2) which the figure carefully does not refer to as PEs, and I see two boxes call PE1 and PE2. Please refer to the actual labels from the figure for clarity (so for example if you meant AG1 and AG2, you'd write "e.g., AG1 and AG2 in Figure 2").

### Section 4.1, EVI/BD

Please expand "EVI/BD" (or put it in your glossary but since you don't use it repeatedly, expanding it on use is better).

### Section 4.2.1, misused RFC 2119 keyword

"The ESI label extended community MAY not be added to Grouping Ethernet A-D per ES and SHOULD be ignored on receiving PE."

You don't mean "MAY not be", do you, you mean "MUST NOT be". Right?

Also, please give an example of when it is OK for the receiving PE to process the ESI label extended community instead of ignoring it.

### Section 4.2.1, ES vs vES

Since you've made a special point of introducing "vES" as something different from "ES", I am trying to parse out whether there's any special meaning to your uses of "ES" in this section. I think "ES route" just refers to a specific kind of route, which can carry a regular ES or a vES -- I wonder if it's worth saying anything about this?

But then we have

  The ESI label extended community (Section 7.5 of [RFC7432]) is not
  relevant to Grouping Ethernet A-D per ES.
 
and

  The ESI label extended community MAY not be added to Grouping
  Ethernet A-D per ES and SHOULD be ignored on receiving PE.

and

  This Grouping Ethernet A-D per ES is advertised with a list of Route
  Targets corresponding to the impacted service instances.
 
These all just say "per ES" and *not* "per ES route" or "per vES". Is there significance to that? Should it say something different?

### Section 4.2.1

Previous comment aside, I don't understand this:

"This Grouping Ethernet A-D per ES is advertised with a list of Route Targets corresponding to the impacted service instances. If the number of Route Targets is more than can fit into a single attribute, then a set of Grouping Ethernet A-D per ES routes are advertised."

I suppose by "single attribute" you mean "single BGP path attribute"? But a BGP path attribute is essentially unlimited in length -- the path attribute length field is up to two bytes wide, and the total BGP update message length is fixed at 4096 bytes, or 64k if extended messages are in use. So a single path attribute can occupy the entire update message if needed. So, I don't understand the "more than can fit" problem scenario.

"More than can fit" aside, I also find the paragraph terribly hard to make sense of at all. :-(

### Section 4.2.2

"For PBB-EVPN, especially where there here are large number of service instances (i.e., I-SIDs) associated with each EVC the PE MAY color each vES B-MAC route with an attribute representing their association to a physical port (e.g. ENNI)."

I think "where there here are" should just be "where there are" (remove "here"). In reading it I mentally deleted the "here". If that's NOT the correct fix, please explain.

### Section 5.3

"5. When this message is received, the remote PE MAY detect the special vES mass‑withdraw message by identifying the Grouping Ethernet A-D per ES route. The remote PEs MAY then access the list created in (1) of the vES's for the specified color, and initiate locally MAC address invalidating procedures for each of the vES's in the list."

Your use of MAY (twice) in the above implies that it's totally fine for the remote PE to *not* detect the special vES mass-withdraw, and/or to *not* then initiate MAC address invalidating procedures.

Is it true that this is completely fine, and that everything will still work (including performing in compliance with the "requirements" in Section 3) if the remote PE doesn't do step 5?

### Section 5.4

Similar question to the previous, with respect to step 4.

### Section 5.5

"This section assumes that the MAC flushing mechanism described in Section 5.4, bullet (1) is used"

There are no bullet items in Section 5.4. There are two numbered lists, so two things that could be considered item (1) in Section 5.4, so this reference isn't unambiguously resolvable. Please clarify/correct.

### Section 5.5

Similar to the previous two sections, everything in the procedures is MAY, which means the procedures are completely optional and in fact, that it would be technically permissible to implement (for example) only points 2 and 5 and not points 1, 3, 4, and 6. Is this intended? What is the result if some or all of the MAY are disregarded by an implementation?

### Section 5.5

Figure 5 is never referred to. Seems like it should be deleted.

Or, if you keep it, it seems like it would be good to connect it to the document somehow.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
I have serious readability concerns, but the RFC Editor will catch a lot of it. I'd like to focus on the problems that limited my understanding of this document.

The abstract is nearly impenetrable, thanks to dense acronyms and grammar mistakes. The verbiage is repeated in the Introduction. In particular

OLD
These solutions introduce Single-Active and All-Active for an Ethernet Segment (ES),
NEW
These solutions introduce Single-Active and All-Active redundancy modes for an Ethernet Segment (ES),

(S1.2)
"In some cases, this aggregation of PWs that share the same LSP pair may not be possible. For instance, if PW3 were terminated into a third PE, e.g. PE3, instead of PE1, the vES would need to be defined on a per individual PW on each PE, i.e. PW3 and PW5 would belong to ES-1, whereas PW4 and PW6 would be associated to ES-2."

"defined on a per individual PW on each PE" is grammatically incorrect, but I think you mean that each PW gets its own vES. But that would mean that you need four ESs, not two.

(S2) Please add EVI and Ethernet A-D to the glossary

[Ballot discuss]
Be ye not afraid - this DISCUSS should be easy to address.
Please see https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for some information on DISCUSS ballots....



Like Paul Wouters I find Section 9 ("Intellectual Property Considerations") troubling, but I'm sufficiently troubled that I feel it deserves a DISCUSS.
I *think* that what the text says is compatible with what is in BCP79 / the copyright boilerplate, but:
1: IANAL and
2: if it's exactly the same, why is this section here?

If it *not* the same, then I think that this requires some discussions with the IETF Trust / lawyers / etc...

I strongly suggest removing it, or, if it is needed for some sort of corporate / legal reason that it be justified / explained.

[Ballot comment]
I read the document but I surely didn't grasp a lot of things in there. The Security Considerations seem sane.

I don't understand why Section 9 is needed, and whether it adds or conflicts with the Copyright Notice. I suggest it be removed entirely.

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

The IANA Functions Operator has reviewed draft-ietf-bess-evpn-virtual-eth-segment-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-04-27):

From: The IESG
To: IETF-Announce
CC: =?utf-8?q?Luc_Andr=C3=A9_Burdet?= , andrew-ietf@liquid.tech, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-virtual-eth-segment@ietf.org, laburdet.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (EVPN Virtual Ethernet Segment) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'EVPN Virtual Ethernet Segment'
  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 2023-04-27. 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


  EVPN and PBB-EVPN introduce a family of solutions for multipoint
  Ethernet services over MPLS/IP network with many advanced features
  among which their multi-homing capabilities.  These solutions
  introduce Single-Active and All-Active for an Ethernet Segment (ES),
  itself defined as a set of physical links between the multi-homed
  device/network and a set of PE devices that they are connected to.
  This document extends the Ethernet Segment concept so that an ES can
  be associated to a set of EVCs (e.g., VLANs) or other objects such as
  MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as
  Virtual Ethernet Segments (vES).  This draft describes the
  requirements and the extensions needed to support vES in EVPN and
  PBB-EVPN.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3169/
  https://datatracker.ietf.org/ipr/3354/
  https://datatracker.ietf.org/ipr/3353/

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?

Internet Standard. Yes.

(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

This draft extends the Ethernet Segment (ES) concept of RFC7432 so that
an ES can be associated to a set of Ethernet Virtual Circuits (e.g., VLANs)
or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs).

Working Group Summary

Consensus achieved- even though most reviews/comments occurred at WGLC (i.e. late in process)

Document Quality

There are several existing vendors' implementations of the draft.


Personnel

Document Shepherd: Luc André Burdet
Responsible Area Director:

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

Careful review in light of three (3) known vendor implementations and interop.
Review raised quite a few nits/typos/ but more importantly 3 questions of substance-
1 which had already been raised on the alias before but I did not find any closure nor
was the document updated for it. Will follow-up with Authors.

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

There are many reviews from several individuals + vendors on the alias showing
good level of review & discussion of this draft.


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

No.

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

Raised as Shepherd review comment: the scale/convergence scheme proposed
is specific to PBB-EVPN. I believe it can be modified/extended to apply to EVPN as well,
and the draft almost implies that at one point. Asking authors to discuss this point explicitly.

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

Yes

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

Yes.
No WG discussion that I know of.

(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? 

Many individuals in WG have commented & agreed .

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

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

All NITS raised by the tool had been found during review & raised to authors' attention.

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

No.

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

Not in Rev-04, but comment to that effect raised in Review.

(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?

Normative to EVPN-IRB which is in Review.

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

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

No known.

(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 5226).

IANA allocation already made for new extended community subtype.

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

N/A.

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

No formal language sections.

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?

Internet Standard. Yes.

(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

This draft extends the Ethernet Segment (ES) concept of RFC7432 so that
an ES can be associated to a set of Ethernet Virtual Circuits (e.g., VLANs)
or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs).

Working Group Summary

Consensus achieved- even though most reviews/comments occurred at WGLC (i.e. late in process)

Document Quality

There are several existing vendors' implementations of the draft.


Personnel

Document Shepherd: Luc André Burdet
Responsible Area Director:

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

Careful review in light of three (3) known vendor implementations and interop.
Review raised quite a few nits/typos/ but more importantly 3 questions of substance-
1 which had already been raised on the alias before but I did not find any closure nor
was the document updated for it. Will follow-up with Authors.

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

There are many reviews from several individuals + vendors on the alias showing
good level of review & discussion of this draft.


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

No.

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

Raised as Shepherd review comment: the scale/convergence scheme proposed
is specific to PBB-EVPN. I believe it can be modified/extended to apply to EVPN as well,
and the draft almost implies that at one point. Asking authors to discuss this point explicitly.

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

Yes

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

Yes.
No WG discussion that I know of.

(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? 

Many individuals in WG have commented & agreed .

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

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

All NITS raised by the tool had been found during review & raised to authors' attention.

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

No.

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

Not in Rev-04, but comment to that effect raised in Review.

(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?

Normative to EVPN-IRB which is in Review.

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

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

No known.

(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 5226).

IANA allocation already made for new extended community subtype.

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

N/A.

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

No formal language sections.