Bit Index Explicit Replication (BIER) Ping and Trace
draft-ietf-bier-ping-21

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Also thanks to the authors (specifically Greg) for the productive discussions to address most comments from the original ballot.

Note: This is an updated ballot for v20. The points that are resolved are deleted but the previous
number has been retained.

A meta question for the WG is whether this document should be specific to BIER-MPLS and leave extensions for OAM for other data planes to future documents. OR, if the WG finds the document to be covering the other data planes of BIER adequately. Please see the discussion thread for more details and context: https://mailarchive.ietf.org/arch/msg/bier/sZZ0sgvoFvpq1ixx4LJVihxOJLc/


Following two discussion points are moved from DISCUSS to COMMENTS (the thread above provides more insight for them):

1031 5.1.  UDP Port Number

1033   This document requests a UDP port TBD1 to be allocated by IANA for
1034   BIER Echo.

Should this not be BIER OAM in general and not just for a specific
message types?


This is in general for all the IANA registries created and their
allocation rules. I would be interested in understanding the rationale for this
very complicated scheme with mix of various allocation policies and the WG
discussion around why this was necessary as opposed to a much simpler scheme
that is IETF Review + experimental/private use ?

Please consider similar can be done for section 5.6 - perhaps for consistency
just IETF Review, Experimental and Private Use - and because this space is so large
you may have split IETF Review into Standards Action and FCFS? And that is ok.

[Ballot comment]
Thanks for the work done in this document and also for the discussion and the revised I-D addressing my previous blocking DISCUSS at:
https://mailarchive.ietf.org/arch/msg/bier/Vnt5AJ719uPpSHE6nr-GN5s2dxw/

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I have a number of points that I would like to DISCUSS on this document that I am providing inline in the idnits o/p of v16 of this document.

Note: This is an updated ballot for v19. The points that are resolved are deleted but the previous number has been retained.

558               Type    Addr. Type      DA Length    DIA Length
559               -------  ---------------  ----------  ----------
560                   1      IPv4 Numbered        4              4
561                   2      IPv4 Unnumbered      4              4
562                   3      IPv6 Numbered        16            16
563                   4      IPv6 Unnumbered      16            4

What is IPv6 Unnumbered? I am not familiar with that term. Could you
please provide a reference? Or, is this a reference to an interface that
only has IPv6 link-local address and no IPv6 global address?

The change incorporated does not seem correct to me. Please check the email
thread below in MPLS WG on the errata on RFC8029 where the fix is being discussed:
https://mailarchive.ietf.org/arch/msg/mpls/0Wu12gufaYjW8mHXqkjIlAyB6sI/

[Ballot comment]
I would also like to share some comments inline in the idnits o/p of v16 of this document.

Note: This is an updated ballot for v19. The points that are resolved are deleted but the previous
number has been retained.

A meta question for the WG is whether this document should be specific to BIER-MPLS and leave extensions for OAM for other data planes to future documents. OR, if the WG finds the document to be covering the other data planes of BIER adequately. Please see the discussion thread for more details and context: https://mailarchive.ietf.org/arch/msg/bier/sZZ0sgvoFvpq1ixx4LJVihxOJLc/


Following two discussion points are moved from DISCUSS to COMMENTS (the thread above provides more insight for them):

1031 5.1.  UDP Port Number

1033   This document requests a UDP port TBD1 to be allocated by IANA for
1034   BIER Echo.

Should this not be BIER OAM in general and not just for a specific
message types?


This is in general for all the IANA registries created and their
allocation rules. I would be interested in understanding the rationale for this
very complicated scheme with mix of various allocation policies and the WG
discussion around why this was necessary as opposed to a much simpler scheme
that is IETF Review + experimental/private use ?

Please consider similar can be done for section 5.6 - perhaps for consistency
just IETF Review, Experimental and Private Use - and because this space is so large
you may have split IETF Review into Standards Action and FCFS? And that is ok.

Approval from AD: Short version: once all the remaining blocking DISCUSS ballots are cleared, this IETF Review draft will move forward with the requested port assignment.

A bit of context may help. OAM is a very different kind of application compared to most of the more traditional cases the port expert usually reviews. An OAM network service comes with quite different operational and security expectations. Early on, there was some confusion around this being a request for a port to carry multicast traffic. As the port expert rightly pointed out, different rules apply there, and using a dedicated multicast address is preferred over assigning a port number. That misunderstanding was discussed in detail and ultimately resolved by tightening up the text and being more explicit in the draft.

Where we landed is that the actual request is for a port used by unicast packets, operating in a closed and well-controlled environment. The protocol does not cause payload amplification in its responses, and payload confidentiality (authentication and/or encryption) is not only unnecessary but would actually be counter-productive for this specific OAM use case. The draft (draft-ietf-bier-ping) has also gone through the Security Directorate review twice and was reviewed during IESG evaluation by two Security ADs, with no security concerns identified.

Taking all of that together, once the remaining blocking DISCUSS items are resolved, I’m comfortable proceeding with the port assignment as requested by the document.

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I have a number of points that I would like to DISCUSS on this document that I am providing inline in the idnits o/p of v16 of this document.

Note: This is an updated ballot for v18. The points that are resolved are deleted but the previous number has been retained.


177 3.  BIER OAM

179   BIER OAM is defined to stay within the BIER layer by directly
180   following the BIER header without mandating the need for an IP
181   header.  [RFC8296] defines a 4-bit field as "Proto" to identify the
182   payload following the BIER header.  When the payload is BIER OAM, the
183   "Proto" field will be set to 5 as defined in [RFC8296]

I do not find the specification for setting the other fields in the
BIER header for OAM packets besides the Proto field. I find something about the
Entropy field usage further and about the use of BFIR-id and BitString but it
was not clear to me. Perhaps some specification in this section that covers
how the BIER header fields are set for BIER OAM packets would help clarify
along with forward reference to the respective sections that describe their
usage in further details?

209       Message Type - a six-bit field that identifies OAM protocol.
210       Values defined in this document are as follows:

212                   Value      Description
213                   --------  ---------------
214                     1        Echo Request
215                     2        Echo Reply

The handling of unknown types is undefined in this base specification.
E.g., how are implementations expected to handle a new Type 3 message defined by
as future specification that it does not recognize? While I am raising the point
for the message types, it also applies to all levels of TLVs/sub-TLVs as well.
For some TLVs, when unrecognized are present, the operation has been specified
to error out and I wanted to confirm that was intended given that it restricts
extensions.


