EVPN BUM Using BIER
draft-ietf-bier-evpn-14

[Ballot comment]
Just some minor nits/suggestions:

Minor level comments:

(1) p 3, sec 2.  Use of the PMSI Tunnel Attribute

      1  The first subfield is a single octet, containing the sub-
        domain-id of the sub-domain to which the BFIR will assign the
        packets that it transmits on the PMSI identified by the NLRI of
        the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that
        contains this PTA.  How that sub-domain is chosen is outside
        the scope of this document.

What does I-PMSI stand for?


(2) p 7, sec 3.  Multihoming Split Horizon

  For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify
  the ES from which a BUM packet originates.  A PE receiving that
  packet from the core side will not forward it to the same ES.  The
  procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP
  P2MP tunnels, using downstream- and upstream-assigned ESI labels
  respectively.  For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local
  bias procedures, with which a PE receiving a BUM packet from the core
  side knows from encapsulation the ingress PE so it does not forward
  the packet to any multihoming ESes that the ingress PE is on, because
  the ingress PE already forwarded the packet to those ESes, regardless
  of whether the ingress PE is a DF for those ESes.

Perhaps expand DF to designated forwarder?



Nit level comments:

(3) p 4, sec 2.1.  IP-Based Tunnel and BIER PHP

  When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP
  header (and UDP header in the case of VXLAN/GENVE) is not included in
  the BIER payload, except when it is known apriori that BIER PHP [I-
  D.ietf-bier-php] is used in the BIER domain and the encapsulation
  (after the BIER header is popped) between the BIER Penultimate Hop
  and the egress PE does not have a way to indicate the next header is
  VXLAN/NVGRE/GENEVE.  In that case the full VXLAN/NVGRE/GENEVE
  encapsulation with an IP header MUST be included in the BIER payload.
  A well-known IP multicast address (to be assigned by IANA) is used as
  the destination address and the egress PEs MUST be set up to receive
  and process packets addressed to the address.  The address is used
  for all BDs and the inner VXLAN/NVGRE/GENEVE header will be used to
  identify BDs.

I assume PHP is "penultimate hop pop", but that doesn't appear to be specified.

Regards,
Rob

[Ballot comment]
# GEN AD review of draft-ietf-bier-evpn-12

CC @larseggert

## Comments

### Section 2, paragraph 4
```
    *  "Tunnel Type".  The same codepoint 0x0B that IANA has assigned for
        BIER for MVPN [RFC8556] is used for EVPN as well.
```
Should this document update RFC8556? It reuses the 0x0B codepoint, but
the definition of "MPLS label" (and "Flags"?) seems to be
broader/different than that in RFC8556?

### Section 2, paragraph 3
```
    *  "Tunnel Identifier".  This field contains three subfields for
        BIER.  The text below is exactly as in [RFC8556].
```
It would be better to normatively cite the relevant section in RFC8556
rather than to replicate its text here. (If that part of RFC8556 is
ever updated by another RFC, the copy here will be inconsistent.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4.1.1, paragraph 2
```
-        packet after the ethernet header, the IMET route originated for
-                        ^
+        packet after the Ethernet header, the IMET route originated for
+                        ^
```

## 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. Review generated by the [`ietf-reviewtool`][IRT].

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

[Ballot comment]
Due to a late change to the document that requested IPv6 multicast registry assignments - which require expert review (The v4 registries don't require expert review), IANA has asked me to hold this pending review by the designated expert.  The designated expert has confirmed he is doing a review and it should be done shortly.  In order to avoid a time delay by deferring this document to a telechat 2 weeks away, I'm issuing this discuss purely to allow the designated expert time to complete review and for IANA to be comfortable with progression.

# 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?
Yes

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

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)?
No implementation we are aware of

## 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.
Yes, BESS and BIER WG members were involved

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

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]?
NA

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

## 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?
Yes

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

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?
Proposed Standard, and its showing correctly in the document

This document is about using BIER as provider tunnels for EVPN.  It
is very similar to using BIER as an MVPN provider tunnel. there are lots
of similarities when compared to mVPN technology which is mature and
very well understood by WG  and implemented. That helps WG to understand
the overall requirement of using BIER as a provider tunnel and make design
choices. Based on this factor proposed standard is the proper type for
this document.

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.

Yes

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.
Its total less than 5 authors .

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

No

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

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

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

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

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

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]).
Yes
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.

