Skip to main content

Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)
draft-ietf-mpls-bfd-directed-31

Note: This ballot was opened for revision 30 and is now closed.

Jim Guichard
Yes
Deb Cooley
No Objection
Erik Kline
No Objection
John Scudder
No Objection
Comment (2024-05-01 for -30) Sent
Thanks for this document. I have several comments I hope may be helpful to you. 

### Section 2, unambiguously interpreted

   *  detection by an ingress node of a failure on the reverse path may
      not be unambiguously interpreted as the failure of the path in the
      forward direction.

I think I get what you're trying to say here, but even if the forward and reverse paths are co-routed, it's not completely guaranteed that the failure of one implies a failure of the other in any case. So I think it might be worth rephrasing.

### Section 3, Section 3.1, zero sub-TLVs

In several places, you make the point that the BFD reverse path TLV can have zero ("none") sub-TLVs included. I don't understand what the use case for zero sub-TLV's is, especially in light of

                                                                     If
   no sub-TLVs are found in the BFD Reverse Path TLV, the egress BFD
   peer MUST revert to using the local policy-based decision as
   described in Section 7 of [RFC5884], i.e., routed over IP network.

Isn't that semantically the same as saying, if there aren't any sub-TLVs, the reverse path TLV must be ignored? Which is... also what you'd say if the TLV were invalid.

This oddity is harmless as far as I can tell, which is why this isn't a DISCUSS point, but I'd still like to understand the reason.

### Section 3.1, syntax tortured past the breaking point

                                                                Only
   non-multicast  Target FEC Stack- sub-TLVs (already defined, or to be
   defined in the future) for  TLV Types 1, 16, and 21 of MPLS LSP Ping
   Parameters registry MUST be used  in this field.
   
RFC 2119 is often nice, but in my opinion, it's actively harmful in this case. The most obvious English-language reading I can see of this sentence is that the listed sub-TLV types have to be used, implying that other sub-TLV types may be used, although they aren't mandatory. I'm sure that's not what you mean. 

A potential rewrite might be something like, 

NEW:
   Only non-multicast Target FEC Stack sub-TLVs (already defined, or to be
   defined in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping
   Parameters registry are permitted to be used in this field. Any other
   sub-TLV MUST NOT be used.
   
See how I even got you a replacement RFC 2119 keyword there? ;-)

### Section 3.1, redundant prohibition

Continuing to the next sentence,

                                                 Multicast Target
   FEC Stack sub-TLVs, i.e., p2mp and mp2mp, MUST NOT be included in
   Reverse Path field.  
   
What's the point of including the sentence at all? The previous sentence already told me (or tried to tell me!) this information. My first inclination would be to just remove this sentence, although if you have some special reason for wanting to emphasize this point, I would suggest rewriting it something like,

NEW:
   (This implies that Multicast Target FEC Stack sub-TLVs, i.e., p2mp 
   and mp2mp, are not permitted in the Reverse Path field.)

The point of the rewrite is to avoid stating the same requirement twice, which I think leads to confusion. If it's just a consequence of the previous requirement, say it that way.

### Section 3.1, use a SHOULD

You SHOULD mark your calendar, I am about to suggest changing a MUST to a SHOULD. This almost never happens!

   If the egress peer LSR cannot find the path specified in the Reverse
   Path TLV it MUST send Echo Reply with the received BFD Discriminator
   TLV, Reverse Path TLV and set the Return Code to "Failed to establish
   the BFD session.  The specified reverse path was not found"
   (Section 3.2).  An implementation MAY provide configuration options
   to define action at the egress BFD peer.  For example, optionally, if
   the egress peer LSR cannot find the path specified in the Reverse
   Path TLV, it will establish the BFD session over an IP network, as
   defined in [RFC5884].
   
The MUST in the first sentence isn't really a MUST, because the second sentence gives an exception with the MAY. The most straightforward fix would be to change the MUST to a SHOULD. Alternatively, you could add some words to make it clear that the MAY is an exception to the preceding sentence, something like either,

NEW:
   If the egress peer LSR cannot find the path specified in the Reverse
   Path TLV it MUST send Echo Reply with the received BFD Discriminator
   TLV, Reverse Path TLV and set the Return Code to "Failed to establish
   the BFD session.  The specified reverse path was not found" 
   (Section 3.2),
   unless this behavior is overridden by configuration.  
   An implementation MAY provide configuration options
   to define action at the egress BFD peer.  For example, optionally, if
   the egress peer LSR cannot find the path specified in the Reverse
   Path TLV, it will establish the BFD session over an IP network, as
   defined in [RFC5884].
   
Or,

NEW:
   If the egress peer LSR cannot find the path specified in the Reverse
   Path TLV it MUST send Echo Reply with the received BFD Discriminator
   TLV, Reverse Path TLV and set the Return Code to "Failed to establish
   the BFD session.  The specified reverse path was not found" 
   (Section 3.2).
   As an exception to the preceding requirement,
   an implementation MAY provide configuration options
   to define action at the egress BFD peer.  For example, optionally, if
   the egress peer LSR cannot find the path specified in the Reverse
   Path TLV, it will establish the BFD session over an IP network, as
   defined in [RFC5884].
   
### Section 4, use cases don't need RFC 2119

A use case by definition, isn't where we specify protocol, so I don't think it makes sense to use RFC 2119 keywords there. However, given that you've used them, isn't the MAY wrong in the following text?

   references H-G-D-C-B-A tunnel.  To bootstrap a BFD session to monitor
   the second tunnel, ingress LSR peer A, MUST include a BFD
   Discriminator TLV with a different Discriminator value (e.g., foobar-
   2) [RFC7726] and MAY include a BFD Reverse Path TLV that references
   H-G-F-E-B-A tunnel.

