EVPN VPWS Flexible Cross-Connect Service
draft-ietf-bess-evpn-vpws-fxc-12

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-bess-evpn-vpws-fxc and RFC 9744, changed IESG state to RFC Published)

[Ballot comment]
Sorry for the noise -- because I was trying to multitask a little too much, I improperly moved from DISCUSS to NOOBJ when what I intended was ABSTAIN. To repeat the reasoning for the ABSTAIN, from my earlier ballot:

"After having reviewed this document, I can say that if I were a coder handed
this spec and told to implement it, I'd have a hard time. What I can't
determine is whether the spec is insufficient, or if it would be OK if I were
an experienced EVPN coder who had already memorized all the other specs.

"The top bullet on the IESG DISCUSS criteria list is "The specification is
impossible to implement due to technical or clarity issues." Because of the
ambiguity mentioned above, and because of the difficulty in providing you a
specific action plan to resolve it, I ultimately plan to ballot ABSTAIN on this
document."

I will review the current revision (I haven't done a full re-review yet) and see if the updates allow me to move to NOOBJ.

## COMMENT

### Section 1

  Some service providers have very large number of ACs (in millions)
  that need to be back hauled across their MPLS/IP network.  These ACs
  may or may not require tag manipulation (e.g., VLAN translation).
  These service providers want to multiplex a large number of ACs
  across several physical interfaces spread across one or more PEs
  (e.g., several Ethernet Segments) onto a single VPWS service tunnel
  in order to a) reduce number of EVPN service labels associated with
  EVPN-VPWS service tunnels and thus the associated OAM monitoring, and
  b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is
  the case in [RFC8214]).

As far as I can tell, (b) isn't satisfied by the "VLAN-Signaled Flexible Xconnect" mode, because in that mode "the PE sends a single Ethernet A-D per EVI route for each AC that is configured".

I don't have a problem with you providing a menu of different options to meet different operators' needs, but I think the Introduction should be clearer about this.

As an aside, I found the "some service providers... these service provider" writing style of the Introduction to be unusual and a little distracting.

### Section 1.1, terms that aren't needed here

These terms are defined, never referenced:

- CE
- EPL

These terms are defined, only used once, so you might as well just expand them in-line:

- EVPL (already expanded in-line)
- L2 (your single use is in a diagram, so if you don't want to clutter it, OK,
  though the expansion would fit. But unlike many of the abbreviations in this
  document, I don't think this one actually needs definition.)
- MTU (same comment as for L2. This one is starred as "well-known" on the RFCEd
  list of abbreviations. I've asked the RFCEd why "L2" isn't starred.)
- VCCV

PW is used twice but really, there is no savings in time, space, or readability, from defining and then using an initialism. I suggest just writing out "pseudowire" those two places. One of them precedes the definition anyway.

RT is used 3x but defined in-line each time so you don't need a definition here.

VRF has a typo. You've called it "Virtual Route Forwarding". But https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list says it is "Virtual Routing and Forwarding". Although RFC 4364 is the authority AFAICT and it says "VPN Routing and Forwarding table" which I think is better -- "table" is important.

### Section 3.1, VLAN-Aware bundle

I can't understand what this means:

  *  VLAN-Aware Bundle : a unique value for individual VLANs, and is
      considered same as the normalised VID.

I was hoping it would become clear as I read the rest of the document, but it didn't. Indeed this is the only place "VLAN-Aware Bundle" is mentioned.

### Section 3.1, ASBR

Please expand ASBR on use.

### Section 3.2, how do PEs know about VLAN mappings?

  Regarding the data-plane aspects of this solution, both imposition
  and disposition Provider Edge (PE) devices MUST be aware of the VLANs
  as the imposition PE performs VID normalization and the disposition
  PE carries out VID lookup and translation.
 
I guess the assumption is that this is done through configuration, hopefully through a management system. I think the document really has to say this somewhere, even if the precise means of doing it is out of scope. It seems like a fundamental assumption, but it's never spelled out.

### Section 3.2, SHOULD ideally

                                              There SHOULD ideally be a
  single point-to-point (P2P) EVPN VPWS service tunnel between a pair
  of PEs for a specific set of Attachment Circuits (ACs).

It's hard for me to understand this use of RFC 2119 SHOULD. Normally RFC 2119 keywords tell the protocol implementor what to do. I don't see how an implementor could do anything with this, though. Sometimes, RFC 2119 keywords are (ab)used to tell operators how to deploy a solution. I *think* that's what you're doing here, but if so I think at a minimum, you have to be much clearer about that, something like, "When deploying the solution, the operator SHOULD ideally provision a single..." I also encourage you to drop the RFC 2119 keyword, and just use "should".

### Section 3.2 VID-VRF

I think you need to put "VID-VRF" in your Terminology section, or otherwise define it.

### Section 5, VCCV-BFD

You mention VCCV-BFD, but you don't have a reference for it. Please add one.

### Section 5, switchover procedure

                                                                the
  switch over procedure to the backup S-PE is the same as the one
  described above.
 
I don't see any switchover procedure described above. What am I missing?

## NITS

- In Section 3.2, "The generated EVPN route is an Ethernet A-D per EVI route with and ESI of 0" should be "The generated EVPN route is an Ethernet A-D per EVI route with an ESI of 0" ("an" not "and").

[Ballot comment]
Thanks for working so quickly to resolve my DISCUSS.

I think I saw that you had worked on my comments, too, but I haven't reviewed those yet. Will do so soon.

## COMMENT

### Section 1

  Some service providers have very large number of ACs (in millions)
  that need to be back hauled across their MPLS/IP network.  These ACs
  may or may not require tag manipulation (e.g., VLAN translation).
  These service providers want to multiplex a large number of ACs
  across several physical interfaces spread across one or more PEs
  (e.g., several Ethernet Segments) onto a single VPWS service tunnel
  in order to a) reduce number of EVPN service labels associated with
  EVPN-VPWS service tunnels and thus the associated OAM monitoring, and
  b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is
  the case in [RFC8214]).

