Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multi-Point MPLS Label Switched Path (LSP)
draft-ietf-mpls-p2mp-bfd-11

Thanks for addressing my previous DISCUSS by requesting an IPv6 Dummy prefix to the IANA. For archiving the DISCUSS was:
https://mailarchive.ietf.org/arch/msg/mpls/6sLqVwgLk8lUF0W1Imjk7OuHSQM/

Nevertheless some non-blocking COMMENTS to be addressed now or before AUTH48.

## NEW COMMENTS (non-blocking)

### Section 1

There is a repetition in `Hence, IANA is requested to allocate TBA2/64 range as a new Dummy IPv6 Prefix range *TBA2/64* (Section 7.1) ` ;-)

### Section 3.1

No need to refer to RFC when writing the IPv6 address in canonical format in `0:0:0:0:0:ffff:7f00/104 range *(see Section 5 of [RFC5952])*.`

### Somewhere

It would be nice to mention that the use of a source-only IPv6 dummy address as the destination is on purpose to generate an exception and a return message.





## OLD COMMENTS (non-blocking)


### Abstract and Section 1

s/recommends the use of *an* IPv6 loopback address/recommends the use of *the* IPv6 loopback address/

### Section 2.1

Suggest adding a reference (or a definition) of `G-ACh`.

### Section 3.1

Please use section 5 of RFC 5952 for `0:0:0:0:0:FFFF:7F00/104`.

### Section 3.2

In figure 1, some fields have a length that is specified and others have no length... Is it on purpose ?

Even if the reader could guess, what are the expected sender/receiver behavior for the reserved fields ?


## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

Thanks for addressing my DISCUSS observation.

I do still support the DISCUSS from Eric

Thanks for addressing my DISCUSS and COMMENT.

Thank you to Meral Shirazipour for the GENART review.

# Internet AD comments for draft-ietf-mpls-p2mp-bfd-09
CC @ekline

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

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

## Comments

### S1

* I'm in the camp of folks who consider it a bit of an abomination that
  nodes are sending packets with ::1 in any of the address fields (however
  many layers of encapsulation there are on the wire) outside of the local
  node.

  That said, I'm well aware that this has been a practice for BFD/OAM/...
  purposes (I raised this concern on MPLS LSP Ping document a while ago).

  I propose we consider a very short document in 6MAN/IPPM/wherever that:

    * requests allocation of an IPv6 Special-Purpose address

    * the intended usage would be for it to be assigned to any loopback
      interface on nodes wishing to do these kinds of stuff control plane
      monitoring or measuring traffic

    * we can ask for ::2/128; failing that, ::/8 is vast and I'm sure we
      could find something suitable.

### S3.1

* I'm afraid I have to disagree with my INT AD colleague: 0:0:0:0:0:FFFF:7F00
  is perfectly okay to be written ::ffff:127.0.0.0.  In fact, RFC 5952
  Section 5 RECOMMENDs mixed notation where it's important to convey that
  there is an embedded IPv4 address.

  Over and above that, RFC 5952 Section 4.3 is pretty clear about MUST use
  lowercase ("f" and not "F").

  Super in-the-weeds, I know.

Thanks for this document, which I found straightforward to review with one exception, noted below.

(Sorry, I missed pasting my final point. Reissuing my ballot to correct.)

### Section 1, unicast?

   [RFC8562] defines a method of using Bidirectional Detection (BFD)
   [RFC5880] to monitor and detect unicast failures between the sender
   (head) and one or more receivers (tails) in multipoint or multicast
   networks.

I don't understand the use of the word "unicast" here. Looking at RFC 8562, it doesn't say anything about unicast (the string only occurs once there, in describing the base BFD). Would it be correct to delete "unicast", or change it to "data plane"?

### Section 3.2, too terse

I found this description to be almost DISCUSS-level terse; it seriously impaired my ability to understand what is otherwise a clear document. 

A straightforward way to fix this would be to follow the usual convention of explaining every field, even if it's by reference. Looking at RFC 7212 Section 3, for instance, the authors are much more generous in the level of detail supplied -- there's a clear overview of the message structure, followed by field-level descriptions. 

But if that's seen as too verbose, another approach might be to at least annotate your diagram to indicate that the first three rows are per RFC 5586, the fourth row is per RFC 5880, and the final three rows are per RFC 7212. 