Regarding section 3.2. Is it possible that more than one error
code is applicable at the responder for a given echo request? If so, I assume
these are supposed to be an ordered set rules (called "steps" in section 4.4)
that need to be followed by an implementation in determining the Return Code?
Please check for redundancy between the text in this section and 4.4 - best to
specify in one place. I am guessing the purpose of the text in this section
was to describe those error codes, but the description includes normative
procedures - best to do so in one place like section 4.4? This still leaves
the part that what is needed in section 4.4 is ordering (with a numbered list?)
- this also allows for further specifications that introduce more TLVs or
verification checks to introduce their error codes/handling in an appropriate
position in the sequence by updating this specification.

The multiple error codes part is clarified, but the discussion on
the use of a numbered list in section 4.4 remains open.


558               Type    Addr. Type      DA Length    DIA Length
559               -------  ---------------  ----------  ----------
560                   1      IPv4 Numbered        4              4
561                   2      IPv4 Unnumbered      4              4
562                   3      IPv6 Numbered        16            16
563                   4      IPv6 Unnumbered      16            4

What is IPv6 Unnumbered? I am not familiar with that term. Could you
please provide a reference? Or, is this a reference to an interface that
only has IPv6 link-local address and no IPv6 global address?


737 3.3.7.  Upstream Interface TLV

739   The BFR replying to the request MUST include the Upstream Interface
740   TLV.  This TLV identifies the incoming interface and the BIER-MPLS
741   label in the incoming Echo Request.  This TLV has the following
742   format:

I don't see the BIER-MPLS label being carried in this TLV. Am I
missing something? Also, I see that the ping but more so the traceroute
procedures in this document work only for MPLS and not for other data planes.
Am I correct? If so, perhaps this needs to be called out in the abstract
and introduction?

770 3.4.  Multipath Entropy Data Encoding

772   The size of the Entropy field in the BIER header is 20 bits, as
773   defined in Section 2 of [RFC8296].  This encoding is the same as the
774   Multipath Type 9 encoding, defined in Section 3.4.1.1.1 of [RFC8029].

RFC8029 talks about MPLS and how the IP destination address for an
LSP Ping packet is encoded. I don't see how that applies to BIER Echo Request.
What is required is perhaps the entropy encoding but I don't follow how that
would work. Please clarify.

814 4.3.  Sending BIER Echo Request

816   The Initiator MUST set the Message Type as 1 and Return Code as 0.
817   The Proto field in the OAM packet MUST be set to 0.  The choice of

Does this precludes the use of any padding or such to increase the
size of the BIER OAM packet to debug issues with specific packet sizes? I don't
see a padding TLV and neither do I see the ability to carry some other payload.
Has this been discussed/considered by the WG?

1031 5.1.  UDP Port Number

1033   This document requests a UDP port TBD1 to be allocated by IANA for
1034   BIER Echo.

Should this not be BIER OAM in general and not just for a specific
message types?

This is in general for all the IANA registries created and their
allocation rules. I would be interested in understanding the rationale for this
very complicated scheme with mix of various allocation policies and the WG
discussion around why this was necessary as opposed to a much simpler scheme
that is IETF Review + experimental/private use ?


FCFS has changed to RFC Required but the discussion point still remains.
Perhaps the 2 unassigned rows in Table 3 were meant to fall on the boundaries
of these different allocation schemes?

[Ballot comment]
I would also like to share some comments inline in the idnits o/p of v16 of this document.

I support the DISCUSS from Roman and some of the DISCUSS points raised by Med.


285                   Value      Description
286                   --------  ---------------
287                     1        Do not Reply
288                     2        Reply via IPv4/IPv6 UDP packet
289                     3        Reply via BIER packet

291       When Reply Mode is set to 1, the receiver will not send any reply.
292       This mode can be used for unidirectional path validation.  When
293       the Reply Mode is set to 2, the Responder Bit-Forwarding Router
294       (BFR) encapsulates the Echo reply payload with the IP/UDP header.

How does the responder choose whether to use IPv4 or IPv6 if is running
dual/stack?

443   Any Initiator MUST include this TLV in the Echo Request packet.

Is this only supposed to be present in the request and not in the response?
Please clarify.

481   the BFER responding to the Echo Request.  This TLV MUST be included
482   by Initiator in the BIER OAM packet if the Downstream Mapping TLV
483   (Section 3.3.4) is included.

Is this allowed in both request and response? i.e., if present in the
request, should the responder also copy it in the response?


609   This section defines the optional Sub-TLVs that can be included in
610   Downstream Mapping TLV.

612                   Sub-TLV Type    Value
613                   ------------  -------------
614                       1        Multipath Entropy Data
615                       2        Egress BitString

What is the handling for unknown/unrecognized sub-TLVs?

767   Upstream Address
768       As defined in Section 3.3.4

What is defined in 3.3.4 is very different. Please specify here again
even if the concept is similar for clarity.

780 4.1.  BIER OAM Processing

782   A BIER OAM packet MUST be sent to the BIER control plane for OAM
783   processing if one of the following conditions is true:

785   *  The receiving BFR is a BFER.

787   *  TTL of BIER-MPLS Label (Section 2.1.1.1 [RFC8296]) expired.

What about IPv6 or natively over Ethernet? If traceroute is not supported
or not specified for those data planes then perhaps this should be called
out in the abstract and introduction sections. This is related to discuss-7.

IPv6 is covered. I am still trying to understand (for my own learning) how
this works for natively over Ethernet.


1036 5.2.  BIER OAM Parameters

1038   IANA is requested to create and maintain the "BIER OAM Parameters"
1039   registry containing the sub-registries listed below.

Why would this not be placed under the existing BIER Parameters
registry-group?

[Ballot comment]
Hi Greg, all,

Thank you for the discussion. The changes made since -16 [1] address all the comments raised in my previous ballot [2].

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-bier-ping-16&url2=draft-ietf-bier-ping-18&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/bier/IOns9SiKtA8O6i15RZUwyNdqBIs/

[Ballot discuss]
(revised position)

** Section 5.4.1, 5.4.2 define an assignment policy for IETF Review and FCFS.  These three new registries also have “experimental” and “private use” ranges.  What’s the difference?  Under what circumstances would I use one instead of the other?

** Section 5.5 defines a range of code points that have an allocation policy of specification required which requires review and approval of an expert.  What guidance does the WG have for this review?

** "IANA Not OK" status, "Port expert doesn't support an assignment"

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-bier-ping-17
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Mankamana Prasad Mishra for the shepherd's short write-up including the WG consensus and the justification of the intended status, even if I am unsure whether the other areas check-lists have been checked.