As far as I can tell, (b) isn't satisfied by the "VLAN-Signaled Flexible Xconnect" mode, because in that mode "the PE sends a single Ethernet A-D per EVI route for each AC that is configured".

I don't have a problem with you providing a menu of different options to meet different operators' needs, but I think the Introduction should be clearer about this.

As an aside, I found the "some service providers... these service provider" writing style of the Introduction to be unusual and a little distracting.

### Section 1.1, terms that aren't needed here

These terms are defined, never referenced:

- CE
- EPL

These terms are defined, only used once, so you might as well just expand them in-line:

- EVPL (already expanded in-line)
- L2 (your single use is in a diagram, so if you don't want to clutter it, OK,
  though the expansion would fit. But unlike many of the abbreviations in this
  document, I don't think this one actually needs definition.)
- MTU (same comment as for L2. This one is starred as "well-known" on the RFCEd
  list of abbreviations. I've asked the RFCEd why "L2" isn't starred.)
- VCCV

PW is used twice but really, there is no savings in time, space, or readability, from defining and then using an initialism. I suggest just writing out "pseudowire" those two places. One of them precedes the definition anyway.

RT is used 3x but defined in-line each time so you don't need a definition here.

VRF has a typo. You've called it "Virtual Route Forwarding". But https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list says it is "Virtual Routing and Forwarding". Although RFC 4364 is the authority AFAICT and it says "VPN Routing and Forwarding table" which I think is better -- "table" is important.

### Section 3.1, VLAN-Aware bundle

I can't understand what this means:

  *  VLAN-Aware Bundle : a unique value for individual VLANs, and is
      considered same as the normalised VID.

I was hoping it would become clear as I read the rest of the document, but it didn't. Indeed this is the only place "VLAN-Aware Bundle" is mentioned.

### Section 3.1, ASBR

Please expand ASBR on use.

### Section 3.2, how do PEs know about VLAN mappings?

  Regarding the data-plane aspects of this solution, both imposition
  and disposition Provider Edge (PE) devices MUST be aware of the VLANs
  as the imposition PE performs VID normalization and the disposition
  PE carries out VID lookup and translation.
 
I guess the assumption is that this is done through configuration, hopefully through a management system. I think the document really has to say this somewhere, even if the precise means of doing it is out of scope. It seems like a fundamental assumption, but it's never spelled out.

### Section 3.2, SHOULD ideally

                                              There SHOULD ideally be a
  single point-to-point (P2P) EVPN VPWS service tunnel between a pair
  of PEs for a specific set of Attachment Circuits (ACs).

It's hard for me to understand this use of RFC 2119 SHOULD. Normally RFC 2119 keywords tell the protocol implementor what to do. I don't see how an implementor could do anything with this, though. Sometimes, RFC 2119 keywords are (ab)used to tell operators how to deploy a solution. I *think* that's what you're doing here, but if so I think at a minimum, you have to be much clearer about that, something like, "When deploying the solution, the operator SHOULD ideally provision a single..." I also encourage you to drop the RFC 2119 keyword, and just use "should".

### Section 3.2 VID-VRF

I think you need to put "VID-VRF" in your Terminology section, or otherwise define it.

### Section 5, VCCV-BFD

You mention VCCV-BFD, but you don't have a reference for it. Please add one.

### Section 5, switchover procedure

                                                                the
  switch over procedure to the backup S-PE is the same as the one
  described above.
 
I don't see any switchover procedure described above. What am I missing?

## NITS

- In Section 3.2, "The generated EVPN route is an Ethernet A-D per EVI route with and ESI of 0" should be "The generated EVPN route is an Ethernet A-D per EVI route with an ESI of 0" ("an" not "and").

[Ballot comment]
John Scudder's concerns about implementability are cause for alarm.  I suggest this be investigated further even if the ballot is otherwise sufficient to pass.  In any event, I also support his DISCUSS position.

Sections 3 and 4 each contain a SHOULD that would be helped by offering guidance to implementers about when it might be appropriate to deviate, and what the impact of deviating would be on operations.  If that's not really possible, maybe this ought to be a MUST or MAY.

[Ballot comment]
Thank you to Joel Haplern for the GENART review. He suggests clarifying language that I also agree would be helpful.

Per Section 7:

7.  IANA Considerations

  This document requests allocation of bits 8-11 in the "EVPN Layer 2
  Attributes Control Flags" registry with names M and V:

      M    Signaling mode of operation (2 bits)
      V    VLAN-ID normalization (2 bits)

(Editorial) Please explicitly note that M gets bits 8-9 and V gets bits 10-11.

[Ballot comment]
## COMMENT

### Section 1

  Some service providers have very large number of ACs (in millions)
  that need to be back hauled across their MPLS/IP network.  These ACs
  may or may not require tag manipulation (e.g., VLAN translation).
  These service providers want to multiplex a large number of ACs
  across several physical interfaces spread across one or more PEs
  (e.g., several Ethernet Segments) onto a single VPWS service tunnel
  in order to a) reduce number of EVPN service labels associated with
  EVPN-VPWS service tunnels and thus the associated OAM monitoring, and
  b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is
  the case in [RFC8214]).

