[Idr] Shepherd Review for draft-ietf-bgp-ls-segment-routing-msd-05.txt

"Susan Hares" <shares@ndzh.com> Sat, 08 June 2019 02:27 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9C7681200EC; Fri, 7 Jun 2019 19:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Mg0L27t2Xegp; Fri, 7 Jun 2019 19:27:10 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F0412006E; Fri, 7 Jun 2019 19:27:09 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org
Date: Fri, 07 Jun 2019 22:27:05 -0400
Message-ID: <06e501d51da1$aabc8780$00359680$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E6_01D51D80.23AD3170"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdUdoaQCS8PNg/UrTueEJJB/vFgqVA==
Content-Language: en-us
X-Antivirus: AVG (VPS 190607-4, 06/07/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BCC8wNMis9t809Qrr1gSgfaH6Oo>
Subject: [Idr] Shepherd Review for draft-ietf-bgp-ls-segment-routing-msd-05.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jun 2019 02:27:11 -0000

Jeff, Ketan, Uma, Greg, and Nikos: 


My initial shepherd review of draft-ietf-bgp-ls-segment-routing-msd-05.txt
has three points: 


1)      2 IPR statements means the draft will have to go through an IPR call
for the IPR issues 

2)      Error handling section needs to be added to the draft (requires

3)      The implementation report needs to be improved (see below)


After all things are completed, I will start the WG LC. 


Sue Hares 

(Shepherd/WG co-chair) 



2 IPR Statements 


The 2 IPR statements for this draft means that after all authors indicate
IPR knowledge,

I will need to do a WG call for considering the draft with 2 IPR statements.


Otherwise, the IESG may wish to cycle a discussion on the IPR.   

It takes less time to just do it up-front. 


Error handling


This draft must add an error handling section that indicates what happen if

Node MSD TLV and the Link MSD TLV are incorrectly parsed.  

This is a requirement for the shepherd/WG chair to send this to WG LC or the

QA reviews (RTG-DIR, OPS-DIR).  


I also would prefer to see 


as a WG document prior to sending this to the IESG.  


Could you check with the authors to determine its status? 

Otherwise, the error handling section in this draft will need

to be improved.  



Implementation report improvement 



The implementation reports for draft-ietf-idr-bgp-ls-segment-routing-msd-05
needs improving and your draft needs to have additional error handling


You need to indicate key features: 


1)      MSD and SR routing interaction 

MSD advertisements MAY be useful even if SR itself is not enabled.  


2)      MSD and BGP-LS interaction  

2a) The BGP-LS speaker may also advertise the
      MSD information for the local node and its links when not running any
      link-state IGP protocol e.g. when running BGP as the only routing


      2b) This enables sharing of MSD-Types that may
      be defined in the future by the IGPs in BGP-LS.



3)      Support for Node TLV parsing 

3a - feature support ( yes/no) 


3b-  MUST  (yes/20) 


         MSD-Value : a number in the range of 0-255.  For all MSD-Types,

         0 represents the lack of ability to impose an MSD stack of any

         depth; any other value represents that of the node.  This value

         MUST represent the lowest value supported by any link

         configured for use by the advertising protocol instance.



        3c) Support for Error handling if Node TLV is incorrectly parsed -
This needs to be specified your draft



4)      Support for Link MSD TLV 

4a) support for feature

4b) support for error handling if Link MSD is incorrectly parsed