[Idr] shepherd review of draft-ietf-idr-bgp-ls-segment-routing-ext-08.txt

"Susan Hares" <shares@ndzh.com> Sun, 17 June 2018 12:35 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 ECDC8130EE1; Sun, 17 Jun 2018 05:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level:
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Px_F4IkKf9sh; Sun, 17 Jun 2018 05:35:39 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 AE1D8130E34; Sun, 17 Jun 2018 05:35:38 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.195.103;
From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
Cc: draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org, 'John Scudder' <jgs@juniper.net>, 'Alvaro Retana' <aretana.ietf@gmail.com>, "'Ketan Talaulikar (ketant)'" <ketant@cisco.com>
Date: Sun, 17 Jun 2018 08:35:27 -0400
Message-ID: <016d01d40637$ac404c90$04c0e5b0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_016E_01D40616.2531E0E0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdQGL5Y5fZ5Ztu4KQ9G6IFTdx3l20w==
Content-Language: en-us
X-Antivirus: AVG (VPS 180617-2, 06/17/2018), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mVc8RYCSXCbjWFa9kQOJ58Kd6tI>
Subject: [Idr] shepherd review of draft-ietf-idr-bgp-ls-segment-routing-ext-08.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.26
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: Sun, 17 Jun 2018 12:35:42 -0000

This is a shepherds review after WG LC, RTG-DIR QA review, and OPS QA
Review. 

 

Summary: I have minor issues and editorial comments on this document. The
minor issues will need to be resolved before this document is sent to the
IESG. The minors issues arise out of the shepherd's review of the document
and the two QA Reviews.

 

 

Thanks:

I want to thank the WG for its active review during WG LC, and following
people who provided specific early reviews on this document: 

1)  Robert Raszuk and Tony Li - during WG LC  

2)  Jeff Hass - during WG LC 

3)  Aijun Wang - during WG LC 

4)  Victoria Pritchard - RTG-DIR QA review 

5)  Joel Jaeggli - OPS QA review 

 

I want to thank the authors for a well written draft and productive
dialogues with the reviewers. 

 

Susan Hares 

 

 

----------

 

Minor issues: 

 

Source: Shepherd 

Issue 1: BGP Error handling 

 

Problem:   

The BGP Error handling in the document has two types:  malformed TLVs and
restrictions on the TLVs which can be inserted in the Node NLRI (section
2.1), Link NLRI (Section 2.2), and Prefix NLRI (section 2.3).  The error
handling in RFC5572 does not specifically handle the restrictions on TLVs. 

 

Suggested solution: 

Denote these errors as NLRI content errors and specifically indicate how
these are treated. 

 

Textual changes: 

Section 2.1 on page 6, just before 2.1.1 paragraph 

New/

If a BGP Peer supporting BGP-LS incorrectly adds these TLVs to the Link
Attribute or the Prefix attribute of the BGP-LS NLRI, this a   content error
rather than a malformed NLRI.  See the manageability     section for an
explanation of how content errors are handled.

/

Section 2.2 on page 10, after table 2 and the paragraph that ends
"TLV/Sub-TLV described below." 

 

New/

If a BGP Peer supporting BGP-LS incorrectly adds these TLVs to the Node
Attribute or the Prefix attribute of the BGP-LS NLRI, this a   content error
rather than a malformed NLRI.  See the manageability     section for an
explanation of how content errors are handled.

/

 

Section 2.3 on page 14, just before 2.3.1 

 

New

/If a BGP Peer supporting BGP-LS incorrectly adds these TLVs to the Node
Attribute or the Link attribute of the BGP-LS NLRI, this content error
rather than a malformed NLRI.  See the manageability     section for an
explanation of how content errors are handled.

/

 

Replace the 3rd sentence of the second paragraph of 5. Manageability
Considerations

 

Old/

