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

I support Ketan's DISCUSS on the unknown behavior for undefined types and Roman's DISCUSS on the IANA registry.

Many thanks to David Mandelberg for their multiple secdir reviews.

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/

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

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/


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

<discuss-10> Should this not be BIER OAM in general and not just for a specific
message types?


<discuss-13> 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 ?

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

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.

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"

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/

Thank you to Roni Even for the GENART review

Thanks for addressing my DISUCSS feedback.

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

I support Ketan's discusses - at least the ones I fully understand :)