Another small fix might be to break up and restructure the big paragraph, which mixes justification (which the WG discussions might have needed but future implementors probably won't care about) with specification. Something like this:

NEW:
   In some environments, the overhead of extra IP/UDP encapsulations may
   be considered burdensome, making the use of more compact G-ACh
   encapsulation attractive.  Also, the validation of the IP/UDP
   encapsulation of a BFD Control packet in a p2mp BFD session may fail
   because of a problem related to neither the MPLS label stack nor to
   BFD.  Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP
   improves the accuracy of the correlation of the detected failure and
   defect in MPLS LSP.  
   
   If a BFD Control
   packet in PW-ACH encapsulation (without IP/UDP Headers) is to be used
   in ACH, an implementation would not be able to verify the identity of
   the MultipointHead and, as a result, will not properly demultiplex
   BFD packets.  Hence, a new channel type value is needed.  
   
^^^ all that is justification, just reordered from what you had. You might even consider making it a different subsection so that implementors can more easily skim over it. That lets the meat of the section stand alone without distraction:

   Non-IP encapsulation for multipoint BFD over
   p2mp MPLS LSP (shown in Figure 1) MUST use Generic Associated Channel
   (G-ACh) Label (GAL) (see [RFC5586]) at the bottom of the label stack
   followed by an Associated Channel Header (ACH).  The Channel
   Type field in ACH MUST be set to Multipoint BFD Session (TBA1) value
   (Section 7).  To provide the identity of the MultipointHead for the
   particular multipoint BFD session, a Source Address TLV, as defined
   in Section 4.1 [RFC7212], MUST immediately follow a BFD Control
   message.  The use of other TLVs defined in Section 4 of [RFC7212] is
   outside the scope of this document.

^^^ by the way, I guess other TLVs defined anywhere else are also outside the scope, so IMO it would be better to say,

   The use of other TLVs is outside the scope of this document.
   
### Section 4.2, BGP-BFD

   The BGP-BFD Attribute [RFC9026] MAY be used to bootstrap multipoint 
   BFD session on a tail.

There's no such attribute. I guess you meant the (BGP) BFD Discriminator Attribute. (There's also a minor grammar error, should be "a multipoint BFD session".)

While we're talking about it, two other things --

- I guess you made the reference to RFC 9026 informative and not normative because this is an optional function? I think it's still normative because to implement this optional function the reader MUST read and understand RFC 9026. (An example of a truly informative reference would be something like "other means of bootstrapping multipoint BFD sessions, such as RFC 9026, are beyond the scope of this document.")

- Since RFC 9026's scope is wider than just bootstrapping multipoint BFD sessions, I think it would be desirable to reference the relevant section. I think all the necessary procedure is in Section 3.1.6, is that right? If so, then perhaps something like,

NEW:
   The BFD Discriminator Attribute MAY be used to bootstrap a multipoint 
   BFD session on a tail, following the format and procedures given in
   Section 3.1.6 of [RFC9026].

### Section 5, of?

   [RFC8562] defined how the BFD Demand mode can be used in multipoint
   networks.  When applied in MPLS, procedures specified in [RFC8562]
   allow an egress LSR to detect a failure of the part of the MPLS p2mp
   LSP from the ingress LSR.  
   
What other part of the LSP is there, other than the part from the ingress LSR? Are you trying to say that the egress LSR doesn't detect failures on other branches (that don't include the egress LSR)? If so I think the sentence would be clearer if you added "... to that egress LSR" to the end. (Or you could just end the sentence after the word "failure", I think it would be clear enough in context and the sentence is non-normative.)

Question #11 of the shepherd writeup doesn't explain why the selected status is the right one.

I support Eric's DISCUSS position.

Note the document uses ":::1/128" in two places instead of "::1/128".

Thank you for this document - I found it interesting. Also, a good catch by Eric Vyncke on the ::1/128 issue - I completely missed that!

Also much thanks to Bo Wu for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-mpls-p2mp-bfd-08-opsdir-lc-wu-2025-01-02/) -- as Loa said in their response "Nice review.". Also thank to the authors for addressing the comments quickly and comprehensively.

Supporting Eric's discuss.