Re: [mpls] MPLS-RT review of draft-mirsky-mpls-bfd-directed-03

Gregory Mirsky <> Fri, 24 July 2015 07:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A31F1B2FF4; Fri, 24 Jul 2015 00:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5qoAh12EfHEd; Fri, 24 Jul 2015 00:51:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A74B1B2FF2; Fri, 24 Jul 2015 00:51:20 -0700 (PDT)
X-AuditID: c6180641-f794d6d000001dfb-d3-55b18654a3f2
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8B.0B.07675.45681B55; Fri, 24 Jul 2015 02:27:00 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Fri, 24 Jul 2015 03:51:18 -0400
From: Gregory Mirsky <>
To: "" <>, "" <>, "" <>
Thread-Topic: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03
Thread-Index: AdC+PcT+J6C8Nh5rR/SbGsOgRmpbuAHpvzxA
Date: Fri, 24 Jul 2015 07:51:18 +0000
Message-ID: <>
References: <AAE428925197FE46A5F94ED6643478FEB1120B3F41@HE111644.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <AAE428925197FE46A5F94ED6643478FEB1120B3F41@HE111644.EMEA1.CDS.T-INTERNAL.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_005_7347100B5761DC41A166AC17F22DF11221883589eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUyuXSPn25I28ZQg7b3FhYPF/ewW7Rv6mK2 uLBW2GLd5VNsFreWrmS1+LviCovF3QVNLA7sHi1H3rJ6LFnyk8njetNVdo9Ft8092l4qeHy5 /JktgC2KyyYlNSezLLVI3y6BK+PUxqCC61u4K5pevmFpYLzRzN3FyMkhIWAicejDfXYIW0zi wr31bF2MXBxCAkcZJV7u384C4SxnlNi+7hoTSBWbgJHEi4097CAJEYHDjBIt+7cxgjjMAs8Y JU71TgWbJSzgIHFkXQtYh4iAo8SXU7vYIGwjiQ/PmsDiLAKqEm+fXASr5xXwldjWMBUsLiQQ JdF75i5YnFMgWmLB2qnMIDYj0H3fT60Bq2EWEJe49WQ+E8TdIhIPL55mg7BFJV4+/scKYStJ zHl9jRmiPlPi3bGjULsEJU7OfMIygVF0FpJRs5CUzUJSBhHPl9hwoR+qRkdiwe5PbBC2tsSy ha+ZYewzBx4zYYpXSRzff4kRZs71hSeAbFB4/WKU2PjoJStEQlFiSvdDdgg7QOLU+26oZiuJ eVevsEM0AONkw/cT7MgaFjAKrGLkKC1OLctNNzLcxAhMRsck2Bx3MC74ZHmIUYCDUYmHd4H2 xlAh1sSy4srcQ4zSHCxK4rzSfnmhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhg39qcockns 6J441ye3/3iE4RX2yU/uXv4qHfj8L9OHg9duHyiYcHoJi8GR3emv7ezfqTheXuOdeXLpq/WC QpE/AqS6WEK/6H4+yLip8edV0R280azr5k4M717d/JVxeo/NRaNrWceWSXxnkTygqPbG86HC 4WIlyVjLx2bbW1Q2BxRNEZNdnT5BiaU4I9FQi7moOBEASq6UKycDAAA=
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [mpls] MPLS-RT review of draft-mirsky-mpls-bfd-directed-03
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jul 2015 07:51:28 -0000

Hi Thomas,
would greatly appreciate if you kindly review proposed changes to address your comments. I've attached diff and MS copy of what may be next version.


From: []
Sent: Tuesday, July 14, 2015 4:03 PM
Cc:;; Gregory Mirsky; Jeff Tantsura;;
Subject: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03


I have been selected as reviewer of

I think the draft is coherent, technically sound and operational useful. It extents the explicit path capability for the backward direction of _bidirectional_ forwarding detection (BFD). The document is ready for WG adoption.

Some comments:

Section 1.1.1, Terminology:
I am not sure, whether the term _MPLS_ is really required in this section.

Section 3.1, "Case of MPLS Data Plane": Structure of sub-TLV specification.
The whole section describes, that three sub-TLV are specified for usage: "Static", "RSVP-TE" and "Segment Routing". For "Static" and "RSVP-TE", the draft refers to the according RFC (that's fine). But the structure of this section contains only a subsection for "Segment routing" and the reference to the other sub-TLV is part of this subsection. I propose to add two additional subsections "Static" (3.1.x) and "RSVP-TE" (3.1.x) with the references and remove it from the subsection "Segment Routing" to be more coherent.

Section 3.1.2: "Segment Routing Tunnel Sub-TLV >
The section specifies the encoding of the SR tunnel Sub-TLV with the encoding of the label stack elements. I think it makes sense to describe the usage of this information in the draft ("copy this information to the label stack"). Is the remote PE (initiator) allowed to add additional segments bases on his local information or is the encoded label stack strict?

Section 3.3:
This section confused me. Maybe it should be considered to be rewritten (or explained specifically to me).
Who is the _initiator_ in this case for the BFD reverse path scenario?

Section 3.4: "Return Codes"
The paragraph repeats the description text of the return code 2 times.  The section specifies, that the egress LSR _MAY_ send back the return code. In section 3.1.1, last paragraph, the behavior is specified, that the egress LSR may set up the BFD session or not, but in both cases, it sends back the return code (are the MAYs are concatenated in the case, when the BFD session is set up - see also comment from Nobo?). This implies, that the egress LSR _MUST_ send the return code, when the reverse path is not known.

Section 4 "Use case scenario":
The "value N" and "value M" are confusing, because it uses the same vocabulary as the nodes in the network example (capital letter). It could be called "foobar" if it is not for interest.