I’ve been selected as a reviewer for draft-mirsky-mpls-bfd-directed-03. Please find my review below.
I believe this is a useful, coherent, and technically sound document. However, it does have issues that require attention and consideration.
o if reverse direction is in Down state, the head-end node would not
receive indication of forward direction failure from its egress
[NOBO] I found above to be slightly unclear in 2 aspects.
Since this section is describing the limitations of using BFD on an unidirectional explicitly routed path, what does "if reverse direction is in Down state" mean?
Additionally, "would not receive indication of forward direction failure from its egress peer" is a bit cryptic. If the egress peer detected that forward direction failed (e.g., BFD session timed out), then the egress peer will send few BFD control packets with DOWN state, IP routed. Thus the ingress peer will notice the problem of the forward direction.
Readers can likely benefit from having this bullet point better clarified.
If the egress LSR fails to establish the BFD session because path
specified in the Reverse Path TLV is not known, the egress MAY
establish the BFD session over IP network [RFC5884] and MAY send Echo
Reply with the Reverse Path TLV received and the return code set to
"Failed to establish the BFD session". The specified reverse path
was not found" (TBD4) Section 3.4.
[NOBO] There are two instances of "MAY" in above.
If the egress establishes the BFD session over IP network and does not send Echo Reply with "error", then it would be difficult for the ingress to know what path egress is using for the BFD session (IP routed or ingress specified path). To avoid this, should the second MAY be MUST, such that if the egress chose to use IP network, then the egress has to send the Echo Reply with "error"?
Related to this, if the egress chose to use the BFD session over IP network, but the ingress specified path became available some time later, then what is the expected behavior? Should this this described in the document?
Also there are 3 instances of '"' (quotation) characters in above, but the second instance should be removed (nit).
| Label Stack Element |
| Label Stack Element |
[NOBO] It would be good to clarify what "Label Stack Element" is. Is it the 4 octet index defining the offset in the SID/Index space? Potentially, we can benefit from referencing a document that describes its details (e.g., draft-ietf-isis-segment-routing-extensions).
Section 3.3 & Section 4
When LSP ping is used to bootstrap BFD session this document updates
this and defines that LSP Ping MUST include the FEC corresponding to
the destination segment and SHOULD NOT include FECs corresponding to
some or all of segment imposed by the initiator. Operationally such
restriction would not cause any problem or uncertainty as LSP ping
with FECs corresponding to some or all segments or traceroute may
preceed the LSP ping that bootstraps the BFD session.
In network presented in Figure 4 node A monitors two tunnels to node
H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap BFD session to monitor
the first tunnel, node A MUST include BFD Discriminator TLV with
Discriminator value N and MAY include BFD Reverse Path TLV that
references H-G-D-C-B-A tunnel. To bootstrap BFD session to monitor
the second tunnel, node A MUST include BFD Discriminator TLV with
Discriminator value M and MAY include BFD Reverse Path TLV that
references H-G-F-E-B-A tunnel.
[NOBO] Since FEC in the MPLS Echo Request will only carry the last SID, there is no way for the egress to distinguish the incoming BFD session bootstrapping request for A-B-C-D-G-H and A-B-E-F-G-H, if we go by RFC5884. By RFC5884, it would be one BFD session that overrides the old (i.e., FEC in both bootstrap requests are the same). If you want the procedures to work, you'll need to reference draft-ietf-bfd-rfc5884-clarifications where BFD discriminator becomes a demux key on the egress.
If an operator needs node H to monitor path to node A, e.g.
H-G-D-C-B-A tunnel, then by looking up list of known Reverse Paths it
MAY find and use existing BFD sessions.
[NOBO] There is a small window where both sides will end up initiating the BFD session bootstrapping. Do we want this document to clarify that scenario or leave it be?
Section 3.2 & Section 5.2
IPv6 can be data plane of choice for Segment Routed tunnels
[I-D.previdi-6man-segment-routing-header]. In such networks the BFD
Reverse Path TLV described in Section 3.1.1 can be used as well. IP
networks, unlike IP/MPLS, do not require use of LSP ping with BFD
Discriminator TLV[RFC4379] to bootstrap BFD session. But to specify
reverse path of a BFD session in IPv6 environment the BFD
Discriminator TLV MUST be used along with the BFD Reverse Path TLV.
The BFD Reverse Path TLV in IPv6 network MUST include sub-TLV.
The IANA is requested to assign two new sub-TLV types from
"Multiprotocol Label Switching Architecture (MPLS) Label Switched
Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV
Types 1, 16, and 21" sub-registry.
| Value | Description | Reference |
| X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document |
| X (TBD3) | Segment Routing IPv6 Tunnel sub-TLV | This document |
[NOBO] We are allocating "Segment Routing IPv6 Tunnel sub-TLV" in the LSP ping registry, but section 3.2 seems to indicate that we are not using LSP ping to bootstrap the BFD session. So ... I'm a bit confused. If we are using something else, besides LSP ping, to bootstrap BFD sessions for IPv6 Segment Routing, then are we allocating this Sub-TLV in the wrong registry space?
[NOBO] For the IP/MPLS case, if we want the egress to use BFD session over specified segment stack, then it would be best for the IP header to carry 127/8. Otherwise, incorrectly popped segment stack can still result in the BFD packets to be received back by the ingress node.