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

[Mach Chen <[e-mail]>]

Hi Nobo,

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

Please see my reply inline...
> 
> From: Nobo Akiya [mailto:[e-mail]]
> Sent: Saturday, July 04, 2015 4:17 PM
> To: mpls; [e-mail]
> 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.

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

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.

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

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

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

Agree.

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

I will leave this to Greg to answer:-)

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

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.

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

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

> -Nobo