Re: [Idr] WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending - Additional revisions needed

"Susan Hares" <shares@ndzh.com> Thu, 12 September 2019 06:30 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050221200E5; Wed, 11 Sep 2019 23:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.348
X-Spam-Level: *
X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 vG7XXnSXRX7Z; Wed, 11 Sep 2019 23:30:36 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 1169B120020; Wed, 11 Sep 2019 23:30:35 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=97.112.17.31;
From: "Susan Hares" <shares@ndzh.com>
To: "'Jeff Tantsura'" <jefftant.ietf@gmail.com>, "'Ketan Talaulikar \(ketant\)'" <ketant@cisco.com>, <idr@ietf.org>
Cc: <draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org>
References: <015001d568c1$2d102fb0$87308f10$@ndzh.com> <5478b600-a6c9-4a39-ba96-93165e297473@Spark>
In-Reply-To: <5478b600-a6c9-4a39-ba96-93165e297473@Spark>
Date: Thu, 12 Sep 2019 02:14:21 -0400
Message-ID: <001101d56931$53244ea0$f96cebe0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01D5690F.CC191740"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFIsHwNj7lft0dwA+g8DNchqsg3kwFgnb+SqDX4QbA=
Content-Language: en-us
X-Antivirus: AVG (VPS 190911-2, 09/11/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2greqCrBLbg8yrq7eR-unBIxuXQ>
Subject: Re: [Idr] WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending - Additional revisions needed
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: Thu, 12 Sep 2019 06:30:39 -0000

Jeff:

 

Thank you for updating the major points. 

I’ve indicated my review of the document is ok. 

 

I’ve updated the shepherd’s reflect an approval of the text. 

I’m missing 3 pieces of data on the draft I should have by 9/15:

early OPS-DIR review, early RTG-DIR review, and 

a request to IDR for information on other planned implementations. 

 

Sue 

 

From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com] 
Sent: Wednesday, September 11, 2019 6:36 PM
To: Ketan Talaulikar (ketant); idr@ietf.org; Susan Hares
Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org
Subject: RE: [Idr] WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending - Additional revisions needed

 

Sue, 

 

Many thanks for your comments, please see inline.

Updated draft has been published. 

 

Cheers, 

Jeff

On Sep 11, 2019, 9:51 AM -0700, Susan Hares <shares@ndzh.com>, wrote:



Ketan, Jeff,  Uma,  Greg and Nikos:

 

Thank you for the additions in -06.txt on the manageability section.

It helps clarify the manageability.  However, this draft needs

another revision to handle 2 major points (1) mentioning RFC7752bis,

2) yang model reference)) and an editorial point. 

 

I mentioned referencing RFC5572bis in my previous comments.

The text below gives some specific text as guidance.   

The yang model references added in -06.txt is not exactly accurate.

I’ve provided a textual suggestion.

 

We have two early reviews outstanding: OPS-DIR (overdue), and

RTG-DIR (due 9/14/2016).     If you could get -07.txt out

so both reviewers could review the -07.txt, it would be helpful.

 

Cheerily,  Sue

 

---------------

2 Major points:

 

Major point 1: RFC7752bis should be referenced.

                             It can be referenced as informational. 

[jeff] Ack, RFC7752bis would go into informal references not to delay the process.

 

Why change:  RFC7752 has known gaps in the clarity of the

   error handling section.  Pointing to work that

     is developing for RFC7752bis will answer questions

      that the security area wants to see resolved.

 

      I agree with the authors of RFC7752bis that rushing

      RFC7752bis work is not wise.  I have augmented the

      shepherd’s report with language to support this issue.  

              

Suggested textual changes:

Location:  7. Security Considerations  page 7.

What: [paragraph 2] replacement

 

Old/The document does not introduce security issues beyond those

Discussed in [RFC7752], [RFC8475], and [RFC8491]. /

 

New /The document does not introduce additional security issues beyond discussed

In [RFC7752], [RFC8476] and [RC8491].   However, [RFC7752] is being

revised in [RFC7752bis] to provide additional clarification in several portions

of the specification after receiving feedback from implementers.

One of the places that is being clarified is the error handling and security.

It is expected that after [RFC7752bis] is released that implementers will

update all BGP-LS base implementations improving the error handling for

protocol work (including this draft) that depend on this function.   

[jeff] Ack

Major Point 2:  [draft-ietf-spring-sr-yang] does not cover

the manageability features of MSD in BGP

 

Why change:  The yang model [draft-ietf-spring-sr-yang] data model

does not provide any  link to the BGP model or an extension for BGP-LS,

or a further extension to BGP-LS for SR-routing MSD.

 

Text change:

Location: section 6, second full paragraph: 

 

