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

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Oct 2018 18:14:27 -0400

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. 

Tightening this text will reduce the number 

of questions by implementers and IESG reviewers. 

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

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

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.  

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?   

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. 

Susan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 19 Oct 2018 08:44:22 +0000

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 <[email-masked]>
Sent: 19 October 2018 03:44
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Cc: 'John Scudder' <[email-masked]>
Subject: Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

Ketan:

Susan

---------

[KT] Will update.

2)     Section 8

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

3)  Section 9

Technical concern 1:

1)     Dropped silently,

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.

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

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.

Editorial issues:
topology information..."

How about

[KT] Corrected.

Thanks,
Ketan

Susan

---

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

Ketan:

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

Sue 

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

Hi Sue,

 

Ketan:

Susan 

---------

[KT] Will update..

[Sue] Thank you

2)     Section 8

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

3)  Section 9 

Technical concern 1: 

Information to be:

1)     Dropped silently, 

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.

applying to this draft.  

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

mis-routing of traffic.   

Is caused by BGP-EPE?   

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. 

Editorial issues: 

topology information." 

How about 

[KT] Corrected.

Thanks,

Ketan

Susan

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Oct 2018 15:37:34 +0200

Hi Sue,

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

Is your intention to "document" the fate sharing issue or solve it ?

If this is about documenting obvious then sure new draft can be spinned
over weekend.

If this is however about solving the issue I recommend we adopt BGP
Transport Instance draft to WG status and move BGP-LS to simply use new TCP
port making it at least at the TCP session level fully independent from
other SAFIs.

Ref: https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

Thx,
R.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 19 Oct 2018 14:01:48 +0000

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 <[email-masked]>
Sent: 19 October 2018 18:37
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Subject: RE: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

Ketan:

Sue

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

Hi Sue,

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

Ketan:

Susan

---------

[Sue] Thank you

2)     Section 8

[KT] Done.

3)  Section 9

Technical concern 1:

1)     Dropped silently,

3)     Drop the session

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

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

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

Editorial issues:

How about

Thanks,
Ketan

Susan

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 19 Oct 2018 14:05:03 +0000

Hi Sue, Robert,
I don’t think we need to gate all the extant BGP-LS drafts on the completion of this new work improving the RFC 7752 considerations. I agree that it would be useful.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, October 19, 2018 at 9:38 AM
To: Susan Hares <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

Hi Sue,

If this is about documenting obvious then sure new draft can be spinned over weekend.

If this is however about solving the issue I recommend we adopt BGP Transport Instance draft to WG status and move BGP-LS to simply use new TCP port making it at least at the TCP session level fully independent from other SAFIs.

Thx,
R.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 10:10:41 -0400

Acee:

Thank you for your feedback on the bis and the ordering of the drafts. 

Sue 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Friday, October 19, 2018 10:05 AM
To: Robert Raszuk; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

Hi Sue, Robert,

Thanks,

Acee

Hi Sue,

Thx,

R.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 10:27:00 -0400

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:[email-masked]] On Behalf Of Ketan Talaulikar
(ketant)
Sent: Friday, October 19, 2018 10:02 AM
To: Susan Hares; [email-masked]
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

Hi Sue,

Thanks,

Ketan

Ketan:

Sue 

Hi Sue,

 

Ketan:

Susan 

---------

[KT] Will update...

[Sue2] Thank you

2)     Section 8

[KT] When I looked at

[KT] Done.

[sue2] thank you for addressing these comments. 

3)  Section 9 

Technical concern 1: 

Information to be:

1)     Dropped silently, 

Placed in the log, 

3)     Drop the session

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

Thank you for addressing this issue. 

applying to this draft.  

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

mis-routing of traffic.   

Is caused by BGP-EPE?   

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: 

topology information." 

How about 

[KT] Corrected.

[Sue2] thank you for fixing this editorial issue. 

Thanks,

Ketan

Susan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 19 Oct 2018 14:34:31 +0000

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 <[email-masked]>
Sent: 19 October 2018 19:57
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
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

Hi Sue,

Thanks,
Ketan

Ketan:

Sue

Hi Sue,

Ketan:

Susan

---------

[Sue2] Thank you

2)     Section 8

3)  Section 9

Technical concern 1:

1)     Dropped silently,

3)     Drop the session

Editorial issues:

How about

Susan

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 10:40:03 -0400

Ketan: 

Thank you for posting the -17 draft.   

The text has some significant editorial changes.  We'll do a 1 week WG
review of editorial changes.  I will also ask Alvaro to do an early AD
review of the changes and the 7752bis issue. 

Sue 

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

Hi Sue,

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

Ketan:

Sue 

Hi Sue,

Thanks,

Ketan

Ketan:

Sue 

Hi Sue,

 

Ketan:

Susan 

---------

[KT] Will update....

[Sue2] Thank you

2)     Section 8

[KT] When I looked at

[KT] Done.

3)  Section 9 

Technical concern 1: 

Information to be:

1)     Dropped silently, 

Placed in the log, 

3)     Drop the session

applying to this draft.  

mis-routing of traffic.   

Is caused by BGP-EPE?   

SR-v6 case. 

Editorial issues: 

topology information." 

How about 

[KT] Corrected.

Thanks,

Ketan

Susan

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 10:41:10 -0400

Ketan: 

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

Sue 

Hi Sue,

Thanks,

Ketan

Ketan:

Sue 

Hi Sue,

Thanks,

Ketan

Ketan:

Sue 

Hi Sue,

 

Ketan:

Susan 

---------

[KT] Will update....

[Sue2] Thank you

2)     Section 8

[KT] When I looked at

[KT] Done.

3)  Section 9 

Technical concern 1: 

Information to be:

1)     Dropped silently, 

Placed in the log, 

3)     Drop the session

applying to this draft.  

mis-routing of traffic.   

Is caused by BGP-EPE?   

SR-v6 case. 

Editorial issues: 

topology information." 

How about 

[KT] Corrected.

Thanks,

Ketan

Susan

---

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

Hi Sue,

I believe we still have some work to do on that document before bringing it up for adoption.

Thanks,
Ketan

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

Ketan:

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

Sue

Hi Sue,

Thanks,
Ketan

Ketan:

Sue

Hi Sue,

Thanks,
Ketan

Ketan:

Sue

Hi Sue,

Ketan:

Susan

---------

[Sue2] Thank you

2)     Section 8

3)  Section 9

Technical concern 1:

1)     Dropped silently,

3)     Drop the session

Editorial issues:

How about

Susan

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 10:35:54 -0400

Robert: 

My understanding is that you wish me to do a WG adoption call for the following draft: 

https://tools..ietf.org/html/draft-raszuk-ti-bgp-01 <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01> 

I will review the draft for an adoption call later today.  You will need to present at the IDR interim so that the IDR WG can ask questions. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, October 19, 2018 10:11 AM
To: 'Acee Lindem (acee)'; 'Robert Raszuk'
Cc: [email-masked]
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

Acee:

Sue 

Hi Sue, Robert,

Thanks,

Acee

Hi Sue,

Ref: https://tools..ietf.org/html/draft-raszuk-ti-bgp-01 <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01> 

Thx,

R.