As far as I can tell, (b) isn't satisfied by the "VLAN-Signaled Flexible Xconnect" mode, because in that mode "the PE sends a single Ethernet A-D per EVI route for each AC that is configured".

I don't have a problem with you providing a menu of different options to meet different operators' needs, but I think the Introduction should be clearer about this.

As an aside, I found the "some service providers... these service provider" writing style of the Introduction to be unusual and a little distracting.

### Section 1.1, terms that aren't needed here

These terms are defined, never referenced:

- CE
- EPL

These terms are defined, only used once, so you might as well just expand them in-line:

- EVPL (already expanded in-line)
- L2 (your single use is in a diagram, so if you don't want to clutter it, OK,
  though the expansion would fit. But unlike many of the abbreviations in this
  document, I don't think this one actually needs definition.)
- MTU (same comment as for L2. This one is starred as "well-known" on the RFCEd
  list of abbreviations. I've asked the RFCEd why "L2" isn't starred.)
- VCCV

PW is used twice but really, there is no savings in time, space, or readability, from defining and then using an initialism. I suggest just writing out "pseudowire" those two places. One of them precedes the definition anyway.

RT is used 3x but defined in-line each time so you don't need a definition here.

VRF has a typo. You've called it "Virtual Route Forwarding". But https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list says it is "Virtual Routing and Forwarding". Although RFC 4364 is the authority AFAICT and it says "VPN Routing and Forwarding table" which I think is better -- "table" is important.

### Section 3.1, VLAN-Aware bundle

I can't understand what this means:

  *  VLAN-Aware Bundle : a unique value for individual VLANs, and is
      considered same as the normalised VID.

I was hoping it would become clear as I read the rest of the document, but it didn't. Indeed this is the only place "VLAN-Aware Bundle" is mentioned.

### Section 3.1, ASBR

Please expand ASBR on use.

### Section 3.2, how do PEs know about VLAN mappings?

  Regarding the data-plane aspects of this solution, both imposition
  and disposition Provider Edge (PE) devices MUST be aware of the VLANs
  as the imposition PE performs VID normalization and the disposition
  PE carries out VID lookup and translation.
 
I guess the assumption is that this is done through configuration, hopefully through a management system. I think the document really has to say this somewhere, even if the precise means of doing it is out of scope. It seems like a fundamental assumption, but it's never spelled out.

### Section 3.2, SHOULD ideally

                                              There SHOULD ideally be a
  single point-to-point (P2P) EVPN VPWS service tunnel between a pair
  of PEs for a specific set of Attachment Circuits (ACs).

It's hard for me to understand this use of RFC 2119 SHOULD. Normally RFC 2119 keywords tell the protocol implementor what to do. I don't see how an implementor could do anything with this, though. Sometimes, RFC 2119 keywords are (ab)used to tell operators how to deploy a solution. I *think* that's what you're doing here, but if so I think at a minimum, you have to be much clearer about that, something like, "When deploying the solution, the operator SHOULD ideally provision a single..." I also encourage you to drop the RFC 2119 keyword, and just use "should".

### Section 3.2 VID-VRF

I think you need to put "VID-VRF" in your Terminology section, or otherwise define it.

### Section 5, VCCV-BFD

You mention VCCV-BFD, but you don't have a reference for it. Please add one.

### Section 5, switchover procedure

                                                                the
  switch over procedure to the backup S-PE is the same as the one
  described above.
 
I don't see any switchover procedure described above. What am I missing?

## NITS

- In Section 3.2, "The generated EVPN route is an Ethernet A-D per EVI route with and ESI of 0" should be "The generated EVPN route is an Ethernet A-D per EVI route with an ESI of 0" ("an" not "and").

[Ballot discuss]
After having reviewed this document, I can say that if I were a coder handed this spec and told to implement it, I'd have a hard time. What I can't determine is whether the spec is insufficient, or if it would be OK if I were an experienced EVPN coder who had already memorized all the other specs.

The top bullet on the IESG DISCUSS criteria list is "The specification is impossible to implement due to technical or clarity issues." Because of the ambiguity mentioned above, and because of the difficulty in providing you a specific action plan to resolve it, I ultimately plan to ballot ABSTAIN on this document.

However, before entering that position, I have one specific issue to raise as a DISCUSS. I think this will be easy to resolve. I also have several comments I hope you will consider.

## DISCUSS

### Section 4, reserved for flow-label

  The following bits in the Control Flags are defined; the remaining
...
      Name    Meaning
      ---------------------------------------------------------------
...
      -        reserved for Flow-label

This is the only place in the document flow-label is mentioned. There is no reference to a controlling document, unlike the other flags that reference RFC 8214. The IANA registry doesn't have a registration for this flag.

I don't know what the correct way to fix this is, because I have no idea what's going on here, but it doesn't seem proper as it stands.

[Ballot comment]
## COMMENT

### Section 1

  Some service providers have very large number of ACs (in millions)
  that need to be back hauled across their MPLS/IP network.  These ACs
  may or may not require tag manipulation (e.g., VLAN translation).
  These service providers want to multiplex a large number of ACs
  across several physical interfaces spread across one or more PEs
  (e.g., several Ethernet Segments) onto a single VPWS service tunnel
  in order to a) reduce number of EVPN service labels associated with
  EVPN-VPWS service tunnels and thus the associated OAM monitoring, and
  b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is
  the case in [RFC8214]).

