[mpls] Review of draft-mirsky-mpls-bfd-directed-03

[Nobo Akiya <[e-mail]>]

Hello,

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.


Section 2

o if reverse direction is in Down state, the head-end node would not
   receive indication of forward direction failure from its egress
   peer.

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


Section 3.1.1

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


Section 3.1.2

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      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

   Section 3.3

   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.

   Section 4

   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.


Section 4

   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

   Section 3.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.

   Section 5.2

   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?


General

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

Thanks!

-Nobo