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

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 11:14:45 -0400

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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 19 Oct 2018 17:09:40 +0000

Hi Sue,

Please check inline below.

From: Susan Hares <[email-masked]>
Sent: 19 October 2018 20:45
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Cc: 'John Scudder' <[email-masked]>
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).

[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.

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

Technical issue #3:

segment routing.

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.

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.

So, the statement needs to be augmented.
[KT] I would augment the text to include SR specific considerations and references.

Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 16:52:58 -0400

Ketan:

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

Sue 

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

Hi Sue,

Ketan:

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. 

[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:  

segment routing.    

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. 

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,  

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

[Sue2]:  Which references would you add? 

Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 16:59:26 -0400

Ketan:

You may want to pause a moment before editing. 

I see you sent potential text in email.   Let me review that text to see if
we are closer. 

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, October 19, 2018 4:53 PM
To: 'Ketan Talaulikar (ketant)'; [email-masked]
Subject: Re: [Idr] Shepherd's comment on
draft-ietf-idr-bgp-ls-segment-routing-ext-09

Ketan:

Sue 

Hi Sue,

Ketan:

I think you mean both.  

Technical issue #3:  

segment routing.    

due to misconfiguration. 

SR topology extensions. 

[Sue2]:  

 

Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 17:57:26 -0400

Ketan:

I look forward to receiving the next update for this draft today.  Let's get
some wider review in the IDR on your proposed additions to the security
text.   

Please add to the manageability section the need for developing Yang modules
for these features.  Since NETMOD, NETCONF and RTGWG are working as fast as
they can on basic issue for BGP models, please just put in the need for the
yang modules.  These yang modules should not hold up the publication of this
draft. 

Sue 

Sent: Friday, October 19, 2018 4:59 PM

Ketan:

Sue Hares 

Ketan:

Sue 

Hi Sue,

Ketan:

I think you mean both.  

Technical issue #3:  

segment routing.    

due to misconfiguration. 

SR topology extensions. 

[Sue2]:  

 

Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 20 Oct 2018 03:48:05 +0000

Hi Sue,

I've posted the draft version 10 which addresses all your comments in the thread below.

Thanks,
Ketan

From: Susan Hares <[email-masked]>
Sent: 20 October 2018 03:27
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Subject: RE: [Idr] Shepherd's comment on draft-ietf-idr-bgp-ls-segment-routing-ext-09

Ketan:

I look forward to receiving the next update for this draft today.  Let's get some wider review in the IDR on your proposed additions to the security text.

Please add to the manageability section the need for developing Yang modules for these features.  Since NETMOD, NETCONF and RTGWG are working as fast as they can on basic issue for BGP models, please just put in the need for the yang modules.  These yang modules should not hold up the publication of this draft.

Sue

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, October 19, 2018 4:59 PM
To: 'Ketan Talaulikar (ketant)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Shepherd's comment on draft-ietf-idr-bgp-ls-segment-routing-ext-09

Ketan:

I see you sent potential text in email.   Let me review that text to see if we are closer.

Sue Hares

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, October 19, 2018 4:53 PM
To: 'Ketan Talaulikar (ketant)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Shepherd's comment on draft-ietf-idr-bgp-ls-segment-routing-ext-09

Ketan:

Sue

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

Hi Sue,

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

Ketan:

[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:

segment routing.

due to misconfiguration.

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:

Susan Hares