[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://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/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/

NA

[Ballot comment]
Thank you for writing this document; I found it an interesting read.

I have a few comments / readability suggestions:

Section 3. Multihoming Split Horizon
"For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify
the ES from which a BUM packet originates. A PE receiving that
packet from the core side will not forward it to the same ES."

It is unclear what exactly "that packet" refers to - from my (limited) understanding the packets themselves don't carry ESI labels.

"For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local
bias procedures, with which a PE receiving a BUM packet from the
core side knows from encapsulation the ingress PE so it does not
forward the packet to any multihoming ESes that the ingress PE is
on, because the ingress PE already forwarded the packet to those
ESes, regardless of whether the ingress PE is a DF for those ESes."

This sentence is somewhat of a run-on. Perhaps moving the "from encapsulation" much earlier would help? Or perhaps splitting this into multiple sentences would help?

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

Thanks for this document. As usual with multicast documents, I largely am taking it on faith that the authors and WG know what they're doing, but I still have a few non-blocking comments, below.

## COMMENTS

### Section 1.1

- You define "AC", but only use it once, IMO the definition isn't needed in this case (for that matter the abbreviation isn't needed in Section 2.2.2.1, you can just use your words).

- "Sets of C-flows can be identified by the use of the "C-*" wildcard" -- I wonder if "denoted" would be a better term than "identified" in this context.

- "A multicast tunnel through the network of one or more SPs" -- presumably by "SPs" you mean "service providers". Probably better to write it out.

### Section 2.2.1

I can't understand what this sentence means: "Only when selectively forwarding is for all flows without tunnel segmentation, SMET routes are used without the need for S-PMSI A-D routes." Specifically, I can't parse the first clause. I would propose a rewrite if I had a solid guess as to what it meant, but alas.

### Section 2.2.2.1

I'm guessing that when you write, "It may be desired that SMET routes are not used to reduce the burden of explicit tracking", what you mean is "It may be desired that SMET routes are not used, in order to reduce the burden of explicit tracking"?

(See also https://en.wikipedia.org/wiki/Eats,_Shoots_%26_Leaves)

### Section 3

Please expand "DF".

### Section 4.1.1, best match

I trust/hope that other documents in the BIER/EVPN/MVPN set clearly define what "best match" means in this context. It's not intuitively obvious what things like "best match the source and destination IP address" mean, absent a definition.

### Section 4.1.2

"Each instance of the re-advertised route for a downstream region has a PTA that specifies tunnel information that is the same as or different from that of the route for a different region."

Possibly this is just my lack of expertise in the subject area and appreciation for your subtlety, but I don't see how the second half of the sentence conveys any information. Couldn't you rewrite it as "Each instance of the re-advertised route for a downstream region has a PTA."?

## 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]
Thanks for working on this specification.

I have some question that might need some clarifications-

  # Section 2.1, is says

        In that case the full VXLAN/NVGRE/GENEVE encapsulation with an IP header MUST be included in the BIER payload.

  The "IP header" here, does this mean outer IP header as mentioned in the beginning of this section? also what about UDP header in case of VXLAN/GENVE, should there be no requirements on that?

[Ballot comment]
# Internet AD comments for draft-ietf-bier-evpn-10
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

### S5

* Do you want to request an IPv6 multicast address as well?

[Ballot discuss]
# Éric Vyncke, INT AD, comments for draft-ietf-bier-evpn-10

Thank you for the work put into this document.

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

Special thanks to Mankamana Prasad Mishra for the shepherd's very succinct write-up even if I wonder what a "YES" answer means to a question about the WG consensus (as it has two clauses linked by a "OR"), it also *lacks* the justification for the intended status.

Other thanks to Haoyu Song, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-bier-evpn-10-intdir-telechat-song-2023-11-20/ (just a nit and I have read Jeffrey's reply)

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is simply a request to have a discussion on the following topics:

## BCP 14

Very similar to Roman's review, but I do think that it is DISCUSS level, i.e., please use the correct BCP14 template (including the reference to RFC 8174).

## IANA considerations

Please also have an IPv6 clause in `Preferably this is assigned from the Local Network Control Block (224.0.0/24).`. I.e., in section 2.1 there is normative text that requires this multicast address `A well-known IP multicast address (to be assigned by IANA)`.

## Section 2.2.1

The RFC editor abbreviation list has multiple expansions for "AC", which one is the correct one in this document? Suggest to expand "AC" on the first use as not every reader may have the context (in this case, guessing attachment circuit).

[Ballot comment]

# COMMENTS (non-blocking)

## Sections 1 & 2.2.2.2

The reference to draft-zzhang-bess-mvpn-evpn-cmcast-enhancements is about a non-adopted expired I-D, is this reference still useful?

## Section 1.1

Suggest to explicitly write that in "C-" the "C" stands for customer, similar comment for "P-tunnel".

Is it a prefix or an address in `BFR-Prefix: An IP address` ?

## Section 2.1

Even if "PHP" is a recognised RFC editor acronym, please expand "PHP" at first use for the less familiar readers.

Please expand "BD" at first use.

## Section 2.2.1

Expansion of SMET is already defined before, no need to expand it again.

Not being a BIER expert, I wonder whether `For a selective PMSI, the set of BFERs to deliver traffic to includes the originators of corresponding SMET routes.` is descriptive enough for an implementor.

## Section 4.1.1

In `a VXLAN/NVGRE/GENEVE header is prepended to the packet with the VNI/VSID set to the value in the PTA's label field` is it specified where the VNI/VSID is located in a NVGRE header ? My understanding (and happy to be corrected) is that NVGRE uses the same encapsulation as GRE, i.e., RFC 2784 does not have any VNI/VSID field. I was about to raise a discuss-discuss level (i.e., just a normal question) but I am trusting the responsible AD on this one.

## Section 5

Suggest to add reference to GENEVE/NVGRE/VXLAN.

## Section 6 (security considerations)

I will let the Security ADs chime in, but I wonder whether there should be recommendations to rate throttle the traffic to those BUM destinations, they are easily generated, can be faked, and will impact several BEFRs (including some shared by other customers). Or is it implicit in the list of references ?

# NITS (non-blocking / cosmetic)

## Section 1

`provider/underlay tunnels (referred to as P-tunnels)` the "P-tunnels" is already defined in section 1.1

## Section 2

Is it really useful to state the length of addresses in `This will either be a /32 IPv4 address or a /128 IPv6 address` ?

## Section 2.1

s/VXLAN/GENVE/VXLAN/GENEVE/ ?

## Section 3 (and other places)

Several acronyms are used without prior extension (e.g., "ES" and "ESI" in section 3), while most of them are included in https://www.rfc-editor.org/materials/abbrev.expansion.txt, it would help the reader to provide expansions for less known (to me at least ;-) ) acronyms. Thank you.

[Ballot comment]
Minor comments:

- Requirements language section should adhere to RFC8174 noting the change in boilerplate language.

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

- idnits complains about several unused and missing references - authors please correct these.

- Section 1: "Several kinds of tunnel technologies can be used, as specified in [RFC7432].". It would be helpful to specify what these tunnel technologies are (with references); also, RFC7432 only specifies the procedures for MPLS LSPs as the tunneling technology so the authors may want to clarify this in the text.

- Section 2.1: "When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP header (and UDP header in the case of VXLAN/GENVE).." - typo 'GENVE' correct to 'GENEVE'

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

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

IANA has a question about the second action requested in this document.

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

First, in the BIER Next Protocol Identifiers registry in the Bit Index Explicit Replication (BIER) registry group located at:

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

three new registrations are to be made as follows:

Value: [ TBD-at-registration ]
Description: Payload is VXLAN encapsulated (no IP/UDP header)
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: Payload is NVGRE encapsulated (no IP header)
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: Payload is GENEVE encapsulated (no IP/UDP header)
Reference: [ RFC-to-be ]

We note that the authors have requested values 7, 8 and 9 for these three registrations.

We also request that the first sentence of the IANA Considerations section of the document be changed to reflect the fact that three registrations are requested in the BIER Next Protocol Identifiers registry rather than two registrations.

Second, in the Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24)) registry in the IPv4 Multicast Address Space Registry group located at:

