Return-Path: 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 AA8701A1A86; Tue, 4 Aug 2015 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtM-U9fKbnxd; Tue, 4 Aug 2015 12:19:28 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97441A00BB; Tue, 4 Aug 2015 12:19:27 -0700 (PDT) X-AuditID: c6180641-f79556d0000002c8-96-55c0a7858ed2 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 95.9E.00712.587A0C55; Tue, 4 Aug 2015 13:52:37 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Tue, 4 Aug 2015 15:19:23 -0400 From: Gregory Mirsky To: Ross Callon Thread-Topic: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03 Thread-Index: AdC+PcT+J6C8Nh5rR/SbGsOgRmpbuAHpvzxAAjrXv5AABl4G0A== Date: Tue, 4 Aug 2015 19:19:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1122188DD02@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221883589@eusaamb103.ericsson.se> In-Reply-To: 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_7347100B5761DC41A166AC17F22DF1122188DD02eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyuXRPiG7r8gOhBhM6VCweLu5ht2jf1MVs cWGtsMW6y6fYLG4tXclq8XfFFRaLuwuaWBzYPVqOvGX1WLLkJ5PH9aar7B6Lbpt7tL1U8Phy +TNbAFsUl01Kak5mWWqRvl0CV8aXuxtZC77uYKw4sHslUwPj3SWMXYycHBICJhJrp21mgrDF JC7cW8/WxcjFISRwlFFixbsfrBDOMkaJrsvzmEGq2ASMJF5s7GEHsUUEVCUuPPjFDFLELPCL SWLT9C42kISwgIPEkXUtTBBFjhJfTu1ig7CdJL72PwAbxCKgIrFk+Ukwm1fAV+JOz30miG1f GSVWN10G28ApkCjx/UoDWDMj0H3fT60BG8osIC5x68l8qLsFJJbsOc8MYYtKvHz8jxXCVpKY tPQcK0R9vsSZ7atYIJYJSpyc+YRlAqPoLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkD j5mQxRcwsq9i5CgtTi3LTTcy3MQIjNljEmyOOxgXfLI8xCjAwajEw6uwZn+oEGtiWXFl7iFG aQ4WJXFeab+8UCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MDZ3fhMsqI9XLl8k7RJrpJnAL Pri2I0FUYFEMT1iOUMp2348L5Q4K2ufPbNAtlG2a/XxO2Wz2ysMm1+evmp7OK2ps+Kx5eubp 88+fV3lwm4WF3/Nz2ntAe+4ruTnWOdzntjIu7712ouiJUgmP75TbPIdf7XpodGZ/184zXj+n 7t2+NZkt03G9EktxRqKhFnNRcSIA+oIX27oCAAA= Archived-At: Cc: "mpls@ietf.org" , "draft-mirsky-mpls-bfd-directed@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] MPLS-RT 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 19:19:32 -0000 --_000_7347100B5761DC41A166AC17F22DF1122188DD02eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, many thanks for you kind consideration. I agree and support the plan you've= set forward. I believe Thomas Beckhaus agreed to proposed changes that address his MPLS-= RT review. Work on addressing comments by Nobo still continues. We'll try = to upload the new version by the end of this week. Regards, Greg From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, August 04, 2015 9:13 AM To: Gregory Mirsky Cc: mpls-chairs@ietf.org; Jeff Tantsura; mach.chen@huawei.com; Ilya@nobulus= .com; Thomas.Beckhaus@telekom.de; mpls@ietf.org; draft-mirsky-mpls-bfd-dire= cted@tools.ietf.org Subject: RE: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03 Greg; 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 rev= iewers 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 [mailto:gregory.mirsky@ericsson.com] Sent: Friday, July 24, 2015 3:51 AM To: Thomas.Beckhaus@telekom.de; mpls@iet= f.org; draft-mirsky-mpls-bfd-directed@tools.ietf.org<= mailto:draft-mirsky-mpls-bfd-directed@tools.ietf.org> Cc: Ross Callon; mpls-chairs@ietf.org; Jeff Ta= ntsura; mach.chen@huawei.com; Ilya@nobulus.com= 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 y= our comments. I've attached diff and MS copy of what may be next version. Regards, Greg From: Thomas.Beckhaus@telekom.de [mailto= :Thomas.Beckhaus@telekom.de] Sent: Tuesday, July 14, 2015 4:03 PM To: mpls@ietf.org; draft-mirsky-mpls-bfd-directed@too= ls.ietf.org Cc: rcallon@juniper.net; mpls-chairs@ietf.org; Gregory Mirsky; Jeff Tantsura; mach.chen@huawe= i.com; Ilya@nobulus.com Subject: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03 Hello, I have been selected as reviewer of http://tools.ietf.org/html/draft-mirsky= -mpls-bfd-directed-03. I think the draft is coherent, technically sound and operational useful. It= extents the explicit path capability for the backward direction of _bidire= ctional_ 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: "S= tatic", "RSVP-TE" and "Segment Routing". For "Static" and "RSVP-TE", the dr= aft refers to the according RFC (that's fine). But the structure of this se= ction 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 additio= nal 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 encodi= ng of the label stack elements. I think it makes sense to describe the usag= e of this information in the draft ("copy this information to the label sta= ck"). 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 sessi= on 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 vocabul= ary as the nodes in the network example (capital letter). It could be calle= d "foobar" if it is not for interest. Regards. Thomas --_000_7347100B5761DC41A166AC17F22DF1122188DD02eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

