[Idr] Shepherd's comment on draft-ietf-idr-bgp-ls-segment-routing-ext-09

"Susan Hares" <shares@ndzh.com> Fri, 19 October 2018 15:14 UTC

From: Susan Hares <shares@ndzh.com>
To: "'Ketan Talaulikar (ketant)'" <ketant@cisco.com>, idr@ietf.org
Date: Fri, 19 Oct 2018 11:14:45 -0400
Message-ID: <01c001d467be$78606f20$69214d60$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C1_01D4679C.F14FE090"
Thread-Index: AdRnuisWxEtXcKIJQRaUqZR9Lc83EQ==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VFdxq-OGXNJwET_1at1EaHa8cyE>
Subject: [Idr] Shepherd's comment on draft-ietf-idr-bgp-ls-segment-routing-ext-09
Precedence: list

Ketan:

 

Thank you for addressing many of my issues in regarding
draft-ietf-idr-bgp-ls-segment-routing-ext-09.   The malformed TLV errors
appeared to be addressed. 

 

The following technical issues still remain in sections 5 (manageability)
and section 6 (security).  

 

Technical/editorial  issue 1:

 In Section 5 Manageability:  

Your text mixes malformed TLVs in NLRI and attributes.  

Please clean up the text.  I believe you mean the malformed TLVs

can be in either NLRIs or attributes, but the new text is unclear. 

I think you mean both.  

 

Technical issues 2:  What happens if the semantic or content 

Checking for the TLVS specified in the document finds an error? 

 

You can borrow the text from draft-ietf-idr-bgpls-segment-routing-epe, 

But please make it specific to what happens if the NLRI TLVs are broken or 

Attribute TLVs are broken.   On the NLRI TLVs, what gets tossed? 

On the Attribute TLVs, does the whole attribute get tossed?  

 

Technical issue #3:  

5.1 Operational Considerations 

Please add additional information to indicate: 

a)      Please indicate what policy is normal to support these extensions to


segment routing.    

b)      Please indicate how the operator will know if there are errors

due to misconfiguration. 

 

Technical issue #4: Management considerations 

 Three types of error exist:  software errors, configuration errors, 

and attacks.  The operator needs to have logging information or 

management parameters to track this. 

 

The BGP Yang models are a good place to put management parameters to 

track errors.  The logs are a good place to put the error messages while 

you wait for BGP Yang modules.  

 

For security attacks, RFC7752bis will address security the attacks. 

 

Technical issue #5:  in Section  6. Security  

In my opinion as a shepherd, the statement in section 6 

is incorrect.  You are changing the information that the 

BGP security model for RFC7752 impacts. 

 

You are allowing the node to report on 

SR algorithms,  SR local block information, 

LAN adjacencies with BGP. 

This is not just the RFC7752 information and 

not BGP reachability or flow specification information. 

 

So, the statement needs to be augmented. 

 

Resolution suggestion:  You can state this draft 

assumes a RFC7752bis that deals with these

drafts in a global manner. 

 

Susan Hares

[Idr] Shepherd's comment on draft-ietf-idr-bgp-ls… Susan Hares
Re: [Idr] Shepherd's comment on draft-ietf-idr-bg… Ketan Talaulikar (ketant)
Re: [Idr] Shepherd's comment on draft-ietf-idr-bg… Susan Hares
Re: [Idr] Shepherd's comment on draft-ietf-idr-bg… Susan Hares
Re: [Idr] Shepherd's comment on draft-ietf-idr-bg… Susan Hares
Re: [Idr] Shepherd's comment on draft-ietf-idr-bg… Ketan Talaulikar (ketant)