https://www.iana.org/assignments/multicast-addresses/

a single new registration will be made as follows:

Address(es): [ TBD-at-registration ]
Description: [??]
References: [RFC-to-be ]
Change Controller:
Date Registered: [ TBD-at-registration ]

IANA Question --> What should be the description for the multicast address assigned for this usage?

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

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

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 2023-10-05):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, bier-chairs@ietf.org, bier@ietf.org, draft-ietf-bier-evpn@ietf.org, mankamis@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (EVPN BUM Using BIER) to Proposed Standard


The IESG has received a request from the Bit Indexed Explicit Replication WG
(bier) to consider the following document: - 'EVPN BUM Using BIER'
  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-10-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies protocols and procedures for forwarding
  broadcast, unknown unicast, and multicast (BUM) traffic of Ethernet
  VPNs (EVPN) using Bit Index Explicit Replication (BIER).





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



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

# 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?
Yes

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

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)?
No implementation we are aware of

## 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.
Yes, BESS and BIER WG members were involved

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

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]?
NA

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

## 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?
Yes

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

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?
Proposed Standard, and its showing correctly in document

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.

Yes

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.
Its total less than 5 authors .

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

No

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

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

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

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

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

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]).
Yes
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.

[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://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/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/

NA

# 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?
Yes

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

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)?
No implementation we are aware of

## 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.
Yes, BESS and BIER WG members were involved

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

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]?
NA

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

## 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?
Yes

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

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?
Proposed Standard, and its showing correctly in document

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.

Yes

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.
Its total less than 5 authors .

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

No

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

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

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

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

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

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]).
Yes
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.

[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://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/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/

NA