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

["Susan Hares" <[e-mail]>]

Ketan:

 

Thank you for your response.  See my comments below in [Sue2]. 

 

Sue 

 

From: Ketan Talaulikar (ketant) [mailto:[e-mail]] 
Sent: Friday, October 19, 2018 1:10 PM
To: Susan Hares; [e-mail]
Cc: 'John Scudder'
Subject: RE: Shepherd's comment on
draft-ietf-idr-bgp-ls-segment-routing-ext-09

 

Hi Sue,

 

Please check inline below.

 

From: Susan Hares <[e-mail]> 
Sent: 19 October 2018 20:45
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
Cc: 'John Scudder' <[e-mail]>
Subject: Shepherd's comment on draft-ietf-idr-bgp-ls-segment-routing-ext-09

 

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.  

[KT] This draft does not introduce nor affect any NLRI encodings. It only
introduces new attribute TLVs. I will update the text to clarify this.

[Sue2]: Thank you for putting in this code. 

 

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?  

[KT] I will borrow that text, but note that these are just attribute TLVs
being introduced in this draft.

[Sue2]: The text in the draft makes it clear it is attributes, but you were
unclear above.  If you borrow the text, you will be fine.  

 

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. 

 

[KT] I did not quite follow this. 

 

There is no additional configuration required for this in BGP or BGP-LS. 

These are just new attributes from IGP being carried for node, links and
prefixes - they are simply additional topological information.  Their being
related to Segment Routing does not change anything as far as BGP or BGP-LS
is concerned. 

I would remove this section 5.1 & 5.2 since there is text at start of
section 5 which has the reference to the base RFC7752.

 

[Sue2]:  It is not just topology, it include the following things besides
topology:

a)      Each notes SR capabilities 

b)      SR Algorithm for calculating the topology, 

c)       SR global base ranges, and  

d)      SR local block ranges. 

These go beyond sending RFC7752 IGP topology information in 

BGP.   Please indicate what configuration causes you to send 

SR topology extensions. 

 

Potential changes:  Nodes configured for Segment routing information

send this information.  For use cases see ____ spring drafts. 

Fill in the blank with the correct spring. 

 

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. 

 

[KT] There is no change with configuration, or provisioning or management
here as far as BGP or BGP-LS operations are concerned besides what is in the
base RFC7752.

[Sue2]:  

See my answer to technical issue #3 as to your expansion. 

 <https://tools.ietf.org/html/draft-ietf-spring-sr-yang-09>
https://tools.ietf.org/html/draft-ietf-spring-sr-yang-09

 

has yang module for IGPs.  May I politely suggest 

that you should extend the BGP yang module with 

an augmentation for the BGP configuration

for Segment routing.   If nothing else,  

 

 

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. 

[KT] I would augment the text to include SR specific considerations and
references.

[Sue2]:  Which references would you add? 

 

Resolution suggestion:  You can state this draft 

assumes a RFC7752bis that deals with these

drafts in a global manner. 

 

Susan Hares