As far as I can tell, (b) isn't satisfied by the "VLAN-Signaled Flexible Xconnect" mode, because in that mode "the PE sends a single Ethernet A-D per EVI route for each AC that is configured".

I don't have a problem with you providing a menu of different options to meet different operators' needs, but I think the Introduction should be clearer about this.

As an aside, I found the "some service providers... these service provider" writing style of the Introduction to be unusual and a little distracting.

### Section 1.1, terms that aren't needed here

These terms are defined, never referenced:

- CE
- EPL

These terms are defined, only used once, so you might as well just expand them in-line:

- EVPL (already expanded in-line)
- L2 (your single use is in a diagram, so if you don't want to clutter it, OK, though the expansion would fit. But unlike many of the abbreviations in this document, I don't think this one actually needs definition.)
- MTU (same comment as for L2. This one is starred as "well-known" on the RFCEd list of abbreviations. I've asked the RFCEd why "L2" isn't starred.)
- VCCV

PW is used twice but really, there is no savings in time, space, or readability, from defining and then using an initialism. I suggest just writing out "pseudowire" those two places. One of them precedes the definition anyway.

RT is used 3x but defined in-line each time so you don't need a definition here.

VRF has a typo. You've called it "Virtual Route Forwarding". But https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list says it is "Virtual Routing and Forwarding". Although RFC 4364 is the authority AFAICT and it says "VPN Routing and Forwarding table" which I think is better -- "table" is important.

### Section 3.1, VLAN-Aware bundle

I can't understand what this means:

  *  VLAN-Aware Bundle : a unique value for individual VLANs, and is
      considered same as the normalised VID.

I was hoping it would become clear as I read the rest of the document, but it didn't. Indeed this is the only place "VLAN-Aware Bundle" is mentioned.

### Section 3.1, ASBR

Please expand ASBR on use.

### Section 3.2, how do PEs know about VLAN mappings?

  Regarding the data-plane aspects of this solution, both imposition
  and disposition Provider Edge (PE) devices MUST be aware of the VLANs
  as the imposition PE performs VID normalization and the disposition
  PE carries out VID lookup and translation.
 
I guess the assumption is that this is done through configuration, hopefully through a management system. I think the document really has to say this somewhere, even if the precise means of doing it is out of scope. It seems like a fundamental assumption, but it's never spelled out.

### Section 3.2, SHOULD ideally

                                              There SHOULD ideally be a
  single point-to-point (P2P) EVPN VPWS service tunnel between a pair
  of PEs for a specific set of Attachment Circuits (ACs).

It's hard for me to understand this use of RFC 2119 SHOULD. Normally RFC 2119 keywords tell the protocol implementor what to do. I don't see how an implementor could do anything with this, though. Sometimes, RFC 2119 keywords are (ab)used to tell operators how to deploy a solution. I *think* that's what you're doing here, but if so I think at a minimum, you have to be much clearer about that, something like, "When deploying the solution, the operator SHOULD ideally provision a single..." I also encourage you to drop the RFC 2119 keyword, and just use "should".

### Section 3.2 VID-VRF

I think you need to put "VID-VRF" in your Terminology section, or otherwise define it.

### Section 5, VCCV-BFD

You mention VCCV-BFD, but you don't have a reference for it. Please add one.

### Section 5, switchover procedure

                                                                the
  switch over procedure to the backup S-PE is the same as the one
  described above.
 
I don't see any switchover procedure described above. What am I missing?

## NITS

- In Section 3.2, "The generated EVPN route is an Ethernet A-D per EVI route with and ESI of 0" should be "The generated EVPN route is an Ethernet A-D per EVI route with an ESI of 0" ("an" not "and").

[Ballot comment]
# Internet AD comments for draft-ietf-bess-evpn-vpws-fxc-09
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/

## Nits

### S1

* s/back hauled/backhauled/ (I think "backhaul" is okay as one word)

* "These service provider" -> "These service providers"

* " without scarifying" -> "without sacrificing"

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-vpws-fxc-09

Thank you for the work put into this document. I found the document very difficult to read and understand, notably with long sentences and absence of graphics in the first sections. This may also be caused by my lack of BESS expertise of course, therefore I was unable to do a deep review of this I-D.

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

Special thanks to Stéphane Litkowski for the shepherd's write-up (including the justification for 6 authors and of the intended status).

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

Should "EVPN VPWS" be expanded ? Even if https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list lists them, it will make the reader task easier.

Suggest to split the abstract in 3 paragraphs.

## Section 1