According to the definitions given in RFC 2119, the MAY means that it's perfectly fine for the ingress LSR to omit the BFD reverse path TLV. How would the use case be satisfied if the TLV were omitted?

I think you should rewrite this section without the use of RFC 2119 keywords, and it would improve readability and clarity.

### Section 5, inappropriate MUST

I can't imagine how could be considered appropriate for you to mandate the following:

   Suppose an operator planned network maintenance activity that
   possibly affects FEC used in the BFD Reverse Path TLV.  In that case,
   the operator MUST avoid the unnecessary disruption using the LSP Ping
   with a new FEC in the BFD Reverse Path TLV.

I think maybe what you mean is something like,

NEW:
   Suppose an operator planned network maintenance activity that
   possibly affects FEC used in the BFD Reverse Path TLV.  In that case,
   the operator can avoid the unnecessary disruption by using the LSP Ping
   with a new FEC in the BFD Reverse Path TLV.
   
Carrot, not stick. The stick is doubly futile considering that we have no protocol police, RFC 8962 notwithstanding.
   
### Section 5, some of these things aren't operational considerations

The second part of that paragraph slides right out of operational considerations and into protocol specification:

                                                         In such a case,
   the ingress BFD peer SHOULD immediately transmit the LSP Ping Echo
   request with Return Path TLV to verify whether the FEC is still
   valid.  If the failure was caused by the change in the FEC used for
   the reverse direction of the BFD session, the ingress BFD peer SHOULD
   bootstrap a new BFD session using another FEC in BFD Reverse Path
   TLV.

Although RFC 5706 isn't prescriptive about how an operational consideration section has to be written or what it can contain, nonetheless this kind of protocol specification material seems out of place. I don't immediately see another section it should move to, but I think it would be cleaner to introduce another small section for this material instead of sneaking it into a section that should be about, well, operational considerations and not protocol implementation.

### Section 6.2, not SA

   The IANA is requested to assign new Return Code values from the
   192-247 range of the "Multi-Protocol Label Switching (MPLS) Label
   Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-
   registry, as follows using a Standards Action value.

Delete "using a Standards Action value". (Or delete 192-247 which is the RFC Required range, not the SA range, but that would be wrong because the status is Experimental.)
Mahesh Jethanandani
No Objection
Comment (2024-04-29 for -30) Sent
Section 3.1, paragraph 9
>    The BFD Reverse Path TLV MAY be used in the bootstrapping of a BFD
>    session process described in Section 6 of [RFC5884].  A system that
>    supports this specification MUST support using the BFD Reverse Path
>    TLV after the BFD session has been established.  If a system that
>    supports this specification receives an LSP Ping with the BFD
>    Discriminator TLV and no BFD Reverse Path TLV even though the reverse
>    path for the specified BFD session has been established according to
>    the previously received BFD Reverse Path TLV, the egress BFD peer
>    MUST transition to transmitting periodic BFD Control messages as
>    defined in Section 7 of [RFC5884].

What happens if the peer does not support this specification, but receives a BFD Reverse Path TLV? Does the request get silently dropped? If so, it should be stated in this document.

Section 5, paragraph 3

The document refers to a configuration option that in addition to other options defines the action an egress BFD peer should do to specify the action the peer can take if the LSR cannot find a path. How can this option be configured? Is there a YANG model extension planned to enable this capability?
Murray Kucherawy
No Objection
Comment (2024-05-01 for -30) Sent
Thanks for a very thorough shepherd writeup.

The SHOULDs in the last paragraph of Section 5 are bare.  Why are they not MUSTs?  What's the choice we're giving implementers here, and what guidance should they have to decide?

John did a good job of finding other BCP 19 and IANA issues before I got to them, so I second his suggestions.
Paul Wouters
No Objection
Comment (2024-04-30 for -30) Sent
The Security Considerations doesn't say _anything_ about something that could apply to this documents feature? Is there really nothing at all to consider?


        Group communication for CoAP has been enabled in
        [I-D.ietf-core-groupcomm-bis]

Maybe say "has been defined in" ?

        Reverse Path field MAY contain none, one, or more sub-TLVs.

Remove the "MAY" here? Or explain what not following the MAY means?

Similar for:

         None, one or more sub-TLVs MAY be included in the BFD Reverse Path TLV.

Related:

        an implementation MAY be able to control that limit
Roman Danyliw
No Objection
Comment (2024-04-26 for -30) Not sent
Thank you to Linda Dunbar for the GENART review.

To the MPLS WG chairs: it wasn’t clear which milestone in the charter this work fit under.  I does not appear to have one.

** Section 6.1.  Please update Table 1 to explicitly say that the Sub-TLV Registry column should read “No Sub-TLVs”

** Section 6.  Please add guidance to the RFCEditor somewhere in the text to say the obvious – that “This document” should be replaced by the published RFC number.
Zaheduzzaman Sarker
No Objection
Comment (2024-05-02 for -30) Sent
Thanks for working on this document. Thanks to Lars for his TSVART review. I see reviewer's comments has been addressed.
Éric Vyncke
No Objection
Comment (2024-05-02 for -30) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-mpls-bfd-directed-30

Thank you for the work put into this document.

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

Special thanks to Nicolai Leymann for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

Thanks also to Murray and John for spotting BCP19-related issues.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

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

## 

# COMMENTS (non-blocking)


## Section 1

```
For the case when BFD is used to detect defects of the traffic engineered LSP the path the BFD control packets transmitted by the egress BFD system toward the ingress may be disjoint from the LSP in the forward direction.
```
The above text is very hard to parse.


`More implementations are encouraged to understand better the operational impact of the mechanism described in the document.` this sounds more application for an I-D with an intended status of 'experimental' though.