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

From: Nobo Akiya <[email-masked]>
Date: Sat, 4 Jul 2015 17:16:51 +0900

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

---

From: Mach Chen <[email-masked]>
Date: Tue, 14 Jul 2015 07:54:02 +0000

Hi Nobo,

Thanks for reviewing the draft and the detailed and useful comments!

Please see my reply inline...
> 
> From: Nobo Akiya [mailto:[email-masked]]
> Sent: Saturday, July 04, 2015 4:17 PM
> To: mpls; [email-masked]
> Cc: Ross Callon
> Subject: Review of draft-mirsky-mpls-bfd-directed-03
> 
> 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.

Thanks.

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

I think there should be 3 situations:

1) the egress does not know the Reverse Path TLV, then the BFD session will not be established and a malformed error should be returned;
2) the egress does know the TLV but can't not find or use (e.g., due to local policy) the specified return path, then:
  2.a) chooses to use the BFD session over IP network, the Reverse Path TLV should be returned and the return code set to something like "The specified reverse path was not found/can't be used, the reverse BFD session is over IP network".
  2.b) fails to establish the BFD session, the Reverse Path TLV should returned and the return code set to something like "The specified reverse path was not found/can't be used, failed to establish the BFD session".

> 
> Also there are 3 instances of '"' (quotation) characters in above, but the second
> instance should be removed (nit).

Indeed.

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

IMHO, the Label Stack Element should refer to the label entry of a label stack. Greg corrects me if I am wrong.

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

Agree.

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

I will leave this to Greg to answer:-)

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

My understanding of Section 3.2 is that it does not say it will not use LSP ping to bootstrap BFD session for IPv6 SR. On the contrary, it intends to say when LSP Ping based bootstrapping mechanisms as defined in this document is used, the BFD Discriminator TLV and the BFD Reverse Path TLV MUST be both included. I think the confusion is coming from this sentence " IP networks, unlike IP/MPLS, do not require use of LSP ping with BFD Discriminator TLV[RFC4379] to bootstrap BFD session.", it does not bring many more meaning, so, remove it can resolve the confusion IMHO. Greg corrects me if I am wrong.

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

Specifying the return path is to reduce the false positive that the (non-congruent) return path may bring. If the packets can return back to the ingress node, it may be a good thing, IMHO. 

Best regards,
Mach