s/These service provider want the above functionality without scarifying any of the capabilities/These service provider*s* want the above functionality without *sacrificing* any of the capabilities/ ?

s/This document presents a solution/This document specifies a solution/

## Section 1.1

Why is there a difference between "Single-Active Redundancy Mode" and "All-Active Redundancy Mode" as the former allows for `When a device *or a network* is multi‑homed`

## Section 3

Generic comment on this section and its sub-section, the text is descriptive only and not really a complete specification, e.g., nothing is specified about things going wrong (section 5 is about failures though).

Be more assertive in a PS, e.g., s/This section outlines a solution for providing/This section specifies how to provide/

Rather than leaving up to the reader to guess what is a "normalized VID", let's define it in the previous paragraph.

Should there be a reference for `Ethernet tag` (e.g., IEEE 802.1Q or another RFC) ? A small graphic would also make the text easier to read.

Any suggestion on how this can be achieved ? `Operators should be informed of potential trade-offs `

While the text specifies what is to be done at the ingress, it is silent about control plane (add a reference ?) and what the egress should do.

## Section 3.1

Should "ASBR" be expanded ? Or simply use the expansion as it is used only here.

## Section 3.2

Please expand "XConnect" somewhere.

## Section 3.3

`Provider Edge (PE)` the PE acronym has been used before and should not be expanded here.

## Section 4

It may be worth repeating the text of RFC 8214 about the 'reserved' field.

## Section 7

Is it worth adding the registry URI ? I.E., https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn-layer-2-attributes-control-flags


# NITS (non-blocking / cosmetic)

The use of the aasvg tool would make the HTML rendering of the figures much easier to read.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a strong consensus around this draft, including multiple implementations.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are already couple of implementations shipping and deployed in field.
Official documentations from vendors are available on the web (Juniper, Cisco).
Ciena, Cisco also mentioned during implementation poll that they support it

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No, this is an EVPN related extension.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG model

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd has reviewed the document, provided comments to Authors. Nits have been checked too.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is considered as ready to go.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document has been reviewed by GENART, OPSDIR, RTGDIR and comments have been addressed.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is targeting standard track, it defines new behaviors and encoding which makes standard track appropriate.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

IPR polls have been done during WG adoption and WG last call. IPR disclosures have been filled up.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

This work comes a strong collaboration between various vendors and operators that all contributed to the draft. The document has 6 authors, but given the level of implication of all of them during the process of writing the draft, it would not be fair to remove one of them.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Not nits found (fixed them already)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References have been checked and look OK

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

References have been checked and look OK

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

It doesn't

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

IANA section is clearly written.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Registry is RFC Required and doesn't require Expert review.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a strong consensus around this draft, including multiple implementations.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are already couple of implementations shipping and deployed in field.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No, this is an EVPN related extension.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG model

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd has reviewed the document, provided comments to Authors. Nits have been checked too.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is considered as ready to go.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document has been reviewed by GENART, OPSDIR, RTGDIR and comments have been addressed.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is targeting standard track, it defines new behaviors and encoding which makes standard track appropriate.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

IPR polls have been done during WG adoption and WG last call. IPR disclosures have been filled up.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

This work comes a strong collaboration between various vendors and operators that all contributed to the draft. The document has 6 authors, but given the level of implication of all of them during the process of writing the draft, it would not be fair to remove one of them.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Not nits found (fixed them already)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References have been checked and look OK

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

References have been checked and look OK

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

It doesn't

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

IANA section is clearly written.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Registry is RFC Required and doesn't require Expert review.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

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

IANA has completed its review of draft-ietf-bess-evpn-vpws-fxc-09. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the EVPN Layer 2 Attributes Control Flags registry in the Border Gateway Protocol (BGP) Extended Communities registry group located at:

https://www.iana.org/assignments/bgp-extended-communities/

two new registrations will be made as follows:

Sub-Type Value: M
Name: Signaling mode of operation (2 bits)
Reference: [ RFC-to-be ]
Date: [ TBD-at-Registration ]

Sub-Type Value: V
Name: VLAN-ID normalization (2 bits)
Reference: [ RFC-to-be ]
Date: [ TBD-at-Registration ]

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action that will be performed.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-10-04):