Specifically the determination of malformed attributes and their
handling follow the base BGP-LS specification [RFC7752
<https://tools.ietf.org/html/rfc7752> ].

/

New /

Specifically, the malformed NLRIs attribute tests 

in the FAULT Management section of [RFC7752
<https://tools.ietf.org/html/rfc7752> ]

now encompass the new TLVs for the BGP-LS NLRI in this document. 

 

Three content restrictions for TLV insertion are given in sections 2.1, 2.2,
and 2.3 to which limit the inclusion of TLVs to certain BGP-LS NLRI
attributes. Any BGP-LS NLRI which does not abide by the content restriction
will be treated as a malformed BGP-LS NLRI.  

 

If BGP-LS NLRI with these extensions is determined to be malformed

by the receiving BGP peer, the BGP peer receiving the BGP packet 

drops the attribute the malformed BGP-LS NLRI was detect in  (either the
BGP_MP_REACH_NLRI attribute or the BGP_MP_UNREACH_NLRI attribute). 

/

 

Issue 2: 

Source: Shepherd: 

Problem: 

section 2.1.3 does not indicate where the values come for the 1 octet
identifying the algorithm.  If these are configured on a network basis,
please identify this point. If these are part of an ISIS or OSPF standard
please specify.

 

Issue 3:

Source: Joel Jaeggli's OPS-DIR review 

Problem:  None of the review points from the OPS-DIR QA review have been
addressed 

Recommended solution: The authors should consider these suggestions and
address his 3 points. 

 

Issue 4: 

Source: Victoria Pritchard QA review concern

Problem: RTG-QA review issue 7

2.1.5 

The SRMS Preference TLV only contains the Preference value, so it was

unclear how this is linked to a mapping server? Is the mapping server some
other field in the message?

 

[KT response] The SRMS Preference TLV indicates the preference value for the
node NLRI that it is a part of when that node is a mapping server. One would
need to go through the referenced IGPs specs and likely the relevant SR
specs to understand the mapping server.

 

[Shepherd's comment: text in draft-ietf-spring-segment-routing-ldp-interop
states:  

   We introduce the definition of the Segment Routing Mapping Server

   (SRMS) which consists of an IGP (IS-IS, OSPF and OSPFv3) extension

   allowing an SR capable router to advertise mappings between prefixes

   and Segment Identifiers (SID).  The details on how the mappings are

   encoded and advertised are protocol specific and defined in

   [I-D.ietf-isis-segment-routing-extensions
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-0
8#ref-I-D.ietf-isis-segment-routing-extensions> ],

   [I-D.ietf-ospf-segment-routing-extensions
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-0
8#ref-I-D.ietf-ospf-segment-routing-extensions> ] and

   [I-D.ietf-ospf-ospfv3-segment-routing-extensions
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-0
8#ref-I-D.ietf-ospf-ospfv3-segment-routing-extensions> ].

 

   The SRMS function of a SR capable router allows distribution of

   mappings for prefixes not locally attached to the advertising router

   and therefore allows advertisement of mappings on behalf of non-SR

   capable routers.

 

I suggest this definition moves up to the segment routing draft
(draft-ietf-spring-segment-routing-16), then
draft-ietf-idr-bgp-ls-segment-routing-ext and
draft-ietf-spring-segment-routing-ldp-interop can utilize the draft.  In the
meantime, put a similar definition in this draft in section with a comment
that states it will disappear.    

 

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

 

Editorial issues 

 

Issue 1: explaining what capability architecture 

 

Source: from RTG-QA issue 5  (editorial) 

(5)2.1.2. The capabilities TLV "advertise the node's SR capabilities and its
Segment Routing Global Base (SRGB) range(s)", but the format diagram only
contains Segment ID information. What are the capabilities? Or does the
presence of this TLV indicate the capability?

 

[KT Response] The Capabilities are the SRGB and the flags carried in the
TLV.

Shepherd: A short explanation on why this is considered "capability" is in
order here.