Other thanks to Brian Haberman, the Internet directorate reviewer (at my request), thanks to Greg Mirsky for his reply:
https://datatracker.ietf.org/doc/review-ietf-bier-ping-16-intdir-telechat-haberman-2025-11-12/

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Missing IANA instructions for proto=5

There is no section in the IANA considerations to register 5 in https://www.iana.org/assignments/bier/bier.xhtml#bier-next-protocol-identifiers (early allocation was done but needs to be confirmed).

### Section 3.2

About RTF and `Any other value MAY be considered as a sanity check failure.`, please specify the obvious (?) that RTF must be zero when sending a ping. Why is it only a MAY and not a MUST ? I.e., how can the ping initiator process the message if it does not know how to decode the time ?

### Section 3.4.4.

It is unclear (at least to me) what is the 'egress interface' in `The value is the Maximum Transmission Unit (MTU) value of the egress interface` it is the interface used to send the reply ? Should it rather be the MTU of the interface where the request was received ?

Where are `IPv6 unnumbered` and `IPv4 unnumbered` defined ? Probably later and linked to DA & DIA, but let's be explicit. Also applies to section 3.4.7 and possibly others.

### Section 4.1

Unable to parse `The use of the Router Alert label to be deprecated as proposed in [RFC9570].`

[Ballot comment]

## COMMENTS (non-blocking)

### Abstract

s/This document describes the mechanism/This document *specifies* the mechanism/ as it is a proposed standard.

### OAM ?

I wonder whether ping/trace are full OAM... i.e., while ping & trace are part of OAM they are also missing big chunks of OAM. But, I will let my OPS AD colleagues to ballot on this point.

In the same vein, it is more a 'query' than a 'ping' and the 'trace' appears to be specified only for BIER over MPLS...

### Section 2.1

The whole section would benefit if references were added to all acronyms expansions.

### Section 3.1

s/The current value is 1/The value defined in this document is 1./