Old: /The extensions specified in this document, do not introduce

any new configuration or monitoring aspects in BGP or BGP-LS

other than as discussed in [RFC7742]. /

 

New:/The extensions specified in this document, do not specify

any new configuration or monitoring aspects in BGP or BGP-LS.

The specification of BGP models BGP and BGP-LS models is an

ongoing work based on the Yang model  [draft-ietf-bgp-model-06].

 

The management of the MSD features within an ietf segment-routing

stack  is also an ongoing work based on the yang model specified

in [draft-ietf-spring-sr-yang].   Management of the segment routing

in IGPs is ongoing work for ISIS  (see [draft-ietf-isis-sr-yang]), and

OSPF (draft-ietf-ospf-sr-yang)]. /

 

[jeff] Ack

 

 

Editorial issue:

 

Terminology

Please add a definition for MSD capabilities  - you use it in section 2 first sentence.

 

Why: A definition will help the reader.   Otherwise, I suspect we will get an AD comment or

an IESG comment on “what is a MSD capability”. 

[jeff] Ack

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Wednesday, September 11, 2019 10:46 AM
To: 'Ketan Talaulikar (ketant)'; idr@ietf.org
Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org
Subject: Re: [Idr] WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending

 

Ketan:

 

Thank you for the reminder.  I am reviewing the document and the shepherd’s report this morning.   

 

Sue Hares

 

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Tuesday, September 10, 2019 1:14 PM
To: Susan Hares; idr@ietf.org
Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org
Subject: RE: [Idr] WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending

 

Hi Sue,

 

We have published the v06 last week. There have been no further implementation report updates (besides the two that were done previously).

 

Could you please review the draft and implementation report updates for the draft progression?

 

Thanks,

Ketan

 

From: Susan Hares <shares@ndzh.com>
Sent: 15 August 2019 20:46
To: idr@ietf.org
Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org
Subject: RE: [Idr] WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending

 

The WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt has completed. 

 

The authors should

1.	Submit draft-ietf-idr-bgp-ls-segment-routing-msd-06.txt
2.	Complete the Wiki page on the implementations.

 

At that point, the Shepherd report can be completed, and the draft sent to Alvaro for review.

 

Cheerily, Sue

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, August 9, 2019 11:17 AM
To: idr@ietf.org
Subject: Re: [Idr] WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending

 

Ketan:

 

Thank you for this response.   Please send me a note when you begin you have completed -06.txt,

and any updates.

 

I encourage other implementers to either update the web page

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations

 

or to send information to the WG chairs.

 

Cheerily, Susan Hares

 

 

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Thursday, August 8, 2019 7:07 AM
To: Susan Hares; 'IDR'
Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org
Subject: RE: WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending

 

Hi Sue/All,

 

The authors are working on the update and we’ll post it once done/ready.

 

I’ve updated the implementation report with most of the items that you have suggested for the implementations that I am aware of. For the error handling part, since that text would get added in v06, we can look at that aspect after the posting is done.

 

I believe there are other implementations and would request WG members to update the same at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations

 

Thanks,

Ketan

 

From: Susan Hares <shares@ndzh.com>
Sent: 07 August 2019 22:54
To: 'IDR' <idr@ietf.org>
Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org
Subject: WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt - WG consensus pending

 

The WG LC on draft-ietf-idr-bgp-ls-segment-routing-msd-05.txt concludes on 8/8/2019.

 

At this point, we have about 12 people who have participated in this last call by making comments.   All comments regarding publication appear to be positive.   If you wish to make additional comments, please make your comments by 8/8/2019.

 

The implementations come from a single vendor (cisco).  A 1 week query will be made (starting on 8/8/2019)  to determine if the WG will accept 2 implementations from the same vendor to meet IDR requirement for 2 implementations.  

 

The authors of this draft (Jeff,  Uma, Ketan, Greg, Nikos) need to do the following:

1.	Post an -06.txt  revision that addresses any comments received at IETF 105 or on the WG list,
2.	Upgrade the interoperability report at

  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-msd%20implementations

 

With details on the following MUST Clause support

 

Reference are:  section 3  

 

      *  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.]

Reference in section 4: - a similar definition

      *  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 link when used as
         an outgoing interface.] 

 

 

Expected addition to Wiki document is the following information

------------------------------------------------------------------------------

Support for zero MSD-value:  

    Node MSD TLV:  yes/no

    Link MSD TLV: yes/no

 

Mechanism for reporting zero-value:

      

Error handling of MSD TLV  (according to RFC7752):    

  Node MSD TLV:  yes/no

  Link MSD TLV :    yes /no

 

 

Mechanism for reporting errors on MSD TLV:  (log error in log file)