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

Gregory Mirsky <> Thu, 23 July 2015 09:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 479C21A8756; Thu, 23 Jul 2015 02:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.2
X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RG-KLUQH4zZX; Thu, 23 Jul 2015 02:22:19 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14EB41A0377; Thu, 23 Jul 2015 02:22:18 -0700 (PDT)
X-AuditID: c6180641-f794d6d000001dfb-2a-55b04a31a3dc
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 88.89.07675.13A40B55; Thu, 23 Jul 2015 03:58:09 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Thu, 23 Jul 2015 05:22:14 -0400
From: Gregory Mirsky <>
To: "" <>, "" <>, "" <>
Thread-Topic: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03
Thread-Index: AdC+PcT+J6C8Nh5rR/SbGsOgRmpbuAG5iKUQ
Date: Thu, 23 Jul 2015 09:22:14 +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-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF112218826C5eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyuXRPlK6h14ZQgzMdOhYPF/ewW7Rv6mK2 uLBW2GLd5VNsFreWrmS1+LviCovF3QVNLA7sHi1H3rJ6LFnyk8njetNVdo9Ft8092l4qeHy5 /JktgC2KyyYlNSezLLVI3y6BK+PwtEbGggvTGCtaFixka2BsaWXsYuTkkBAwkViyZzaULSZx 4d56ti5GLg4hgaOMEgs/HWWCcJYzSiw+vooJpIpNwEjixcYedpCEiMBhRomW/dsYQRxmgWeM Eqd6p7KDVAkLOEgcWdcC1iEi4Cjx5dQuNgjbSOJI334WEJtFQFVizYdNYDW8Ar4SO59PYQax hQSiJHrP3AWbwykQLbFg7VSwOCPQfd9PrQGrZxYQl7j1ZD4TxN0CQD+cZ4awRSVePv7HCmEr SXz8PZ8doj5f4s/DF1C7BCVOznzCMoFRdBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvM gcdMyOILGNlXMXKUFqeW5aYbGW5iBMbsMQk2xx2MCz5ZHmIU4GBU4uFNENoQKsSaWFZcmXuI UZqDRUmcV9ovL1RIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo3rLxbTtcSqZlxWPpxSlXTlY dS0/K13mxZf0GO7KXyeVr8TKhC9POjxLzLNguoHQlfPT58yL3Pv3vdIz+T3ftuu96uv78VpH /1f+ZnZf5owZMQ1pM1dd+WZfeW6p2KHpAktMdAsWn7p+g0E6yuOV2pE5TxaI+eh+TzKpmP1+ duwOYd2Ll6xE3imxFGckGmoxFxUnAgAtFIujugIAAA==
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: Thu, 23 Jul 2015 09:22:23 -0000

Hi Thomas,
many thanks for thorough review and thoughtful and most helpful comments and suggestions. Please find my answers in-line and tagged GIM>>.


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.

GIM>> Agree

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.

GIM>> Will extract references to Static and RSVP-TE and format into subsections.

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?

GIM>> This is very interesting angle. We thought that it is strict but I think that if egress node instructed to make stack more explicit it MAY do so. In other words, egress SHOULD NOT exclude any LSE from the stack but MAY only add. Would you agree with this interpretation?

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?

GIM>> The term "initiator" is inherited from LSP Ping for Segment Routing. I'll discuss with authors and either map to another, clearer term or provide explanation of roles and 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.

GIM>> Yes, Nobo as well pointed to duplicate use of MAY in one sentence. Idea was that use of LSP Echo Reply is optional, hence the first MAY. And use of Return Code is proposed as optional - thus the second MAY. If the generic idea sound, will re-word. If normative language should be different - open for suggestion.

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.

GIM>> Agree, will update in the next version.