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

Gregory Mirsky <> Sat, 08 August 2015 01:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1DA361ACCFD; Fri, 7 Aug 2015 18:02:15 -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 YaVxgxFzfVGx; Fri, 7 Aug 2015 18:02:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 793B71A894C; Fri, 7 Aug 2015 18:02:10 -0700 (PDT)
X-AuditID: c6180641-f79556d0000002c8-5e-55c4ec248fb1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 09.59.00712.42CE4C55; Fri, 7 Aug 2015 19:34:28 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Fri, 7 Aug 2015 21:02:00 -0400
From: Gregory Mirsky <>
To: Ross Callon <>
Thread-Topic: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03
Thread-Index: AdC+PcT+J6C8Nh5rR/SbGsOgRmpbuAHpvzxAAjrXv5AAqU2WgA==
Date: Sat, 08 Aug 2015 01:01:59 +0000
Message-ID: <>
References: <AAE428925197FE46A5F94ED6643478FEB1120B3F41@HE111644.EMEA1.CDS.T-INTERNAL.COM> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_004_7347100B5761DC41A166AC17F22DF1122189114Beusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA2WTbUhTYRTHe+69u/dOFB7nzFMWyFCI3lxlOnuxGQQjyV5IivqQiy5mmcWm VtAHEcsyK80yXS9bbZplWWn0ogbzLWuWLbQix1LTpKUpamZKRrv3LjL69jvP/3+ec55zeFhS 1kXPZBOTUzhdsjZJQXtR+ak1MQuC+xvilFdGIlRd5hxGlVWRTarst/1U5a02WtVefEOi6mkZ oFSTpW2UymnKoNSs5rHByWgyG75KNBbLOKF5l/GG0VxzRGiOuYI031pH6A3MNq8Vu7ikxDRO FxoV77W78ed1yQHHJ3RocrSeSUcfWlA2krKAw+D66VKJyNPB/uEOzbMMNyKwnlZmIy83lyAY +DFI8gKNF8PnezkMz3IcAvbOCZI3kdhKgsNVQvCCH1ZDQ3kmIZqi4ZutihZ5Nbw9kSecUzgY TjWaKZ598Dqoz+5AYrVRBGUZrUIFKdbCWFu6kIzc7Y3ZbgnJJA6A9h4jIbYth67XzbTI/uDq /uV5jgLOFre4mXX7E+Hly81iLV94XtRD5SJ/w5SbDH9dhiku0bIf8upfeHg+mKqHaZHnQcnV PvIPv7B2E/+fz4LK8yeQQRjRUQRZhW1CIMOVCJqHahkxuIvgktlEicF5AuxNAxKDsIdzCPIt W0XhAYKKNwWelHwErhGjUJHGy6G8tInmBTluIyD3To7Qrh+OgdwGs9CuHG+CRsdZRuSFUFxk FDz8ImodDynx2Wqwvs9g/p0MP8v50J930cMr4WN1PyUyBkvNK1Lk2dBvvCIxTNkD3xDgKm8o LLV7hDDoLbsvjBvwHDBfUJtQ8E3Epuq5tH0JixdVIPefeAp09CNkGo6sQ5hFCm8fk6k+TibR pukP76tDgSylCPAJjE2Ok+EEbQq3l+MOcLodutQkTl+HCFY6Mx0FO1OWrEp3lVdHjzuVRPjH vX3DJ89V2jqWupYt7D6jmLjh3/wkKH77moPfIzMHo1FKeNOeIxYb4fR3hTyb5re0fSgkzDfm 9Zdpxo5ZoXfLisJHlEsK+6ypURvXGwuw5bjUd/mzy1iyJWAtU9ebFKQOVx6O7ZV2yjfc/pG5 c45xxikFpd+tXTSX1Om1vwFoBG3S9AMAAA==
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: Sat, 08 Aug 2015 01:02:15 -0000

Dear Ross, et. al,
we have posted the update. We hope we've addressed comments received from Thomas and Nobo during MPLS-RT review.


From: Ross Callon []
Sent: Tuesday, August 04, 2015 9:13 AM
To: Gregory Mirsky
Cc:; Jeff Tantsura;;;;;
Subject: RE: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03


Do you feel that you are ready to post the update?

I believe that the next steps here are for you to post the update (whenever the authors feel that you are ready), for me to check with the MPLS-RT reviewers to make sure that they are fine with the update, to do an IPR poll, and then to call for WG adoption.

Thanks, Ross

From: Gregory Mirsky []
Sent: Friday, July 24, 2015 3:51 AM
Cc: Ross Callon;<>; Jeff Tantsura;<>;<>
Subject: RE: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03

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.



--- Begin Message ---
A new version of I-D, draft-mirsky-mpls-bfd-directed-04.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:		draft-mirsky-mpls-bfd-directed
Revision:	04
Title:		Bidirectional Forwarding Detection (BFD) Directed Return Path
Document date:	2015-08-08
Group:		mpls
Pages:		10

   Bidirectional Forwarding Detection (BFD) is expected to monitor bi-
   directional paths.  When a BFD session monitors in its forward
   direction an explicitly routed path there is a need to be able to
   direct egress BFD peer to use specific path as reverse direction of
   the BFD session.


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

--- End Message ---