From: The IESG
To: IETF-Announce
CC: bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-vpws-fxc@ietf.org, gunter@vandevelde.cc, slitkows.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (EVPN VPWS Flexible Cross-Connect Service) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'EVPN VPWS Flexible Cross-Connect Service'
  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 2024-10-04. 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 describes a new EVPN VPWS service type specifically for
  multiplexing multiple attachment circuits across different Ethernet
  Segments and physical interfaces into a single EVPN VPWS service
  tunnel and still providing Single-Active and All-Active multi-homing.
  This new service is referred to as flexible cross-connect service.
  After a description of the rationale for this new service type, the
  solution to deliver such service is detailed.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/


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

  https://datatracker.ietf.org/ipr/3176/
  https://datatracker.ietf.org/ipr/3170/

Following up on length of author list and will submit a list of nits to the authors shortly that need to be resolved prior to last call

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 1 November 2019.

(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 RFC type requested is "Proposed Standard". The draft defines some protocol extensions are requires interoperability so the intended document type is right.


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

The document defines a way to multiplex multiple attachment circuits (that spans multiple Ethernet segments and physical interfaces) into a single EVPN VPWS service including multi-homing.


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?

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, YANG 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?

There are multiple existing implementations from this specification. There hasn't been any substantive change or issues on the draft.



Personnel:

Stephane Litkowski is the document shepherd
Andrew Alston is the responsible AD


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

The shepherd read the document and provided comments to the authors that have been addressed.
References and IANA section has been checked as well.

The document is considered as ready.


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

No concern.

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

No concern

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

There are two IPR disclosures on the document and WG didn't comment or raised concern about these IPRs.


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

There is a solid WG consensus.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nits have been addressed by authors

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

not applicable

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

no

(15) Are there downward normative 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.

No

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

IANA section is clear

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

No expert review 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, YANG modules, etc.

not applicable

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

not applicable

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 1 November 2019.

(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 RFC type requested is "Proposed Standard". The draft defines some protocol extensions are requires interoperability so the intended document type is right.


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

The document defines a way to multiplex multiple attachment circuits (that spans multiple Ethernet segments and physical interfaces) into a single EVPN VPWS service including multi-homing.


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?

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, YANG 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?

There are multiple existing implementations from this specification. There hasn't been any substantive change or issues on the draft.



Personnel:

Stephane Litkowski is the document shepherd
Andrew Alston is the responsible AD


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

The shepherd read the document and provided comments to the authors that have been addressed.
References and IANA section has been checked as well.

The document is considered as ready.


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

No concern.

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

No concern

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

There are two IPR disclosures on the document and WG didn't comment or raised concern about these IPRs.


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

There is a solid WG consensus.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nits have been addressed by authors

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

not applicable

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

no

(15) Are there downward normative 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.

No

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

IANA section is clear

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

No expert review 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, YANG modules, etc.

not applicable

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

not applicable

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 1 November 2019.

(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 RFC type requested is "Proposed Standard". The draft defines some protocol extensions are requires interoperability so the intended document type is right.


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

The document defines a way to multiplex multiple attachment circuits (that spans multiple Ethernet segments and physical interfaces) into a single EVPN VPWS service including multi-homing.


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?

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, YANG 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?

There are multiple existing implementations from this specification. There hasn't been any substantive change or issues on the draft.



Personnel:

Stephane Litkowski is the document shepherd
Martin Vigoureux is the responsible AD


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

The shepherd read the document and provided comments to the authors that have been addressed.
References and IANA section has been checked as well.

The document is considered as ready.


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

No concern.

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

No concern

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

There are two IPR disclosures on the document and WG didn't comment or raised concern about these IPRs.


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

There is a solid WG consensus.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nits have been addressed by authors

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

not applicable

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

no

(15) Are there downward normative 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.

No

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

IANA section is clear

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

No expert review 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, YANG modules, etc.

not applicable

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

not applicable

Request for posting confirmation emailed to previous authors: Jorge Rabadan , Wen Lin , Ali Sajassi , Sami Boutros , John Drake , bess-chairs@ietf.org, Jim Uttaro , Patrice Brissette

Request for posting confirmation emailed to previous authors: John Drake , Jorge Rabadan , Sami Boutros , Jim Uttaro , Patrice Brissette , Ali Sajassi , Wen Lin