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

Gregory Mirsky <gregory.mirsky@ericsson.com> Wed, 05 August 2015 23:23 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F31ACD02 for <mpls@ietfa.amsl.com>; Wed, 5 Aug 2015 16:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.2
X-Spam-Level:
X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eutYoaIBGpG0 for <mpls@ietfa.amsl.com>; Wed, 5 Aug 2015 16:23:51 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4951ACEFB for <mpls@ietf.org>; Wed, 5 Aug 2015 16:23:51 -0700 (PDT)
X-AuditID: c618062d-f799e6d00000329e-17-55c23e5f9997
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A8.81.12958.06E32C55; Wed, 5 Aug 2015 18:48:32 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 19:23:49 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Mach Chen <mach.chen@huawei.com>, Nobo Akiya <nobo.akiya.dev@gmail.com>, mpls <mpls@ietf.org>, "draft-mirsky-mpls-bfd-directed@tools.ietf.org" <draft-mirsky-mpls-bfd-directed@tools.ietf.org>
Thread-Topic: Review of draft-mirsky-mpls-bfd-directed-03
Thread-Index: AQHQtjHWT52rlfiXr0Kwzk1T+HvBqp3UA4fwgAAAHRCAKislIA==
Date: Wed, 5 Aug 2015 23:23:49 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1122188F2A6@eusaamb103.ericsson.se>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B486F6B@SZXEMA510-MBX.china.huawei.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B4B901E@SZXEMA510-MBX.china.huawei.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B4B901E@SZXEMA510-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1122188F2A6eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXSPt26C3aFQg+vvJSweLu5ht7iwVtji 1tKVrBZPzr1jsfi74gqLA6vHzll32T1ajrxl9Viy5CeTx/Wmq+weXy5/ZgtgjeKySUnNySxL LdK3S+DK+HL5PWtB3xmmitN/DzE1MO44zNTFyMkhIWAiMf1wAwuELSZx4d56NhBbSOAoo8SM S1FdjFxA9jJGiaV9G8Ea2ASMJF5s7GEHSYgIHGOUuPjgHztIgllAVeL68WawbmEBC4kNV38x g9giApYSeyZeZIGwnSSWrTsFNohFQEXiw9J1rCA2r4CvxLmfn1ggti1klJh2bhNYEadAmETX /zZGEJsR6Lzvp9YwQSwTl7j1ZD7UCwISS/acZ4awRSVePv7HCmErSUxaeo4Voj5f4u2x0+wQ ywQlTs58wjKBUXQWklGzkJTNQlI2i5EDKK4psX6XPkSJosSU7ofsELaGROucuezI4gsY2Vcx cpQWp5blphsZbGIERuUxCTbdHYx7XloeYhTgYFTi4V3w90CoEGtiWXFl7iFGaQ4WJXFex6i8 UCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M2gwOR+SbvhzTrCo/ItI4ufTGTv0H0++8Lk28 fZNLsHD9zK6UOxNaQ1ILXWYGx/eZTjWpPp2Y8Wyj6IG7X0M3BGpMSeWI8ln24uGRpWxzvsxV /pgketW14VTjlrvv1fqrBX7PmPrzxjTHK+c+T9rD6MOg0MWxdd/HRDfJO/nLvI7o2W1dyxN6 V4mlOCPRUIu5qDgRAFD+JiyrAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/UO-K81R6jLUWnCFqR5OwKfmMg_I>
Cc: Ross Callon <rcallon@juniper.net>
Subject: Re: [mpls] Review of draft-mirsky-mpls-bfd-directed-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 23:23:56 -0000

Hi Nobo,
thank you for great comments, insightful as always.
Mach provided many resolutions to your comments and I'll add couple more and propose text changes. Please let us know what do you think.
My notes are in-line and tagged GIM>>.

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen
Sent: Tuesday, July 14, 2015 12:54 AM
To: Nobo Akiya; mpls; draft-mirsky-mpls-bfd-directed@tools.ietf.org
Cc: Ross Callon
Subject: Re: [mpls] Review of draft-mirsky-mpls-bfd-directed-03

Hi Nobo,

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

Please see my reply inline...
>
> From: Nobo Akiya [mailto:nobo.akiya.dev@gmail.com]
> Sent: Saturday, July 04, 2015 4:17 PM
> To: mpls; draft-mirsky-mpls-bfd-directed@tools.ietf.org<mailto:draft-mirsky-mpls-bfd-directed@tools.ietf.org>
> 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.
>

GIM≫ Would the following wording be more deterministic:
   o  failure detection on the reverse path cannot reliably be
      interpreted as bi-directional failure and thus trigger, for
      example, protection switchover of the forward direction;

   o  if a failure of the reverse path being ignored, the ingress node
      would not receive indication of forward direction failure from its
      egress peer.


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

GIM>> Proposed re-wording:
   If the egress LSR cannot find path specified in the Reverse Path TLV
   it MUST 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".  The egress LSR MAY establish
   the BFD session over IP network [RFC5884].
I don’t think that egress must keep the Reverse Path and monitor its availability. If it was unavailable, ingress or controller may be monitoring it and signal new reverse path accordingly.

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

Indeed.
GIM>> Cleared
>
>
> 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.

GIM>> Yes, this is reference to an entry in the label stack. Would changing “Label Stack Element” to “Label Entry” in the figure and throughout the text clarify it?

>
>
> 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.
GIM>>> Added reference to 5884-clarifications:
   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 foobar-1 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 foobar-2
   [I-D.ietf-bfd-rfc5884-clarifications] and MAY include BFD Reverse
   Path TLV that references H-G-F-E-B-A tunnel.


>
>
> 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:-)
GIM>> I have full trust in ingenuity of the developers.

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


GIM>> Mach captured it perfectly. Would suggested change make text clear and unambiguous?

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

GIM>> We had not intended to change IP/UDP encapsulation of BFD control packets as defined in RFC5884. Should a note be added to Introduction
       This document does not modify IP/UDP encapsulation of BFD control packets as specified in [RFC5884].

Best regards,
Mach

> -Nobo
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls