Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

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

Ketan: 

 

One other issue, are we close to asking for WG adoption on
draft-dawra-idr-bgpls-srv6-ext?  

 

Sue 

 

From: Idr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar
(ketant)
Sent: Friday, October 19, 2018 10:35 AM
To: Susan Hares; [e-mail]
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

 

Hi Sue,

 

The draft version 17 just posted with all your comments addressed.

 

Note that the SRv6 EPE extensions are covered in
draft-dawra-idr-bgpls-srv6-ext and we will incorporate all these inputs into
it in due course.

 

Thanks,

Ketan

 

From: Susan Hares <[e-mail]> 
Sent: 19 October 2018 19:57
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
Subject: RE: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

 

Ketan:

 

Thank you for the response.  See my comments inline (Sue2, red).   I think
we have convergence on a set of solutions. 

 

Please watch for the next review on
draft-ietf-idr-bgp-ls-segment-routing-ext.  It's heading your way shortly.
If we could work on getting that draft revised today as well, it would be
helpful.  

 

Sue 

 

From: Idr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar
(ketant)
Sent: Friday, October 19, 2018 10:02 AM
To: Susan Hares; [e-mail]
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

 

Hi Sue,

 

Please check inline below.

 

I will post an update for the draft shortly based on the discussions here.

 

Thanks,

Ketan

 

From: Susan Hares <[e-mail]> 
Sent: 19 October 2018 18:37
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
Subject: RE: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

 

Ketan:

 

Thank you for the fast response.  See my comments below.

 

Sue 

 

From: Idr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar
(ketant)
Sent: Friday, October 19, 2018 4:44 AM
To: Susan Hares; [e-mail]
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

 

Hi Sue,

 

Thanks for your comments and please see inline below for responses.

 

I will post the draft with the updates once I get your confirmation.

 

 

From: Susan Hares <[e-mail]> 
Sent: 19 October 2018 03:44
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
Cc: 'John Scudder' <[e-mail]>
Subject: Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

 

Ketan:

 

This version of the draft fixes a number of the error 

However, a few of my comments were not addressed. 

 

Please address these concerns in section 4.4, 8, and 9. 

I'd like to resolve these quickly.  I working the weekend. 

 

Susan 

 

---------

 

1)     Section 4.4 flag field under figure 2. 

Please provide a name for the "other bits" in 

the flag field in the diagram for the flags in 

section 4.4 under the figure 2.   Also please 

put a figure number with the flag field. 

[KT] Will update....

 

Tightening this text will reduce the number 

of questions by implementers and IESG reviewers. 

 

[Sue2] Thank you

 

2)     Section 8

 

Where you have "assigned by IANA", I believe you 

should replace this with "Early allocation by IANA".    

Your section should have a note that this is replaced 

by the phrase "IANA assigned". 

[KT] When I looked at
https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml
for the codepoints introduced by this draft, I did not see any "TEMPORARY"
or expiry dates. That gave me an impression that these were actually
assigned and not early allocation. I will update as required once you
re-confirm.

 

[Sue] All standards specified codepoints are early allocation

Note the RFC drafts in the same registry. 

[KT] Done.

[sue2] thank you for addressing these comments. 

 

3)  Section 9 

 

Technical concern 1: 

Syntactic check are specified, 

and it is clearly stated that the consumer 

of the information must do the 

the semantic/content checking errors are 

 

This is a good step forward.  

 

What is not specified here is what happens

when there is the semantic/content checking 

errors (detected by the consumer).  

State something about what happens if the 

Consumer detects an semantic/content error.

Will the consumers detection cause the

Information to be:

1)     Dropped silently, 

2)     Dropped and an error message

Placed in the log, 

3)     Drop the session

[KT] I would propose the following text (though IMHO as with the next
comment, this would be something that applies generically to BGP-LS and not
just this specific draft):

The handling of semantic or content errors by the consumer would be dictated
by the nature of its application usage and hence is beyond the scope of this
document. It may be expected that an error detected in the NLRI descriptor
TLVs would result in that specific NLRI update being unusable and hence its
update to be discarded. While an error in Attribute TLVs would result in
only that specific attribute being discarded.

 

[Sue]: When the update is discarded or attributes are discarded, 

is it silent (no mention) or will it be flagged in an error log?  

Please add whether it is silent (no update to the log) and put this text in.


[KT] With logging and updated the text.

[Sue2] Just add this point and we are good to go. 

Thank you for addressing this issue. 

 

Technical issues #2: Isolation of RFC7752 

applying to this draft.  

 

What happens if the operators do not 

adhere to the isolate of the BGP-LS 

sessions? How does the operator 

detect the problem?  A little more must 

be included in this section.  

 

[KT] When isolation is not followed then the BGP-LS AFI/SAFI share fate with
the other MP BGP signaling. This can result in update churn or errors hit on
one would affect the other. The concern would be that BGP-LS topology churn
should not come in the way of the (MP) BGP routing updates and slow down
convergence. The session bring down due to an error notification due to some
error in BGP-LS encoding is also a likelihood. However, all of these are not
really specific to this BGP-LS extension and should be documented in general
for BGP-LS. I volunteer to help with that as a separate draft and putting
some text like this hear does not seem like a good idea.

 

[Sue] An additional draft is a fine way to handle this point as 

this problem does impact  all BGP-LS.  I like this approach. 

 

However, if you take this approach we will need to have this draft 

at a WG draft status before we can forward the other drafts to the 

IESG.   Can you spin this draft quickly?  I will be glad to review it 

and do a WG adoption call.  Can you get it done over the weekend? 

We can talk about it on the 26th. 

[KT] I think there are both manageability and security considerations
aspects. Do we want to do a bis draft or just and update which covers these
aspects. There has now been some experience with implementations and
deployment which would help clarify these aspects. I am not sure though that
it would be a matter of weekend work J

 

[Sue] Let's start this work.   Write the outline of

bis change and send me the results. 

I'll be glad to provide text and review this draft. 

 

Technical issue #3: BGP-EPE functionality 

Is a capability that can provide looping or 

mis-routing of traffic.   

 

This is an improvement over the past statement. 

How does the operator detect the problem 

Is caused by BGP-EPE?   

 

[KT] I would propose the following text:

Traffic counters corresponding to the MPLS label of the BGP Peering SID on
the router would indicate the traffic being forwarded based on the specific
EPE path. Monitoring these counters and the flows hitting the corresponding
MPLS forwarding entry would help identify issues, if any, with traffic
engineering over the EPE paths.

 

[Sue]: This text is fine for the MPLS case. 

You must add that similar IP forwarding counters would detect it for the

SR-v6 case. 

[KT] This draft only covers the SR-MPLS dataplane and SRv6 is covered in a
separate draft.

[Sue2]: State this draft only covers SR-MPLS. Indicate  

SR-v6 usage would need to define similar detection mechanisms. 

Thank you for addressing this issue. 

 

The second sentence provides a 

 

Editorial issues: 

"The new protocol extensions introduced herein augment the existing

topology information." 

 

How about 

"The new protocol extensions introduced described in this document 

augment the existing topology information" 

 

While "herein" is a part of the English language, it causes many 

readers to stumble.  Your previous text was better. 

[KT] Corrected.

[Sue2] thank you for fixing this editorial issue. 

Thanks,

Ketan

 

Susan