In `no data packet following the OAM payload. Value is one from the IANA registry "BIER Next Protocol Identifiers" [RFC8296].`, it is unclear whether 'OAM payload' is the same as 'OAM message' moreover add a reference to the IANA registry (i.e., https://www.iana.org/assignments/bier/bier.xhtml#bier-next-protocol-identifiers) rather than to the packet format RFC.

### Section 3.2

RFC 4443 uses 'identifier' so why using 'Sender's handle' in this document ? Same concept, but different names can only lead to confusion.

### Section 5.3

Suggest to add one or two values as 'experimental' or 'private use'.

### Section 6

Please add RFC 4443 (ICMPv6) as a reference for ICMP.

Port expert doesn't support an assignment: "Although I appreciate THAT this request is not using the existing UDP port assignment intended to avoid the need for additional ports, the response is not clear as to WHY a port assignment is needed here in addition. Further, the complete lack of security for this service also strongly warrants against assigning a port for this service. For both these reasons, I strongly recommend against proceeding here."

[Ballot comment]
Section 3.1, paragraph 8
>      OAM Message Length - a two-octet field that reflects the length of
>      the OAM message, including the header and the Messsage Type
>      Dependent Data.

A two-octet field is 16 bits. The diagram above seems to indicate it is 32 bits. What gives? Can we be consistent in specifying all fields in bits?

Section 3.1, paragraph 16
>      When Reply Mode is set to 1, the receiver will not send any reply.
>      This mode can be used for unidirectional path validation.  When
>      the Reply Mode is set to 2, the Responder Bit-Forwarding Router
>      (BFR) encapsulates the Echo reply payload with the IP/UDP header.
>      When the Initiator intends to validate the return BIER path, the
>      Reply Mode will be set to 3 so that the Responder BFR will
>      encapsulate the Echo Reply with the BIER header.

This might be a dumb question, but when Reply Mode is set to 1, and traffic flows only in one direction, how does one determine that the path is valid?

The IANA review of this document seems to not have concluded yet.

Check whether Expert Review is an appropriate registration policy here.

I also support Ketan's and Roman's DISCUSS.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

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.

Section 3.2, paragraph 2
> more than one BFER, the Return Code is set to "Invalid Multipath Info Request
>                                    ^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

[Ballot comment]
Thank you for expanding the acronyms used in this document. Please consider adding definitions and/or references for these terms.

Although Section 1 expands the OAM acronym, "BIER OAM" is not really given a clear definition prior to its use as the title of Section 3.

CONSIDER: This document describes "BIER OAM", a protocol that can be used to...

In Section 3.1, expand "Value is one from" a bit.

CONSIDER: If a data packet follows the OAM payload, this field identifies the type of the payload using a value from the "BIER Next Protocol Identifiers" registry defined in RFC8296.

However, I note that "0" is a Reserved value in that field. Is this used in other contexts? Would it make sense to define "0" as None in the registry rather than special-casing the value here?

Throughout, there are figures which contain information which isn't consistently present in the prose. See "IESG Statement on Clarifying the Use of BCP 14 Key Words"; while in these cases the keywords themselves aren't in the figure, the values required to implement them are. Some examples:

⦁ In Sections 3.2 and 3.3.4.1, the ASCII table is the only source of the numerical values for each state. Further, the table in 3.2 is misaligned. Here, consider using actual table structures rather than embedding the columns in a figure.
⦁ In Sections 3.3 and 3.3.x, the figures are the only indication of the length of multiple fields, including Type and Length. The prose describing these fields should include their length in bits/bytes.

Consider moving the expansion of the term TLVs from Section 3.3 to 3.1 in the "TLVs" field definition.

In Section 3.3.1, it states that this TLV carries two things, but it only has one field. If these two things are equivalent, please state that, e.g. "carries the set of BFERs that the Initiator included in the BIER header."

In multiple places, a list of possible values is given for a field that covers less than the full range of the bits allocated, but the handling of unknown values is undefined. For example, the Downstream Mapping TLV's Address Type field has 256 possible values but only four are defined. What do I do if I receive one of the others?

In that particular instance, since the length of subsequent fields depends on the interpretation of the Address Type value, it also means that any following fields in this TLV will be inaccessible.

In Section 4.3 and elsewhere, the MUST isn't needed for the values of Message Type and Return Code. Rather, if the values aren't set to these, the message isn't an Echo Request. It's sufficient to say that if the Initiator wishes to perform an Echo Request, it uses these values.

There are four instances of the term "sanity check" in the document. While this term isn't listed in the documents referenced by the IESG Statement on Inclusive Language, it is advised against by several other sources; see e.g. https://inclusivenaming.org/word-lists/tier-2/sanity-check/, https://www.acm.org/diversity-inclusion/words-matter. Unless this is an existing term of art defined in BIER RFCs, you might consider finding a different expression.

In Section 5.4.3, there appears to be a mix of left-justified and center-justified values in the table.

===NITS FOLLOW===
⦁ Abstract: "per- flow" => "per-flow"
⦁ 1: "BIER architecture that" => "the BIER architecture, which"
⦁ 3.3: "BIER OAM packet" => "a BIER OAM packet" or "BIER OAM packets"
⦁ 4.5: "Best- return-code" => "Best-return-code"

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I have a number of points that I would like to DISCUSS on this document that I am providing inline in the idnits o/p of v16 of this document.


177 3.  BIER OAM

179   BIER OAM is defined to stay within the BIER layer by directly
180   following the BIER header without mandating the need for an IP
181   header.  [RFC8296] defines a 4-bit field as "Proto" to identify the
182   payload following the BIER header.  When the payload is BIER OAM, the
183   "Proto" field will be set to 5 as defined in [RFC8296]

I do not find the specification for setting the other fields in the
BIER header for OAM packets besides the Proto field. I find something about the
Entropy field usage further and about the use of BFIR-id and BitString but it
was not clear to me. Perhaps some specification in this section that covers
how the BIER header fields are set for BIER OAM packets would help clarify
along with forward reference to the respective sections that describe their
usage in further details?

209       Message Type - a six-bit field that identifies OAM protocol.
210       Values defined in this document are as follows:

212                   Value      Description
213                   --------  ---------------
214                     1        Echo Request
215                     2        Echo Reply

The handling of unknown types is undefined in this base specification.
E.g., how are implementations expected to handle a new Type 3 message defined by
as future specification that it does not recognize? While I am raising the point
for the message types, it also applies to all levels of TLVs/sub-TLVs as well.
For some TLVs, when unrecognized are present, the operation has been specified
to error out and I wanted to confirm that was intended given that it restricts
extensions.

223       Reserved - a fourteen-bit field.  The value MUST be zeroed on
224       transmission and ignored on receipt.

4+6+6+14=30 - we still have 2 bits missing? I guess the reserved
field should be 16-bit? Also, the Figure 1 has this wrong and needs to be fixed.


261       QTF (Querier Timestamp Format) - a four-bit field.  When the field
262       is set to 2, the Timestamp Sent field is (in seconds and
263       microseconds, according to the Initiator's clock) in NTP format
264       [RFC5905].  When the value of the QTF field is 3, the Timestamp
265       Sent's format is the IEEE 1588-2008 (1588v2) Precision Time
266       Protocol (PTP) [IEEE.1588.2008] format.  Any other value MAY be
267       considered as a sanity check failure.

269       RTF (Responder Timestamp Format) - a four-bit field.  When the
270       field is set to 2, the Timestamp Received field is (in seconds and
271       microseconds, according to the Initiator's clock) in NTP format
272       [RFC5905].  When filed's value is 3, the format of the Timestamp
273       Received is as defined in IEEE 1588-2008 (1588v2) Precision Time
274       Protocol [IEEE.1588.2008].  Any other value MAY be considered as a
275       sanity check failure.

"sanity check failure" on these formats is unclear and the use of MAY is
confusing. If the intention is to allow for more formats, then please say so and
perhaps introduce an IANA registry. If not, just say anything else MUST be
discarded or something like that?


Regarding section 3.2. Is it possible that more than one error
code is applicable at the responder for a given echo request? If so, I assume
these are supposed to be an ordered set rules (called "steps" in section 4.4)
that need to be followed by an implementation in determining the Return Code?
Please check for redundancy between the text in this section and 4.4 - best to
specify in one place. I am guessing the purpose of the text in this section
was to describe those error codes, but the description includes normative
procedures - best to do so in one place like section 4.4? This still leaves
the part that what is needed in section 4.4 is ordering (with a numbered list?)
- this also allows for further specifications that introduce more TLVs or
verification checks to introduce their error codes/handling in an appropriate
position in the sequence by updating this specification.


558               Type    Addr. Type      DA Length    DIA Length
559               -------  ---------------  ----------  ----------
560                   1      IPv4 Numbered        4              4
561                   2      IPv4 Unnumbered      4              4
562                   3      IPv6 Numbered        16            16
563                   4      IPv6 Unnumbered      16            4

What is IPv6 Unnumbered? I am not familiar with that term. Could you
please provide a reference? Or, is this a reference to an interface that
only has IPv6 link-local address and no IPv6 global address?


737 3.3.7.  Upstream Interface TLV

739   The BFR replying to the request MUST include the Upstream Interface
740   TLV.  This TLV identifies the incoming interface and the BIER-MPLS
741   label in the incoming Echo Request.  This TLV has the following
742   format:

I don't see the BIER-MPLS label being carried in this TLV. Am I
missing something? Also, I see that the ping but more so the traceroute
procedures in this document work only for MPLS and not for other data planes.
Am I correct? If so, perhaps this needs to be called out in the abstract
and introduction?

770 3.4.  Multipath Entropy Data Encoding

772   The size of the Entropy field in the BIER header is 20 bits, as
773   defined in Section 2 of [RFC8296].  This encoding is the same as the
774   Multipath Type 9 encoding, defined in Section 3.4.1.1.1 of [RFC8029].

RFC8029 talks about MPLS and how the IP destination address for an
LSP Ping packet is encoded. I don't see how that applies to BIER Echo Request.
What is required is perhaps the entropy encoding but I don't follow how that
would work. Please clarify.


814 4.3.  Sending BIER Echo Request

816   The Initiator MUST set the Message Type as 1 and Return Code as 0.
817   The Proto field in the OAM packet MUST be set to 0.  The choice of

Does this precludes the use of any padding or such to increase the
size of the BIER OAM packet to debug issues with specific packet sizes? I don't
see a padding TLV and neither do I see the ability to carry some other payload.
Has this been discussed/considered by the WG?

1031 5.1.  UDP Port Number

1033   This document requests a UDP port TBD1 to be allocated by IANA for
1034   BIER Echo.

Should this not be BIER OAM in general and not just for a specific
message types?

Sec 3.1 indicates that request and reply are separate message
types with values 1 and 2? Besides sec 5.3 there is another registry in
sec 5.4 that is allocating the two message types? Am I missing something?
Perhaps you intended to allocate the type 5 for OAM Packet in the BIER
Next Protocol Identifiers registry in 5.3 and then in section 5.4 for the OAM
message types - echo request and echo response?

Sec 5.4.3 these reply modes have a bearing on normative processing
procedures of the protocol. As such, this split into FCFS and IETF Review sounds
problematic to me. What this means is that any private person can pick a code and
ship it and that can cause interop issues due to the nature of procedures. And in
general, I would like to discuss/understand the reason for such a split from the WG.

This is in general for all the IANA registries created and their
allocation rules. I would be interested in understanding the rationale for this
very complicated scheme with mix of various allocation policies and the WG
discussion around why this was necessary as opposed to a much simpler scheme
that is IETF Review + experimental/private use ?

[Ballot comment]
I would also like to share some comments inline in the idnits o/p of v16 of this document.

I support the DISCUSS from Roman and some of the DISCUSS points raised by Med.

15 Abstract

17   Bit Index Explicit Replication (BIER) is an architecture that
18   provides optimal multicast forwarding through a "BIER domain" without
19   requiring intermediate routers to maintain any multicast-related per-
20   flow state.  BIER also does not require any explicit tree-building
21   protocol for its operation.  A multicast data packet enters a BIER
22   domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
23   BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
24   The BFIR router adds a BIER header to the packet.  The BIER header
25   contains a bit-string in which each bit represents exactly one BFER
26   to forward the packet to.  The set of BFERs to which the multicast
27   packet needs to be forwarded is expressed by setting the bits that
28   correspond to those routers in the BIER header.

The above paragraph is about BIER itself and not what's specified in
this document. This seems odd in the abstract. Please condense to a single
sentence about BIER.

226       OAM Message Length - a two-octet field that reflects the length of
227       the OAM message, including the header and the Messsage Type
228       Dependent Data.

I assume length is in octets or bytes as clarified in sec 3.3? Please
clarify the same here as well.


285                   Value      Description
286                   --------  ---------------
287                     1        Do not Reply
288                     2        Reply via IPv4/IPv6 UDP packet
289                     3        Reply via BIER packet

291       When Reply Mode is set to 1, the receiver will not send any reply.
292       This mode can be used for unidirectional path validation.  When
293       the Reply Mode is set to 2, the Responder Bit-Forwarding Router
294       (BFR) encapsulates the Echo reply payload with the IP/UDP header.

How does the responder choose whether to use IPv4 or IPv6 if is running
dual/stack?

402   TLV Types are defined below; Length is the length of the Value field
403   in octets.  The Value field depends on the TLV Type.

Based on the text in sec 3.2 above, unknown or unsupported TLVs result
in an error response. It might be good to state that here as well as a
consideration for those looking to introduce new TLVs in the future.

443   Any Initiator MUST include this TLV in the Echo Request packet.

Is this only supposed to be present in the request and not in the response?
Please clarify.

481   the BFER responding to the Echo Request.  This TLV MUST be included
482   by Initiator in the BIER OAM packet if the Downstream Mapping TLV
483   (Section 3.3.4) is included.

Is this allowed in both request and response? i.e., if present in the
request, should the responder also copy it in the response?


553   Address Type  A one-octet field.  The Address Type indicates the
554       address type and length of the IP address for the downstream
555       interface.  The Address type is set to one of the following
556       values:

558               Type    Addr. Type      DA Length    DIA Length
559               -------  ---------------  ----------  ----------
560                   1      IPv4 Numbered        4              4
561                   2      IPv4 Unnumbered      4              4
562                   3      IPv6 Numbered        16            16
563                   4      IPv6 Unnumbered      16            4

Use of other values makes this TLV invalid?


595       If the Address Type is 2, the Downstream Address MUST be set to
596       IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address
597       is set to the index assigned by upstream BFR to the interface.

Why is this "upstream BFR"? It is the index assigned by the responder to
the downstream interface, right?

609   This section defines the optional Sub-TLVs that can be included in
610   Downstream Mapping TLV.

612                   Sub-TLV Type    Value
613                   ------------  -------------
614                       1        Multipath Entropy Data
615                       2        Egress BitString

What is the handling for unknown/unrecognized sub-TLVs?

767   Upstream Address
768       As defined in Section 3.3.4

What is defined in 3.3.4 is very different. Please specify here again
even if the concept is similar for clarity.

780 4.1.  BIER OAM Processing

782   A BIER OAM packet MUST be sent to the BIER control plane for OAM
783   processing if one of the following conditions is true:

785   *  The receiving BFR is a BFER.

787   *  TTL of BIER-MPLS Label (Section 2.1.1.1 [RFC8296]) expired.

What about IPv6 or natively over Ethernet? If traceroute is not supported
or not specified for those data planes then perhaps this should be called
out in the abstract and introduction sections. This is related to discuss-7.

807   The Initiator MUST include Multipath Entropy Data Sub-TLV in
808   Downstream Mapping TLV.  It MUST also include the BFER in BitString
809   TLV to which the Multipath query is performed.

I assume those MUSTs apply only to when doing Per BFER ECMP Discovery?
If so, please just suffix those sentences with that to avoid confusion.

860   Any BFR on receiving Echo Request MUST perform the basic sanity
861   check.  If the BFR cannot parse the OAM Dependent data payload

What is "OAM Dependent data payload"?


890   BFR will populate the Interface-I with the identifier of the
891   interface over which the Echo Request is received, the top label in
892   the MPLS stack of the received Echo Request to BIER-Label-L, and the
893   BIER header to BIER-Header.  If the received Echo Request carries

to BIER-Header or Header-H ?


904   This step allows the detection of a synchronization problem in the

s/This step/The above step ? ... same goes for other similar text in this
section.

1036 5.2.  BIER OAM Parameters

1038   IANA is requested to create and maintain the "BIER OAM Parameters"
1039   registry containing the sub-registries listed below.

Why would this not be placed under the existing BIER Parameters
registry-group?

1087       3 - 175 IETF Review

The assignment policy should also include initial allocations (here
1 and 2). This is a general comment.

For the authors:

Please see https://datatracker.ietf.org/doc/draft-ietf-intarea-multicast-application-port/

This document should be revised to address the potential use of that assigned port.

Additionally, it is not clear why this PING should not be using ICMP, e.g., with BIER headers.

Finally, this proposal lacks any security for this service (see RFC 7605), and as such, we strongly recommend against deploying it as a port-based service.

[Ballot discuss]
** Section 5.4.1, 5.4.2 define an assignment policy for IETF Review and FCFS.  These three new registries also have “experimental” and “private use” ranges.  What’s the difference?  Under what circumstances would I use one instead of the other?

** Section 5.5 defines a range of code points that have an allocation policy of specification required which requires review and approval of an expert.  What guidance does the WG have for this review?

[Ballot comment]
Thank you for this document.

I support the set of issues raised in the TSVART IETF Last Call review by Marcus Ihlar.  There was a partial email follow-up to this review in this thread with some suggested improvements, but no new I-D:
https://mailarchive.ietf.org/arch/msg/tsv-art/rRZlalC28-0Vu77TvBntZeSWisw.

Can a set of homogeneous formats be RECOMMENDED?

===

There seem to be a set of field values that are illegal in this version of the protocol, but the action if these values happens to be received is not explicitly indicated. I think it is important a rule is added to allow for future evolution, e.g.:

QIF: “…Any other value MAY be considered as a sanity check failure.” 
- Otherwise what protocolaction? - Ignore?

Section 3.2 :
“The Return Code can be one of the following:”
- What is the protocol action for a Return Code >10? (Ignore?)

RTF:
“…Any other value MAY be considered as a sanity check failure.”  Otherwise what? - Ignore?

How does a v1 receiver handle packets with a Ver > 1.
- are these ignored on receipt or do they generate an error?

(2) NiTs

NiT: RTF: “When filed's value” - perhaps “When the field’s value”
protocol

NiT: Return Code: “The value of the Return Code filed MUST” - is this “field”?

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

### S3.1

* The phase "in NTP format" is lacking some precision.

  Given that the size of the fields seem to be 64-bit, I assume you're
  referring to what RFC 5905 Section 6 calls "NTP Timestamp Format".

  If that's true, then the granularity of the fractional part is documented
  as being picoseconds, whereas this document suggests microseconds.

## Nits

### S3.1

* "When filed's value is 3" -> "the field's"

[Ballot discuss]
Hi Nagendra, Carlos, Mach, and Greg,

Thank you for the effort put into this well-written specification. Enjoyed reading the spec.

Also, thanks to Will (Shucheng Liu) for the OPSDIR review.

Please find below some points for DISCUSSion:

# Scope

## After reading the spec, it is not clear to me if the OAM packets can be scoped to diagnose only a subset of the distribution path, not form an ingress to egress. Can we please clarify that and record that scope early in the document.

## BTW, the doc says:

  The specification conforms to R-1 through R-4, and R-7 requirements
  listed in [I-D.ietf-bier-oam-requirements].

While OAM-req doc has the following:

  1.  The listed requirements MUST be supported with any routing
        underlay [RFC8279] over which the BIER layer can be realized.

  2.  It MUST be possible to initialize a BIER OAM session from any
        Bit-Forwarding Router (BFR) of the given BIER domain.

  3.  It SHOULD be possible to initialize a BIER OAM session from a
        centralized controller.

  4.  BIER OAM MUST support proactive and on-demand OAM monitoring and
        measurement methods.

### Compliance with R-1 is trivial.

### Compliance with R-2 would benefit from some elaboration as I interpret some text there is a BFIR involved such as in:

  The source IP address is any local address of the responder, and
  the destination IP address is derived from the BFIR-id of the BIER header
  [RFC8296] of the received Echo Request.

### I wonder whether we can say how proactive mode is relevant here?

### I don’t see any discussion in the spec how R-7 is covered.

# Conflict between narrative text and figure

CURRENT:
      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Ver  | Message Type  |  Proto  |        Reserved          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        OAM Message Length                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                  Message Type Dependent Data                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1: BIER OAM Header

      …

      Message Type - a six-bit field that identifies OAM protocol.
      Values defined in this document are as follows:

Which one is correct? 6- or 8-bit?

# The registry is authoritative for the values

CURRENT:
      This field MUST be set to 0 if
      there is no data packet following the OAM payload.  Value is one
      from the IANA registry "BIER Next Protocol Identifiers" [RFC8296].

The authoritative reference should be the registry not the initial values in 8296. Please fix that.

# Behavior when in transit

The spec focuses on sender/receiver behavior while there are BIER elements in-between. Please consider adding some text to indicates fields that must not be modified in transit.

# Timestamps

## Timestamp Units

The spec seems to assume that the unit of the fraction part is microseconds, while the recommended unit for 64-bit timestamp in RFC8877 is picoseconds. Is there any reason what the recommended format in 8877 is not used here?

Please note that RFC8877 recommend the use of a template of a non recommended format is used.

## Figure 2 can be interpreted as if both sent/received TS are present even in a request. I don’ think this intended. Can we please clarify the intent?

## The use of initiator is confusing here? is it the sender of the request? the source of a reply?

CURRENT:
      When the
      field is set to 2, the Timestamp Received field is (in seconds and
      microseconds, according to the Initiator's clock) in NTP format
      [RFC5905]. 

## What is the need for the following? In which case distinct format will be needed?

  The sender of the BIER Echo Request might receive the BIER Echo Reply
  with RTF different from the Sender's QTF, Thus, the Sender MUST be
  able to interpret both timestamp formats, i.e., NTP [RFC5905] and PTP
  [IEEE.1588.2008].

Absent justification, this seems about adding complexity to the spec. 

## Guards against reply

Should timestamp sent be used to discard requests that are too late? This can be a guard against reply attacks, for example.

# Correlate a reply with a response for malformed messages

CURRENT:
  "Malformed Echo Request received" will be used by any BFR if the
  received Echo Request packet is not properly formatted.

What value will be included in handle/Sequence number if the request is malformed/can’t be parsed? I guess sending the error message makes some assumptions on the nature of malformed message. Please call these out.

# Help identify unsupported TLVs

CURRENT:
  When a receiver does not support any TLV included in the Echo
  Request, the Return code will be set to "One or more of the TLVs is
  not supported" carrying the respective TLVs.

This error message along is not helpful to place future requests. Can the reply also mirror the unsupported TLVs?

# Vague MUST on OAM Packet

CURRENT:
4.1.  BIER OAM Processing

  A BIER OAM packet MUST be sent to the BIER control plane for OAM
  processing if one of the following conditions is true:

I don’t understand what is the purpose of this. Send an OAM packet is vague, at the least.

# Rate-limit and effect of other policy in place

CURRENT:
  Any transit BFR will reply with Bit-masked Entropy for each
  downstream path as defined in [RFC8029]

Or

  If the BFR cannot parse the OAM Dependent data payload
  completely because the value in the OAM Message Length field is
  incorrect, BFR MUST send Echo Reply with Return Code set to
  "Malformed Echo Request received" if the OAM Message Length is
  incorrect. 

Will these reply systematically/blindly? Wouldn’t we expect some rate-limiting and control of leaking the information outside a domain?

Please check these statements and similar ones and formulate to take into account the policy.

[Ballot comment]
# Generic: Having a state diagram would really be appreciate to go through all the state of return code.

# Please expand BIER in the title.

# The first para of the abstract is a copy/paste from the base BIER spec. Not sure that is useful to describe this extension, especially that the same content is also mirrored in the introduction.

# OAM Field (Section 3)

In addition to Proto discussion to identify a OAM packet, I wonder whether the “OAM” field from the base spec (rfc8296#section-4) can be reminded here (including indicating whether no change of meaning is made here):

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              BIFT-id                  | TC  |S|    TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Nibble |  Ver  |  BSL  |              Entropy                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |OAM|Rsv|    DSCP  |  Proto  |            BFIR-id            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

# Version Registry

CURRENT:
      Ver - a four-bit field that indicates the current version of the
      BIER OAM header.  The current value is 1.  …

Shouldn’t the version be maintained in an IANA registry?

As I’m there, please consider this change.

NEW:
      Ver - a four-bit field that indicates the version of the
      BIER OAM header.  The current value is 1.  …

# nit in Section 3

OLD: The Echo Request/Reply header format displayed in Figure 2

NEW: The Echo Request/Reply header format is displayed in Figure 2.

# Add a pointer where “multipath info” is defined

CURRENT:
  When the Echo Request is received with multipath info for more than
  one BFER, the Return Code is set to "Invalid Multipath Info Request".

# (nit) Section 3.3

OLD: 3.3.  BIER OAM TLV

NEW: 3.3.  BIER OAM TLVs

# (nit) Sub-domain ID 

Consider using sub-domain-id to be consistent with RFC8296.

# (3.3.1) Redundant behavior?

CURRENT:
  This
  TLV MUST be included by the Initiator in the Echo Request packet.

  Any Initiator MUST include this TLV in the Echo Request packet.

Unless I missed something too subtle, I guess this can cleaned to keep only one mention.

# (3.3.4) nits

OLD:
      IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address
      ..

      IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address
      ..

      IPV6 BFR-Prefix of downstream BFR and Downstream Interface Address

NEW:
      IPv4 BFR-Prefix of downstream BFR and Downstream Interface Address
      ..

      IPv4 BFR-Prefix of downstream BFR and Downstream Interface Address
      ..

      IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address


# Sanity Checks

CURRENT:
  Any BFR on receiving Echo Request MUST perform the basic sanity
  check. 

Not requesting to be exhaustive, but I would elaborate those.

# Best-return-code variable

CURRENT:
  BFR MUST initialize the Best-return-code variable to the null value.
 
This variable comes from no where when reading the document :-)

Please introduce the variable first and its role.

# (4.5) mysterious IP :-)

## I guess the following:

CURRENT:
  The source IP is any local address of the responder, and
  the destination IP is derived from the BFIR-id of the BIER header
  [RFC8296] of the received Echo Request.

Should be changed to

NEW:
  The source IP address is any local address of the responder, and
  the destination IP address is derived from the BFIR-id of the BIER header
  [RFC8296] of the received Echo Request.

## Also, shouldn’t this be a non-link-local @?

# 4.6.  Receiving Echo Reply

## There is no mention how sequence number is used.

## How long a state (handle) is maintained? Any guidance to provide here?

Cheers,
Med

IESG/Authors/WG Chairs:

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

IANA has a question about several of the actions requested in the IANA Considerations section of this document.

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

First, the authors request a port assignment, for UDP only, for BIER Echo.

An expert review will be requested for the port number. The IANA state for the document review will be set to "IANA NOT OK" until the port review is completed and approved.

Second, a new registry group will be created on the IANA Matrix located at:

https://www.iana.org/protocols

The new registry group will be titled BIER OAN Parameters and have [ RFC-to-be ] as its reference.

Third, in the new registry group created in action two, above, a new registry will be created called BIER OAN Message Types. The reference for the new registry will be [ RFC-to-be ]. The registration policy for the new registry [RFC8126] will be:

0 - Reserved
1-31 - IETF Review
32-62 - First Come, First Served
63 - Reserved

There are initial registrations in the new registry as follows:

Value Description Reference
-----+-----------+-----------
0 Reserved [ RFC-to-be ]
1 BIER Echo Request/Echo Reply [ RFC-to-be ]
2-31 Unassigned
32-62 Unassigned
63 Reserved [ RFC-to-be ]

Fourth, in the new registry group created in action two, above, a new registry will be created called BIER Echo Request/Echo Reply Message Types. The reference for the new registry will be [ RFC-to-be ]. The registration policy for the new registry [RFC8126] will be:

0 - Reserved
1-175 - IETF Review
176-239 - First Come, First Served
240-251 - Experimental
252-254 - Private Use
255 - Reserved

IANA Question --> The assignment policy for this newly created registry has a mismatch between the text in Section 5.4.1 and Table 2. It appears that the text in table 2 is definitive. Is this correct? The text in Section 5.4.1 should be updated to include an accurate description of the registration policy for the new registry.

There are initial registrations in the new registry as follows:

Value Description Reference
-----+-----------+-----------
0 Reserved [ RFC-to-be ]
1 BIER Echo Request [ RFC-to-be ]
2 BIER Echo Reply [ RFC-to-be ]
3 - 175 Unassigned
176 - 239 Unassigned
240 - 251 Experimental
252 - 254 Private Use
255 Reserved [ RFC-to-be ]

Fifth, in the new registry group created in action two, above, a new registry will be created called BIER Echo Reply Mode. The reference for the new registry will be [ RFC-to-be ]. The registration policy for the new registry [RFC8126] will be:

0 - Reserved
1-175 - IETF Review
176-239 - First Come, First Served
240-251 - Experimental
252-254 - Private Use
255 - Reserved

IANA Question --> The assignment policy for this newly created registry has a mismatch between the text in Section 5.4.2 and Table 3. It appears that the text in table 3 is definitive. Is this correct? The text in Section 5.4.2 should be updated to include an accurate description of the registration policy for the new registry.

There are initial registrations in the new registry as follows:

Value Description Reference
-----+-----------+-----------
0 Reserved [ RFC-to-be ]
1 Do Not Reply [ RFC-to-be ]
2 Reply via an IPv4/IPv6 UDP Packet [ RFC-to-be ]
3 Reply via BIER packet [ RFC-to-be ]
4-175 Unassigned
176-239 Unassigned
240-251 Experimental
252-254 Private Use
255 Reserved [ RFC-to-be ]

Sixth, in the new registry group created in action two, above, a new registry will be created called BIER Echo Return Codes. The reference for the new registry will be [ RFC-to-be ]. The registration policy for the new registry [RFC8126] will be:

0 - Reserved
1-251 - IETF Review
252-254 - Private Use
255 - Reserved

IANA Question --> The assignment policy for this newly created registry has a significant difference between the text in Section 5.4.3 and Table 4. It appears that the text in Table 4 is definitive. Is this correct? The text in Section 5.4.3 should be updated to include an accurate description of the registration policy for the new registry.

There are initial registrations in the new registry as follows:

Value Description Reference
-----+-----------+-----------
0 No Return Code [ RFC-to-be ]
1 Malformed Echo Request received [ RFC-to-be ]
2 One or more of the TLVs is not supported [ RFC-to-be ]
3 Replying BFR is the only BFER in header BitString [ RFC-to-be ]
4 Replying BFR is one of the BFERs in header BitString [ RFC-to-be ]
5 Packet-Forward-Success [ RFC-to-be ]
6 Invalid Multipath Info Request [ RFC-to-be ]
7 Unassigned [ RFC-to-be ]
8 No matching entry in the forwarding table [ RFC-to-be ]
9 Set-Identifier Mismatch [ RFC-to-be ]
10 DDMAP Mismatch [ RFC-to-be ]
11 - 191 Unassigned
192-251 Unassigned
252-254 Private Use
255 Reserved [ RFC-to-be ]

Seventh, in the new registry group created in action two, above, a new registry will be created called TLVs.

IANA Question --> Could there be a more descriptive title for this new registry?

The reference for the new registry will be [ RFC-to-be ]. The valid range for TLVs and sub-TLVs is 0-65535. The registration policy for the new registry [RFC8126] will be:

0-16383 - Standards Action
16384-31743 - Specification Required
31744-32767 - Private Use
32768-49161 - Standards Action
49162-64511 - Specification Required
64512-65535 - Private Use

There are initial registrations in the new registry as follows:

Type Sub-Type Value Field Reference
-----+---------+----------+----------
1 Original SI-BitString [ RFC-to-be ]
2 Target SI-BitString [ RFC-to-be ]
3 Incoming SI-BitString [ RFC-to-be ]
4 Downstream Mapping [ RFC-to-be ]
4 1 Multipath Entropy Data [ RFC-to-be ]
4 2 Egress BitString [ RFC-to-be ]
5 Responder BFER [ RFC-to-be ]
6 Responder BFR [ RFC-to-be ]
7 Upstream Interface [ RFC-to-be ]

IANA Question --> Is TLV Type 0 reserved?

We understand that these are the only actions required to be completed upon approval of this document.

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

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 2025-10-17):

From: The IESG
To: IETF-Announce
CC: bier-chairs@ietf.org, bier@ietf.org, draft-ietf-bier-ping@ietf.org, gunter@vandevelde.cc, mankamana mishra , mankamis@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BIER Ping and Trace) to Proposed Standard


The IESG has received a request from the Bit Indexed Explicit Replication WG
(bier) to consider the following document: - 'BIER Ping and Trace'
  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 2025-10-17. 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


  Bit Index Explicit Replication (BIER) is an architecture that
  provides optimal multicast forwarding through a "BIER domain" without
  requiring intermediate routers to maintain any multicast-related per-
  flow state.  BIER also does not require any explicit tree-building
  protocol for its operation.  A multicast data packet enters a BIER
  domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
  BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
  The BFIR router adds a BIER header to the packet.  The BIER header
  contains a bit-string in which each bit represents exactly one BFER
  to forward the packet to.  The set of BFERs to which the multicast
  packet needs to be forwarded is expressed by setting the bits that
  correspond to those routers in the BIER header.

  This document describes the mechanism and basic BIER OAM packet
  format that can be used to perform failure detection and isolation on
  the BIER data plane.




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


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

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

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?

  It did reach to broad agreement. There was good participation from different members of working group.

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

  No, there were 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)?

  Yes, some part of it has been implemented by vendors who support BIER in some form.

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

  NA

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, this document is needed as it describes the basic functionality of the protocol. The document has been written clearly and is ready to move forward.

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?

    NA

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?

    Intended Standards Track is the proper type considering it defines a new extension to protocol.

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, IPR disclosure checks were done.


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.

Author list has been updated

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

    Ready without nits.

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?

    NA

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

    IANA section does clearly capture the appropriate information.

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

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?

  It did reach to broad agreement. There was good participation from different members of working group.

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

  No, there were 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)?

  Yes, some part of it has been implemented by vendors who support BIER in some form.

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

  NA

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, this document is needed as it describes the basic functionality of the protocol. The document has been written clearly and is ready to move forward.

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?

    NA

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?

    Intended Standards Track is the proper type considering it defines a new extension to protocol.

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, IPR disclosure checks were done.


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.