many thanks for you kind = consideration. I agree and support the plan you’ve set forward.<= /o:p>

I believe Thomas Beckhaus= agreed to proposed changes that address his MPLS-RT review.  Work on = addressing comments by Nobo still continues. We’ll try to upload the new version by the end of this week.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Tuesday, August 04, 2015 9:13 AM
To: Gregory Mirsky
Cc: mpls-chairs@ietf.org; Jeff Tantsura; mach.chen@huawei.com; Ilya@= nobulus.com; Thomas.Beckhaus@telekom.de; mpls@ietf.org; draft-mirsky-mpls-b= fd-directed@tools.ietf.org
Subject: RE: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03

 

Greg;

 <= /p>

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

 <= /p>

I believe that the next s= teps here are for you to post the update (whenever the authors feel that yo= u 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 th= en to call for WG adoption.

 <= /p>

Thanks, Ross

 <= /p>

From: Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, July 24, 2015 3:51 AM
To: Thomas.Beckhaus@te= lekom.de; mpls@ietf.org; draft-mirsky-mpls-bfd-directed@tools.ietf.org
Cc: Ross Callon; mpls-chairs= @ietf.org; Jeff Tantsura; mach.chen@huawei.com; Ilya@nobulus.com
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.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

 <= /p>

From: Thomas.Beckhaus@telekom.de [mailto:Thomas.Beckhaus@tel= ekom.de]
Sent: Tuesday, July 14, 2015 4:03 PM
To: mpls@ietf.org; draft-mirsky-mpls-bfd-directed@tools.ietf.org
Cc: rcallon@juniper.net; = mpls-chairs@ietf.org; Gregory Mirsky; Jeff Tantsura; mach.chen@huawei.com; Ilya@nobulus.= com
Subject: MPLS-RT review of draft-mirsky-mpls-bfd-directed-03

 

Hello,

 

I have been selected as reviewer of ht= tp://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed-03.<= /span>

 

I think the draft is coherent, technica= lly sound and operational useful. It extents the explicit path capability f= or the backward direction of _bidirectional_ forwarding detection (BFD). The document is ready for WG adoption.<= /p>

 

Some comments:

 

Section 1.1.1, Terminology:<= /span>

I am not sure, whether the term _MPL= S_ is really required in this section.

 

Section 3.1, “Case of MPLS Data P= lane”: Structure of sub-TLV specification.

The whole section describes, that three= sub-TLV are specified for usage: “Static”, “RSVP-TE̶= 1; and “Segment Routing”. For “Static” and “R= SVP-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 othe= r sub-TLV is part of this subsection. I propose to add two additional subse= ctions “Static” (3.1.x) and “RSVP-TE” (3.1.x) with the references and remove it from the subsection ”Segment Routing= 221; to be more coherent.

 

Section 3.1.2: “Segment Routing T= unnel Sub-TLV »

The section specifies the encoding of t= he 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 l= ocal information or is the encoded label stack strict?

 

Section 3.3:

This section confused me. Maybe it shou= ld be considered to be rewritten (or explained specifically to me).

Who is the _initiator_ in this c= ase for the BFD reverse path scenario?

 

Section 3.4: “Return Codes”=

The paragraph repeats the description t= ext of the return code 2 times.  The section specifies, that the egres= s 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 (a= re the MAYs are concatenated in the case, when the BFD session is set up &#= 8211; 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̶= 1;:

The “value N” and “va= lue M” are confusing, because it uses the same vocabulary as the node= s in the network example (capital letter). It could be called “foobar= ” if it is not for interest.

 

Regards.

 

Thomas

 

--_000_7347100B5761DC41A166AC17F22DF1122188DD02eusaamb103erics_--