Author list has been updated

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

    Ready without nits.

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?

    NA

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

    IANA section does clearly capture the appropriate information.

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

Request for posting confirmation emailed to previous authors: Carlos Pignataro , Greg Mirsky , Lianshu Zheng , Mach Chen , Nagendra Nainar , Nobo Akiya , bier-chairs@ietf.org

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?

  It did reach to broad agreement. There was good participation from different members of working group.

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

  No, there were 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)?

  Yes, some part of it has been implemented by vendors who support BIER in some form.

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

  NA

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, this document is needed as it describes the basic functionality for protocol. Document has been written clearly and ready to move forward.

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?

    NA

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?

    Intended Standards Track and it is proper type considering it defines new extension to protocol.

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 , IPR disclosure check were done.


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.

    Yes, there are more than 5 authors. Chairs need to take call about it .

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

    Ready without nits.

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?

    NA

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

    IANA section does clearly capture the appropriate information.

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

Request for posting confirmation emailed to previous authors: Carlos Pignataro , Greg Mirsky , Lianshu Zheng , Mach Chen , Nagendra Nainar , Nobo Akiya , bier-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Nagendra Kumar , Carlos Pignataro , Nobo Akiya , Gregory Mirsky , Mach Chen , Lianshu Zheng , bier-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Mach Chen" , "Lianshu Zheng" , "Nagendra Kumar" , "Carlos Pignataro" , "Nobo Akiya" , "Gregory Mirsky" , bier-chairs@ietf.org