Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Boris Hassanov]

 Agree Jeff.
Thank you.
SY,Boris

On Friday, April 30, 2021, 11:46:36 PM GMT+3, Jeff Tantsura 
 wrote:  
 
 Boris/Ketan,

Traditionally, we have been using Wiki to track implementations status, let’s 
take the same approach here?

Thanks and have a great weekend
Cheers,JeffOn Apr 27, 2021, 10:48 PM -0700, Ketan Talaulikar (ketant) 
, wrote:


Hi Boris,

 

Thanks for your review and feedback.

 

Did you imply that we add an implementation status section in the draft? Or are 
you suggesting that the chairs poll for implementation and deployment status? I 
ask because the Implementation Status section is generally removed before 
publication as RFC.

 

Regarding implementation, I am aware of support for this draft in Cisco’s 
Routing products for many years now with multiple deployments. I am also aware 
of other vendor support & operator deployment. However, would request other WG 
members to respond/confirm.

 

Thanks,

Ketan

 

From: spring  On Behalf Of Boris Hassanov
Sent: 28 April 2021 02:43
To: spring@ietf.org; James Guichard 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

 

Hi James and all,

 

I read the draft and strongly support its publication as WG document. Very 
detailed, helpful and interesting document.

I would only add implementation status part because currently it is not easy to 
get such info about implementation details.

 

Thank you.

 

SY,

Boris

 

On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
 wrote:

 

 

Dear WG:

 

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

 

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

 

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

 

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread. 

 

Thanks!

 

Jim, Joel & Bruno

 
[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/  
 

 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
  ___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Jeff Tantsura]

Boris/Ketan,

Traditionally, we have been using Wiki to track implementations status, let’s 
take the same approach here?

Thanks and have a great weekend

Cheers,
Jeff
On Apr 27, 2021, 10:48 PM -0700, Ketan Talaulikar (ketant) 
, wrote:
> Hi Boris,
>
> Thanks for your review and feedback.
>
> Did you imply that we add an implementation status section in the draft? Or 
> are you suggesting that the chairs poll for implementation and deployment 
> status? I ask because the Implementation Status section is generally removed 
> before publication as RFC.
>
> Regarding implementation, I am aware of support for this draft in Cisco’s 
> Routing products for many years now with multiple deployments. I am also 
> aware of other vendor support & operator deployment. However, would request 
> other WG members to respond/confirm.
>
> Thanks,
> Ketan
>
> From: spring  On Behalf Of Boris Hassanov
> Sent: 28 April 2021 02:43
> To: spring@ietf.org; James Guichard 
> Cc: spring-cha...@ietf.org
> Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
>
> Hi James and all,
>
> I read the draft and strongly support its publication as WG document. Very 
> detailed, helpful and interesting document.
> I would only add implementation status part because currently it is not easy 
> to get such info about implementation details.
>
> Thank you.
>
> SY,
> Boris
>
> On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
>  wrote:
>
>
> Dear WG:
>
> This email starts a 2 week Working Group Last Call for 
> draft-ietf-spring-segment-routing-policy [1].
>
> Please read this document if you haven’t read the most recent version and 
> send your comments to the SPRING WG list no later than April 29th 2021.
>
> If you are raising a point which you expect will be specifically debated on 
> the mailing list, consider using a specific email/thread for this point.
>
> Lastly, if you are an author or contributors for this document please 
> response to the IPR call in the previous email thread.
>
> Thanks!
>
> Jim, Joel & Bruno
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Joel,

Authors, can you clarify whether it would be accurate for Jim to report "there 
have been implementations for many years, and multiple interoperability tests" ?

KT> Yes

Thanks,
Ketan

-Original Message-
From: Joel M. Halpern  
Sent: 30 April 2021 22:27
To: Ketan Talaulikar (ketant) ; Boris Hassanov 
; spring@ietf.org; James Guichard 

Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

It would seem very strange to add an implementation section at WGLC, since by 
IETF policy they are removed before RFC publication.  (For context, the driving 
reason for removal is that they inherently become
obsolete.)

It is reasonable to include comments on implementation in the shepherd writeup. 
 That has to be short.  Authors, can you clarify whether it would be accurate 
for Jim to report "there have been implementations for many years, and multiple 
interoperability tests" ?

Thank you,
Joel

On 4/30/2021 12:12 PM, Ketan Talaulikar (ketant) wrote:
> Hi Boris,
> 
> I will leave it the chair/shepherd guidance on this one.
> 
> EANTC has been running multi-vendor interop for Segment Routing that 
> covers this document along with signalling protocols like PCEP and 
> BGP-SRTE every year since at least 2016. It includes various 
> controller and router products. Their results are published in 
> whitepapers which might perhaps provide at least some of the information that 
> you are looking.
> 
> Thanks,
> 
> Ketan
> 
> *From:*Boris Hassanov 
> *Sent:* 30 April 2021 20:49
> *To:* spring@ietf.org; James Guichard 
> ; Ketan Talaulikar (ketant) 
> 
> *Cc:* spring-cha...@ietf.org
> *Subject:* Re: [spring] WGLC for 
> draft-ietf-spring-segment-routing-policy
> 
> Hi Ketan,
> 
> Yes, I meant an implementation status section in the draft.
> 
> The either one way, which will be easier to accomplish. We need to fix 
> such status somewhere, IMO.
> 
> Thank you.
> 
> SY,
> 
> Boris
> 
> On Wednesday, April 28, 2021, 8:48:06 AM GMT+3, Ketan Talaulikar
> (ketant)  <mailto:ketant=40cisco@dmarc.ietf.org>> wrote:
> 
> Hi Boris,
> 
> Thanks for your review and feedback.
> 
> Did you imply that we add an add an implementation status section in 
> the draft?  Or are you suggesting that the chairs poll for 
> implementation and deployment status? I ask because the Implementation 
> Status section is generally removed before publication as RFC.
> 
> Regarding implementation, I am aware of support for this draft in 
> Cisco’s Routing products for many years now with multiple deployments. 
> I am also aware of other vendor support & operator deployment. 
> However, would request other WG members to respond/confirm.
> 
> Thanks,
> 
> Ketan
> 
> *From:*spring  <mailto:spring-boun...@ietf.org>> *On Behalf Of *Boris Hassanov
> *Sent:* 28 April 2021 02:43
> *To:* spring@ietf.org <mailto:spring@ietf.org>; James Guichard 
>  <mailto:james.n.guich...@futurewei.com>>
> *Cc:* spring-cha...@ietf.org <mailto:spring-cha...@ietf.org>
> *Subject:* Re: [spring] WGLC for 
> draft-ietf-spring-segment-routing-policy
> 
> Hi James and all,
> 
> I read the draft and strongly support its publication as WG document. 
> Very detailed, helpful and interesting document.
> 
> I would only add implementation status part because currently it is 
> not easy to get such info about implementation details.
> 
> Thank you.
> 
> SY,
> 
> Boris
> 
> On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
>  <mailto:james.n.guich...@futurewei.com>>
> wrote:
> 
> Dear WG:
> 
> This email starts a 2 week Working Group Last Call for 
> draft-ietf-spring-segment-routing-policy [1].
> 
> Please read this document if you haven’t read the most recent version 
> and send your comments to the SPRING WG list no later than April 29^th 
> 2021.
> 
> If you are raising a point which you expect will be specifically 
> debated on the mailing list, consider using a specific email/thread for this 
> point.
> 
> Lastly, if you are an author or contributors for this document please 
> response to the IPR call in the previous email thread.
> 
> Thanks!
> 
> Jim, Joel & Bruno
> 
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-pol
> icy/ 
> <https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-po
> licy/>
> 
> ___
> spring mailing list
> spring@ietf.org <mailto:spring@ietf.org> 
> https://www.ietf.org/mailman/listinfo/spring
> <https://www.ietf.org/mailman/listinfo/spring>
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Joel M. Halpern]

It would seem very strange to add an implementation section at WGLC, 
since by IETF policy they are removed before RFC publication.  (For 
context, the driving reason for removal is that they inherently become 
obsolete.)


It is reasonable to include comments on implementation in the shepherd 
writeup.  That has to be short.  Authors, can you clarify whether it 
would be accurate for Jim to report "there have been implementations for 
many years, and multiple interoperability tests" ?


Thank you,
Joel

On 4/30/2021 12:12 PM, Ketan Talaulikar (ketant) wrote:

Hi Boris,

I will leave it the chair/shepherd guidance on this one.

EANTC has been running multi-vendor interop for Segment Routing that 
covers this document along with signalling protocols like PCEP and 
BGP-SRTE every year since at least 2016. It includes various controller 
and router products. Their results are published in whitepapers which 
might perhaps provide at least some of the information that you are looking.


Thanks,

Ketan

*From:*Boris Hassanov 
*Sent:* 30 April 2021 20:49
*To:* spring@ietf.org; James Guichard ; 
Ketan Talaulikar (ketant) 

*Cc:* spring-cha...@ietf.org
*Subject:* Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan,

Yes, I meant an implementation status section in the draft.

The either one way, which will be easier to accomplish. We need to fix 
such status somewhere, IMO.


Thank you.

SY,

Boris

On Wednesday, April 28, 2021, 8:48:06 AM GMT+3, Ketan Talaulikar 
(ketant) <mailto:ketant=40cisco@dmarc.ietf.org>> wrote:


Hi Boris,

Thanks for your review and feedback.

Did you imply that we add an add an implementation status section in the 
draft?  Or are you suggesting that the chairs poll for implementation 
and deployment status? I ask because the Implementation Status section 
is generally removed before publication as RFC.


Regarding implementation, I am aware of support for this draft in 
Cisco’s Routing products for many years now with multiple deployments. I 
am also aware of other vendor support & operator deployment. However, 
would request other WG members to respond/confirm.


Thanks,

Ketan

*From:*spring mailto:spring-boun...@ietf.org>> 
*On Behalf Of *Boris Hassanov

*Sent:* 28 April 2021 02:43
*To:* spring@ietf.org <mailto:spring@ietf.org>; James Guichard 
mailto:james.n.guich...@futurewei.com>>

*Cc:* spring-cha...@ietf.org <mailto:spring-cha...@ietf.org>
*Subject:* Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi James and all,

I read the draft and strongly support its publication as WG document. 
Very detailed, helpful and interesting document.


I would only add implementation status part because currently it is not 
easy to get such info about implementation details.


Thank you.

SY,

Boris

On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
mailto:james.n.guich...@futurewei.com>> 
wrote:


Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].


Please read this document if you haven’t read the most recent version 
and send your comments to the SPRING WG list no later than April 29^th 
2021.


If you are raising a point which you expect will be specifically debated 
on the mailing list, consider using a specific email/thread for this point.


Lastly, if you are an author or contributors for this document please 
response to the IPR call in the previous email thread.


Thanks!

Jim, Joel & Bruno

[1] 
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ 
<https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/>


___
spring mailing list
spring@ietf.org <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring 
<https://www.ietf.org/mailman/listinfo/spring>




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Linda Dunbar]

 I have finished reading the draft-ietf-spring-segment-routing-policy-09. I 
think the draft is written very clear.

I support the WGLC.



Best Regards,

Linda Dunbar



On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:





Dear WG:



This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].



Please read this document if you haven't read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.



If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.



Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.



Thanks!



Jim, Joel & Bruno



[1] 
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/







___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Boris Hassanov]

 Hi Ketan,
Surely. Regarding EANTC, yes, I read those reports but there are no many such 
implementation details.
Thx.

SY,Boris
On Friday, April 30, 2021, 7:12:31 PM GMT+3, Ketan Talaulikar (ketant) 
 wrote:  
 
 #yiv3975518635 #yiv3975518635 -- _filtered {} _filtered {} _filtered {} 
_filtered {}#yiv3975518635 #yiv3975518635 p.yiv3975518635MsoNormal, 
#yiv3975518635 li.yiv3975518635MsoNormal, #yiv3975518635 
div.yiv3975518635MsoNormal 
{margin:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv3975518635 a:link, 
#yiv3975518635 span.yiv3975518635MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv3975518635 pre 
{margin:0cm;margin-bottom:.0001pt;font-size:10.0pt;}#yiv3975518635 
p.yiv3975518635ydp659101d9yiv3420978394msonormal, #yiv3975518635 
li.yiv3975518635ydp659101d9yiv3420978394msonormal, #yiv3975518635 
div.yiv3975518635ydp659101d9yiv3420978394msonormal 
{margin-right:0cm;margin-left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv3975518635
 p.yiv3975518635ydp659101d9yiv3420978394ydpe9939475yiv7878076663msonormal, 
#yiv3975518635 
li.yiv3975518635ydp659101d9yiv3420978394ydpe9939475yiv7878076663msonormal, 
#yiv3975518635 
div.yiv3975518635ydp659101d9yiv3420978394ydpe9939475yiv7878076663msonormal 
{margin-right:0cm;margin-left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv3975518635
 span.yiv3975518635HTMLPreformattedChar {font-family:Consolas;}#yiv3975518635 
span.yiv3975518635EmailStyle23 
{font-family:sans-serif;color:windowtext;}#yiv3975518635 
.yiv3975518635MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv3975518635 
div.yiv3975518635WordSection1 {}#yiv3975518635 
Hi Boris,
 
  
 
I will leave it the chair/shepherd guidance on this one.
 
  
 
EANTC has been running multi-vendor interop for Segment Routing that covers 
this document along with signalling protocols like PCEP and BGP-SRTE every year 
since at least 2016. It includes various controller and router products. Their 
results are published in whitepapers which might perhaps provide at least some 
of the information that you are looking.
 
  
 
Thanks,
 
Ketan
 
  
 
From: Boris Hassanov 
Sent: 30 April 2021 20:49
To: spring@ietf.org; James Guichard ; Ketan 
Talaulikar (ketant) 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
 
  
 
Hi Ketan,
 
  
 
Yes, I meant an implementation status section in the draft.
 
The either one way, which will be easier to accomplish. We need to fix such 
status somewhere, IMO.
 
  
 
Thank you.
 
  
 
SY,
 
Boris
 
  
 
On Wednesday, April 28, 2021, 8:48:06 AM GMT+3, Ketan Talaulikar (ketant) 
 wrote: 
 
  
 
  
 
Hi Boris,
 
 
 
Thanks for your review and feedback.
 
 
 
Did you imply that we add an add an implementation status section in the draft? 
 Or are you suggesting that the chairs poll for implementation and deployment 
status? I ask because the Implementation Status section is generally removed 
before publication as RFC.
 
 
 
Regarding implementation, I am aware of support for this draft in Cisco’s 
Routing products for many years now with multiple deployments. I am also aware 
of other vendor support & operator deployment. However, would request other WG 
members to respond/confirm.
 
 
 
Thanks,
 
Ketan
 
 
 
From: spring On Behalf Of Boris Hassanov
Sent: 28 April 2021 02:43
To: spring@ietf.org; James Guichard 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
 
 
 
Hi James and all,
 
 
 
I read the draft and strongly support its publication as WG document. Very 
detailed, helpful and interesting document.
 
I would only add implementation status part because currently it is not easy to 
get such info about implementation details.
 
 
 
Thank you.
 
 
 
SY,
 
Boris
 
 
 
On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
 wrote: 
 
 
 
 
 
Dear WG:
 
 
 
This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].
 
 
 
Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021. 
 
 
 
If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.
 
 
 
Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread. 
 
 
 
Thanks!
 
 
 
Jim, Joel & Bruno
 
 
 [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ 
   
 
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
   ___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Boris,

I will leave it the chair/shepherd guidance on this one.

EANTC has been running multi-vendor interop for Segment Routing that covers 
this document along with signalling protocols like PCEP and BGP-SRTE every year 
since at least 2016. It includes various controller and router products. Their 
results are published in whitepapers which might perhaps provide at least some 
of the information that you are looking.

Thanks,
Ketan

From: Boris Hassanov 
Sent: 30 April 2021 20:49
To: spring@ietf.org; James Guichard ; Ketan 
Talaulikar (ketant) 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan,

Yes, I meant an implementation status section in the draft.
The either one way, which will be easier to accomplish. We need to fix such 
status somewhere, IMO.

Thank you.

SY,
Boris

On Wednesday, April 28, 2021, 8:48:06 AM GMT+3, Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>> 
wrote:



Hi Boris,



Thanks for your review and feedback.


Did you imply that we add an add an implementation status section in the draft? 
 Or are you suggesting that the chairs poll for implementation and deployment 
status? I ask because the Implementation Status section is generally removed 
before publication as RFC.



Regarding implementation, I am aware of support for this draft in Cisco’s 
Routing products for many years now with multiple deployments. I am also aware 
of other vendor support & operator deployment. However, would request other WG 
members to respond/confirm.



Thanks,

Ketan



From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Boris Hassanov
Sent: 28 April 2021 02:43
To: spring@ietf.org<mailto:spring@ietf.org>; James Guichard 
mailto:james.n.guich...@futurewei.com>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy



Hi James and all,



I read the draft and strongly support its publication as WG document. Very 
detailed, helpful and interesting document.

I would only add implementation status part because currently it is not easy to 
get such info about implementation details.



Thank you.



SY,

Boris



On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:





Dear WG:



This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].



Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.



If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.



Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.



Thanks!



Jim, Joel & Bruno



[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/







___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Boris Hassanov]

 Hi Ketan,
Yes, I meant an implementation status section in the draft.
The either one way, which will be easier to accomplish. We need to fix such 
status somewhere, IMO.
Thank you.
SY,Boris

On Wednesday, April 28, 2021, 8:48:06 AM GMT+3, Ketan Talaulikar (ketant) 
 wrote:  
 
 
Hi Boris,
 
  
 
Thanks for your review and feedback.
 
  
 Did you imply that we add an add an implementation status section in the 
draft?  Or are you suggesting that the chairs poll for implementation and 
deployment status? I ask because the Implementation Status section is generally 
removed before publication as RFC. 
  
 
Regarding implementation, I am aware of support for this draft in Cisco’s 
Routing products for many years now with multiple deployments. I am also aware 
of other vendor support & operator deployment. However, would request other WG 
members to respond/confirm.
 
  
 
Thanks,
 
Ketan
 
  
 
From: spring On Behalf Of Boris Hassanov
Sent: 28 April 2021 02:43
To: spring@ietf.org; James Guichard 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
 
  
 
Hi James and all,
 
  
 
I read the draft and strongly support its publication as WG document. Very 
detailed, helpful and interesting document.
 
I would only add implementation status part because currently it is not easy to 
get such info about implementation details.
 
  
 
Thank you.
 
  
 
SY,
 
Boris
 
  
 
On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
 wrote:
 
  
 
  
 
Dear WG:
 
 
 
This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].
 
 
 
Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021. 
 
 
 
If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.
 
 
 
Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.
 
 
 
Thanks!
 
 
 
Jim, Joel & Bruno
 
 
 [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ 
   
 
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
   ___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Dhruv,

Just a follow-up as I was addressing Gyan’s comments. The additional 
considerations and details that you were looking for – was it for 
implementation and deployment aspects (rather than specifically security & 
manageability)?

We have a separate draft that carries some details which contains text that was 
part of this document in an earlier version : 
https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-07

It has been removed as it was purely informational and in some cases getting 
into implementation specifics.

Thanks,
Ketan

From: Ketan Talaulikar (ketant)
Sent: 30 April 2021 12:55
To: Dhruv Dhody 
Cc: James Guichard ; spring@ietf.org; 
spring-cha...@ietf.org
Subject: RE: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Dhruv,

Please check inline below.

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Sent: 30 April 2021 11:43
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: James Guichard 
mailto:james.n.guich...@futurewei.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan

Thanks for handling the comments. Just a final comment on the 
security/manageability considerations that explains my reasoning. I would let 
you/shepherd take a call!

This draft describes the SR Policy with a common informational model which has 
proven to be quite useful.
[KT] Agree.

I would like to see this approach extended to also capture the security and 
manageability aspects in a protocol-agnostic way.
[KT] Most of the considerations are covered by the base RFC8402. The security 
of the mechanism used between a controller and router is protocol specific. 
Same goes for the manageability aspect outside of the common YANG model. 
Perhaps it would help if there is some text proposal for us to evaluate or at 
least please point specific points that we should try to cover.

The configuration of SR policy, the verification rules, SR-DB handling, various 
policies that control active path selection, are all common and should be 
listed in this I-D.
[KT] Those aspects are covered by the draft already. Please do let know if any 
specific points that need inclusion.

You could also give clear requirements for the protocols to build on.
[KT] When it comes to the model and general things, yes. But there will be 
differences in protocols themselves.

There have been cases where the protocols have differed leading to issues. 
Having a section in this I-D that lays out clearly for protocols would be 
useful.
[KT] I want to make sure here that we are still talking about security and 
manageability? Or is there any other specific aspect?

As the work is distributed across WG, IMHO having a SPRING WG consensus on such 
a text would be nice.
[KT] Another aspect is a lot of the key protocol work is in fairly advance 
stages. We already have some PCEP specs published while others are quite mature 
with implementations and deployments. The BGP SRTE is also implemented and 
deployed – hopefully it gets into WGLC right after this. So we need to also 
look at the timing aspects for the specific points that we would like to see 
added.

Thanks,
Ketan

Just my 2 paisa :)
Stay Safe!

Thanks!
Dhruv


On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Dhruv,

Please check inline below.

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Sent: 29 April 2021 15:46
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: James Guichard 
mailto:james.n.guich...@futurewei.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan,

Thanks for the discussion. Sniping to -


If a node is identified by multiple addresses, from the point of view of the SR 
policy they would be considered as different nodes, correct?
[KT] This relates to the computation of SR Policy which is outside the scope of 
this document. There was some text around computation aspects in an earlier 
version of the draft that has been moved into 
draft-filsfils-spring-sr-policy-considerations around the WG adoption time. To 
answer your question, the endpoint address can be mapped to a node which 
becomes the tail-end and then path is computed to that node. In that case, 
multiple addresses may all map to a single node. This would be an 
implementation aspect.

[Dhruv]: I was thinking from the SR policy identification point of view, i.e. 
 and  will be considered as 
different SR policies even though H1-IP1 and H1-IP2 belong to the same headend 
H1.
[KT] Yes, they would be different SR Policies.


- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there an 
existing registry that is used here? Is it - 
https://datatracker.ietf.or

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Gyan,

Thanks for your review and the detailed feedback/comments. Will address your 
comments in the upcoming updated and let me try to summarize the 
changes/responses below:


  1.  The SR Policy computation can use/leverage the Flex-Algo SIDs when they 
meets the requirements. There used to be text in an earlier version of this 
document which was taken out and put into a separate draft since it was purely 
informational in nature. The authors got the feedback/guidance from the chairs 
to move it into a separate document. Can you please check and see if the text 
here is what you were looking for ? 
https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-07#section-7


  1.  Sec 9.3. You are right that there is no signalling involved and so it is 
different. This is about path protection and since the only state is on the SR 
source node, it alone needs to have a backup CP ready and programmed in the h/w 
to get activated when a failure is detected by the SR Source Node itself (via 
say BFD monitoring) on the primary CP. If your point was that this backup CP 
can be setup with the desired intent in mind, then yes I agree and I will 
clarify that in the text.



  1.  On the abstract and intro, thanks for bringing out the point that the 
“per-flow” term may have different interpretations. Here we are talking about 
SR paths and so actually, we are talking about using source routing to 
eliminate the “per-path” state in the intermediate nodes. I will clarify that 
in the text. I am not proposing to use “intermediate node control plane state” 
since it can be misinterpreted to include a lot of things – even the IGP Prefix 
and Adjacency SIDs are new states being introduced (however they are not 
per-path).



  1.  On the abstract and intro, a lot of the details are actually covered in 
the RFC8402 and so I am going to clarify that in the text and update specific 
pointer to that.



  1.  For the data-plane things, thanks for pointing out. I’ve updated 
references to the specs RFC8660, RFC8754 and RFC8986 where those aspects are 
covered.



  1.  Sec 2. That line/text is a reminder from RFC8402. The segment can be 
associated with a topological or service instruction and therefore it would not 
be right to just limit to prefix segment.



Thanks again for your review and will be posting an updated version to address 
your comments along with others received during this WGLC.

Thanks,
Ketan

From: Gyan Mishra 
Sent: 30 April 2021 13:01
To: Dhruv Dhody 
Cc: James Guichard ; Ketan Talaulikar (ketant) 
; spring-cha...@ietf.org; spring@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear Authors

As Flex Algo specification must be used over SR data plane architecture I think 
a section should be added related to flex Algo interaction with SR policy. It 
may have been mentioned but I didn’t notice it.

Also in section 9.3 so as I understand we are using the backup path for FRR 
path protection.  How the fast 50ms failover restoration can occur is that its 
intent based and no PCALC signaling RSVP FRR like make before break signaling 
so the path does not have to be pre built as it cannot be pre built technically 
as their is no intermediate node state and all state is “intent based” on the 
SR source node when the packet per flow hits the source node.

 I don’t think the backup path can be pre provisioned into the forwarding plane 
as their is no state on the intermediate nodes.


I am not sure if below is accurate.

“ The headend MAY compute a-priori and validate such backup candidate

   paths as well as provision them into the forwarding plane as a backup

   for the active path.  A fast re-route mechanism MAY then be used to

   trigger sub 50msec switchover from the active to the backup candidate

   path in the forwarding plane.  Mechanisms like BFD MAY be used for

   fast detection of such failures.”

https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/15/


Kind Regards

Gyan

On Fri, Apr 30, 2021 at 3:15 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:

Dear Authors

In the Abstract and Introduction you could say that the intermediate node 
control plane state maintenance is eliminated as now the same functionality of 
a label binding is now provided with IGP SR extension per SR architecture.


Kind Regards

Gyan

On Fri, Apr 30, 2021 at 3:06 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
Dear WG Authors

This draft is very well written and I support publication.

Few minor comments

Abstract and Introduction

I would reword “ Intermediate per-flow states are eliminated thanks to source 
routing.”

I would reword saying the header of a packet is steered into an SR policy as 
it’s the entire packet including overlay payload and not just the header.  Also 
saying that intermediate per flow state is eliminated is not accurate even 
though RFC 8402 does state so it’s not accurate.  So the concept of “per fl

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Gyan Mishra]

think having both examples and taking into account both throughout
>> the draft for consistency and also to ensure nothing technical get
>> overlooked in the specification.
>>
>> NEW Abstract
>>
>>Segment Routing (SR) allows a headend node to steer a packet flow
>>along any path.  Intermediate node control plane signaling is eliminated
>>by source routing.  The headend node can now steer any discrete flow into 
>> an
>>
>>instantiated SR Policy path.
>>
>>The per flow packets are now steered into an SR Policy made up of an
>>ordered list of transport topological segments .  This
>>document details the forwarding plane concepts of SR Policy and per flow 
>> steering into an SR
>>Policy explicit path.
>>
>>
>> Section 2 minor typo
>>
>> An instruction is a segment so I think you meant binding of the
>> topological SID instructions advertised in the IGP extension is what is
>> bound to the prefix FEC binding in the case of MPLS
>> data plane and SRv6 a binding.
>>
>> OLD
>>
>>The Segment Routing architecture.
>>
>> [RFC8402 <https://tools.ietf.org/html/rfc8402>] specifies that any
>>instruction can be bound to a segment.  Thus, an SR Policy can be
>>built using any type of Segment Identifier (SID) including those
>>associated with topological or service instructions.
>>
>>
>> NEW
>>
>>
>> The Segment Routing architecture [RFC8402 
>> <https://tools.ietf.org/html/rfc8402>] specifies that any
>>Prefix can be bound to a segment.  Thus, an SR Policy can be
>>built using any type of Segment Identifier (SID) including those
>>associated with topological or service instructions.
>>
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Fri, Apr 30, 2021 at 2:13 AM Dhruv Dhody  wrote:
>>
>>> Hi Ketan
>>>
>>> Thanks for handling the comments. Just a final comment on the
>>> security/manageability considerations that explains my reasoning. I would
>>> let you/shepherd take a call!
>>>
>>> This draft describes the SR Policy with a common informational model
>>> which has proven to be quite useful. I would like to see this approach
>>> extended to also capture the security and manageability aspects in a
>>> protocol-agnostic way. The configuration of SR policy, the verification
>>> rules, SR-DB handling, various policies that control active path selection,
>>> are all common and should be listed in this I-D. You could also give clear
>>> requirements for the protocols to build on. There have been cases where the
>>> protocols have differed leading to issues. Having a section in this I-D
>>> that lays out clearly for protocols would be useful. As the work is
>>> distributed across WG, IMHO having a SPRING WG consensus on such a text
>>> would be nice.
>>>
>>> Just my 2 paisa :)
>>> Stay Safe!
>>>
>>> Thanks!
>>> Dhruv
>>>
>>>
>>> On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) <
>>> ket...@cisco.com> wrote:
>>>
>>>> Hi Dhruv,
>>>>
>>>>
>>>>
>>>> Please check inline below.
>>>>
>>>>
>>>>
>>>> *From:* Dhruv Dhody 
>>>> *Sent:* 29 April 2021 15:46
>>>> *To:* Ketan Talaulikar (ketant) 
>>>> *Cc:* James Guichard ; spring@ietf.org;
>>>> spring-cha...@ietf.org
>>>> *Subject:* Re: [spring] WGLC for
>>>> draft-ietf-spring-segment-routing-policy
>>>>
>>>>
>>>>
>>>> Hi Ketan,
>>>>
>>>>
>>>>
>>>> Thanks for the discussion. Sniping to -
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> If a node is identified by multiple addresses, from the point of view
>>>> of the SR policy they would be considered as different nodes, correct?
>>>>
>>>> *[KT] This relates to the computation of SR Policy which is outside the
>>>> scope of this document. There was some text around computation aspects in
>>>> an earlier version of the draft that has been moved into
>>>> draft-filsfils-spring-sr-policy-considerations around the WG adoption time.
>>>> To answer your question, the endpoint address can be mapped to a node which
>>>> becomes the tail-end and then path is computed to that node. In that case,
>>>> multipl

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Dhruv,

Please check inline below.

From: Dhruv Dhody 
Sent: 30 April 2021 11:43
To: Ketan Talaulikar (ketant) 
Cc: James Guichard ; spring@ietf.org; 
spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan

Thanks for handling the comments. Just a final comment on the 
security/manageability considerations that explains my reasoning. I would let 
you/shepherd take a call!

This draft describes the SR Policy with a common informational model which has 
proven to be quite useful.
[KT] Agree.

I would like to see this approach extended to also capture the security and 
manageability aspects in a protocol-agnostic way.
[KT] Most of the considerations are covered by the base RFC8402. The security 
of the mechanism used between a controller and router is protocol specific. 
Same goes for the manageability aspect outside of the common YANG model. 
Perhaps it would help if there is some text proposal for us to evaluate or at 
least please point specific points that we should try to cover.

The configuration of SR policy, the verification rules, SR-DB handling, various 
policies that control active path selection, are all common and should be 
listed in this I-D.
[KT] Those aspects are covered by the draft already. Please do let know if any 
specific points that need inclusion.

You could also give clear requirements for the protocols to build on.
[KT] When it comes to the model and general things, yes. But there will be 
differences in protocols themselves.

There have been cases where the protocols have differed leading to issues. 
Having a section in this I-D that lays out clearly for protocols would be 
useful.
[KT] I want to make sure here that we are still talking about security and 
manageability? Or is there any other specific aspect?

As the work is distributed across WG, IMHO having a SPRING WG consensus on such 
a text would be nice.
[KT] Another aspect is a lot of the key protocol work is in fairly advance 
stages. We already have some PCEP specs published while others are quite mature 
with implementations and deployments. The BGP SRTE is also implemented and 
deployed – hopefully it gets into WGLC right after this. So we need to also 
look at the timing aspects for the specific points that we would like to see 
added.

Thanks,
Ketan

Just my 2 paisa :)
Stay Safe!

Thanks!
Dhruv


On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Dhruv,

Please check inline below.

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Sent: 29 April 2021 15:46
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: James Guichard 
mailto:james.n.guich...@futurewei.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan,

Thanks for the discussion. Sniping to -


If a node is identified by multiple addresses, from the point of view of the SR 
policy they would be considered as different nodes, correct?
[KT] This relates to the computation of SR Policy which is outside the scope of 
this document. There was some text around computation aspects in an earlier 
version of the draft that has been moved into 
draft-filsfils-spring-sr-policy-considerations around the WG adoption time. To 
answer your question, the endpoint address can be mapped to a node which 
becomes the tail-end and then path is computed to that node. In that case, 
multiple addresses may all map to a single node. This would be an 
implementation aspect.

[Dhruv]: I was thinking from the SR policy identification point of view, i.e. 
 and  will be considered as 
different SR policies even though H1-IP1 and H1-IP2 belong to the same headend 
H1.
[KT] Yes, they would be different SR Policies.


- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there an 
existing registry that is used here? Is it - 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
 , should it be listed in this document perhaps?
[KT] These are not code points but suggested default values for the Priority 
assigned to each protocol. An implementation may use a completely different 
scheme and/or make theme configurable. I see that 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
 does not clearly indicate this and perhaps the authors should clarify that the 
Protocol Origin in that PCEP TLV is used to tweak/signal the Priority value to 
be used for that particular CP in the tiebreaker.


[Dhruv]: I am referring to this text -

   Protocol-Origin of a candidate path is an 8-bit value which
   identifies the component or protocol that originates or signals the
   candidate path.

Which says that an "8-bit value" identifies the protocol as PCEP, BGP, etc. 
What you are describing is the priority associated with t

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Gyan Mishra]

 Segment Identifier (SID) including those
>associated with topological or service instructions.
>
>
> Kind Regards
>
> Gyan
>
> On Fri, Apr 30, 2021 at 2:13 AM Dhruv Dhody  wrote:
>
>> Hi Ketan
>>
>> Thanks for handling the comments. Just a final comment on the
>> security/manageability considerations that explains my reasoning. I would
>> let you/shepherd take a call!
>>
>> This draft describes the SR Policy with a common informational model
>> which has proven to be quite useful. I would like to see this approach
>> extended to also capture the security and manageability aspects in a
>> protocol-agnostic way. The configuration of SR policy, the verification
>> rules, SR-DB handling, various policies that control active path selection,
>> are all common and should be listed in this I-D. You could also give clear
>> requirements for the protocols to build on. There have been cases where the
>> protocols have differed leading to issues. Having a section in this I-D
>> that lays out clearly for protocols would be useful. As the work is
>> distributed across WG, IMHO having a SPRING WG consensus on such a text
>> would be nice.
>>
>> Just my 2 paisa :)
>> Stay Safe!
>>
>> Thanks!
>> Dhruv
>>
>>
>> On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) <
>> ket...@cisco.com> wrote:
>>
>>> Hi Dhruv,
>>>
>>>
>>>
>>> Please check inline below.
>>>
>>>
>>>
>>> *From:* Dhruv Dhody 
>>> *Sent:* 29 April 2021 15:46
>>> *To:* Ketan Talaulikar (ketant) 
>>> *Cc:* James Guichard ; spring@ietf.org;
>>> spring-cha...@ietf.org
>>> *Subject:* Re: [spring] WGLC for
>>> draft-ietf-spring-segment-routing-policy
>>>
>>>
>>>
>>> Hi Ketan,
>>>
>>>
>>>
>>> Thanks for the discussion. Sniping to -
>>>
>>>
>>>
>>>
>>>
>>> If a node is identified by multiple addresses, from the point of view of
>>> the SR policy they would be considered as different nodes, correct?
>>>
>>> *[KT] This relates to the computation of SR Policy which is outside the
>>> scope of this document. There was some text around computation aspects in
>>> an earlier version of the draft that has been moved into
>>> draft-filsfils-spring-sr-policy-considerations around the WG adoption time.
>>> To answer your question, the endpoint address can be mapped to a node which
>>> becomes the tail-end and then path is computed to that node. In that case,
>>> multiple addresses may all map to a single node. This would be an
>>> implementation aspect.*
>>>
>>>
>>>
>>> [Dhruv]: I was thinking from the SR policy identification point of view,
>>> i.e.  and  will be
>>> considered as different SR policies even though H1-IP1 and H1-IP2 belong to
>>> the same headend H1.
>>>
>>> *[KT] Yes, they would be different SR Policies.*
>>>
>>>
>>>
>>>
>>> - Section 2.3, What are the 8-bit values for the Protocol-Origin, is
>>> there an existing registry that is used here? Is it -
>>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
>>> , should it be listed in this document perhaps?
>>>
>>> *[KT] These are not code points but suggested default values for the
>>> Priority assigned to each protocol. An implementation may use a completely
>>> different scheme and/or make theme configurable. I see that
>>> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2>
>>> does not clearly indicate this and perhaps the authors should clarify that
>>> the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority
>>> value to be used for that particular CP in the tiebreaker.*
>>>
>>>
>>>
>>>
>>> [Dhruv]: I am referring to this text -
>>>
>>>Protocol-Origin of a candidate path is an 8-bit value which
>>>identifies the component or protocol that originates or signals the
>>>candidate path.
>>>
>>> Which says that an "8-bit value" identifies the protocol as PCEP, BGP,
>>> etc. What you are describing is the priority associated with the
>>> protocol. I feel the term "Protocol-Origin" and &qu

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Gyan Mishra]

all common and should be listed in this I-D. You could also give clear
> requirements for the protocols to build on. There have been cases where the
> protocols have differed leading to issues. Having a section in this I-D
> that lays out clearly for protocols would be useful. As the work is
> distributed across WG, IMHO having a SPRING WG consensus on such a text
> would be nice.
>
> Just my 2 paisa :)
> Stay Safe!
>
> Thanks!
> Dhruv
>
>
> On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) <
> ket...@cisco.com> wrote:
>
>> Hi Dhruv,
>>
>>
>>
>> Please check inline below.
>>
>>
>>
>> *From:* Dhruv Dhody 
>> *Sent:* 29 April 2021 15:46
>> *To:* Ketan Talaulikar (ketant) 
>> *Cc:* James Guichard ; spring@ietf.org;
>> spring-cha...@ietf.org
>> *Subject:* Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
>>
>>
>>
>> Hi Ketan,
>>
>>
>>
>> Thanks for the discussion. Sniping to -
>>
>>
>>
>>
>>
>> If a node is identified by multiple addresses, from the point of view of
>> the SR policy they would be considered as different nodes, correct?
>>
>> *[KT] This relates to the computation of SR Policy which is outside the
>> scope of this document. There was some text around computation aspects in
>> an earlier version of the draft that has been moved into
>> draft-filsfils-spring-sr-policy-considerations around the WG adoption time.
>> To answer your question, the endpoint address can be mapped to a node which
>> becomes the tail-end and then path is computed to that node. In that case,
>> multiple addresses may all map to a single node. This would be an
>> implementation aspect.*
>>
>>
>>
>> [Dhruv]: I was thinking from the SR policy identification point of view,
>> i.e.  and  will be
>> considered as different SR policies even though H1-IP1 and H1-IP2 belong to
>> the same headend H1.
>>
>> *[KT] Yes, they would be different SR Policies.*
>>
>>
>>
>>
>> - Section 2.3, What are the 8-bit values for the Protocol-Origin, is
>> there an existing registry that is used here? Is it -
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
>> , should it be listed in this document perhaps?
>>
>> *[KT] These are not code points but suggested default values for the
>> Priority assigned to each protocol. An implementation may use a completely
>> different scheme and/or make theme configurable. I see that
>> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
>> <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2>
>> does not clearly indicate this and perhaps the authors should clarify that
>> the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority
>> value to be used for that particular CP in the tiebreaker.*
>>
>>
>>
>>
>> [Dhruv]: I am referring to this text -
>>
>>Protocol-Origin of a candidate path is an 8-bit value which
>>identifies the component or protocol that originates or signals the
>>candidate path.
>>
>> Which says that an "8-bit value" identifies the protocol as PCEP, BGP,
>> etc. What you are describing is the priority associated with the protocol.
>> I feel the term "Protocol-Origin" and "Protocol-Origin Priority" is used
>> interchangeably, leading to this misunderstanding.
>>
>> To confirm, in the example - Candidate-path CP1 > originator = 100:1.1.1.1, discriminator = 1>. The value 20 identify BGP or
>> the Priority value associated with BGP? I am assuming it is the
>> priority!
>>
>> In which case some cleanup of text is needed to make things clear.
>>
>> *[KT] I see your point. The use of “priority” and that too inconsistently
>> might be the cause for the confusion. Will clean-up the text around this.*
>>
>>
>>
>>
>> - Section 10, It might be a good idea to acknowledge security
>> considerations from the SR policy architecture point of view: how various
>> SR policy parameters and attributes could be exploited to make a headend to
>> forward the traffic incorrectly. It is better to add details that clearly
>> show that the authors/WG have given it a thought and analyzed the
>> implications.
>>
>> *[KT] As a reminder the SR Policy has been introduced in RFC8402 which
>> covers these aspects of incorrect routing and other challenges associated
>>

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Dhruv Dhody]

Hi Ketan

Thanks for handling the comments. Just a final comment on the
security/manageability considerations that explains my reasoning. I would
let you/shepherd take a call!

This draft describes the SR Policy with a common informational model which
has proven to be quite useful. I would like to see this approach extended
to also capture the security and manageability aspects in a
protocol-agnostic way. The configuration of SR policy, the verification
rules, SR-DB handling, various policies that control active path selection,
are all common and should be listed in this I-D. You could also give clear
requirements for the protocols to build on. There have been cases where the
protocols have differed leading to issues. Having a section in this I-D
that lays out clearly for protocols would be useful. As the work is
distributed across WG, IMHO having a SPRING WG consensus on such a text
would be nice.

Just my 2 paisa :)
Stay Safe!

Thanks!
Dhruv


On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) 
wrote:

> Hi Dhruv,
>
>
>
> Please check inline below.
>
>
>
> *From:* Dhruv Dhody 
> *Sent:* 29 April 2021 15:46
> *To:* Ketan Talaulikar (ketant) 
> *Cc:* James Guichard ; spring@ietf.org;
> spring-cha...@ietf.org
> *Subject:* Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
>
>
>
> Hi Ketan,
>
>
>
> Thanks for the discussion. Sniping to -
>
>
>
>
>
> If a node is identified by multiple addresses, from the point of view of
> the SR policy they would be considered as different nodes, correct?
>
> *[KT] This relates to the computation of SR Policy which is outside the
> scope of this document. There was some text around computation aspects in
> an earlier version of the draft that has been moved into
> draft-filsfils-spring-sr-policy-considerations around the WG adoption time.
> To answer your question, the endpoint address can be mapped to a node which
> becomes the tail-end and then path is computed to that node. In that case,
> multiple addresses may all map to a single node. This would be an
> implementation aspect.*
>
>
>
> [Dhruv]: I was thinking from the SR policy identification point of view,
> i.e.  and  will be
> considered as different SR policies even though H1-IP1 and H1-IP2 belong to
> the same headend H1.
>
> *[KT] Yes, they would be different SR Policies.*
>
>
>
>
> - Section 2.3, What are the 8-bit values for the Protocol-Origin, is there
> an existing registry that is used here? Is it -
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
> , should it be listed in this document perhaps?
>
> *[KT] These are not code points but suggested default values for the
> Priority assigned to each protocol. An implementation may use a completely
> different scheme and/or make theme configurable. I see that
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
> <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2>
> does not clearly indicate this and perhaps the authors should clarify that
> the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority
> value to be used for that particular CP in the tiebreaker.*
>
>
>
>
> [Dhruv]: I am referring to this text -
>
>Protocol-Origin of a candidate path is an 8-bit value which
>identifies the component or protocol that originates or signals the
>candidate path.
>
> Which says that an "8-bit value" identifies the protocol as PCEP, BGP,
> etc. What you are describing is the priority associated with the protocol.
> I feel the term "Protocol-Origin" and "Protocol-Origin Priority" is used
> interchangeably, leading to this misunderstanding.
>
> To confirm, in the example - Candidate-path CP1  originator = 100:1.1.1.1, discriminator = 1>. The value 20 identify BGP or
> the Priority value associated with BGP? I am assuming it is the priority!
>
> In which case some cleanup of text is needed to make things clear.
>
> *[KT] I see your point. The use of “priority” and that too inconsistently
> might be the cause for the confusion. Will clean-up the text around this.*
>
>
>
>
> - Section 10, It might be a good idea to acknowledge security
> considerations from the SR policy architecture point of view: how various
> SR policy parameters and attributes could be exploited to make a headend to
> forward the traffic incorrectly. It is better to add details that clearly
> show that the authors/WG have given it a thought and analyzed the
> implications.
>
> *[KT] As a reminder the SR Policy has been introduced in RFC8402 which
> covers these aspects of incorrect routing and other 

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Satoru Matsushima]

Thanks Ketan-san, yes it looks good to me.

Cheers,
--satoru

> On Apr 29, 2021, at 23:14, Ketan Talaulikar (ketant)  wrote:
> 
> 
> Hi Satoru-san,
>  
> Thanks for your review and comment.
>  
> I believe your point is to also cover SRv6 BSID and to that I would propose 
> the following text :
>  
> When the active candidate path has a specified BSID, the SR Policy uses that 
> BSID if this value (label in MPLS, IPv6 address in SRv6) is available (i.e., 
> not associated with any other usage: e.g. to another MPLS client, to another 
> SRv6 client, to another SID, to another SR Policy, outside the range of SRv6 
> Locators).
>  
> Thanks,
> Ketan
>  
> From: spring  On Behalf Of Satoru Matsushima
> Sent: 29 April 2021 18:36
> To: spring-cha...@ietf.org
> Cc: James Guichard ; spring@ietf.org
> Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
>  
> Hi spring chairs, 
>  
> I think that the document is ready to move forward.
>  
> Here one minor comment is bellow:
>  
> Section 6.2 says on BSID as follow:
>  
>When the active candidate path has a specified BSID, the SR Policy
>uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
>available (i.e., not associated with any other usage: e.g. to another
>MPLS client, to another SID, to another SR Policy).
>  
> My suggestion for that above text as follow:
>  
>When the active candidate path has a specified BSID, the SR Policy
>uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
>available (i.e., not associated with any other usage: e.g. to another
>MPLS client, to another SID, to another SR Policy, within the range of 
> locators in SRv6).
>  
> Best regards,
> --satoru
> 
> 
> On Apr 16, 2021, at 3:57, James Guichard  
> wrote:
> 
> 
> Dear WG:
>  
> This email starts a 2 week Working Group Last Call for 
> draft-ietf-spring-segment-routing-policy [1].
>  
> Please read this document if you haven’t read the most recent version and 
> send your comments to the SPRING WG list no later than April 29th 2021.
>  
> If you are raising a point which you expect will be specifically debated on 
> the mailing list, consider using a specific email/thread for this point.
>  
> Lastly, if you are an author or contributors for this document please 
> response to the IPR call in the previous email thread.
>  
> Thanks!
>  
> Jim, Joel & Bruno
>  
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>  
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Nandan Saha]

Hi WG, chairs,
 I support the publication of this draft. It's comprehensive and has
implementations that are deployed.

Thanks,
Nandan

On Thu, Apr 15, 2021 at 11:57 AM James Guichard <
james.n.guich...@futurewei.com> wrote:

> Dear WG:
>
>
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-spring-segment-routing-policy [1].
>
>
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SPRING WG list no later than April 29th 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributors for this document please
> response to the IPR call in the previous email thread.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Richard Vallee (rvallee)]

This is an important draft. I have reviewed the draft and believe it is ready 
for publication.

Many thanks for the authors and everyone helping to get that far.

Richard

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Matt Anderson]

After having read the first few revisions awhile back, duly impressed with
the scope, clarity, and utility of the document, I've read the latest draft
and support this document moving to publication.

On Thu, Apr 15, 2021 at 2:57 PM James Guichard <
james.n.guich...@futurewei.com> wrote:

> Dear WG:
>
>
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-spring-segment-routing-policy [1].
>
>
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SPRING WG list no later than April 29th 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributors for this document please
> response to the IPR call in the previous email thread.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>


-- 
Matt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Stone, Andrew (Nokia - CA/Ottawa)]

Looks good to me, thanks Ketan!

Andrew

From: "Ketan Talaulikar (ketant)" 
Date: Thursday, April 29, 2021 at 1:57 AM
To: "Stone, Andrew (Nokia - CA/Ottawa)" , James 
Guichard , "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: RE: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Andrew,

Thanks for your review and comments.

We can update that text to clarify as below:

When BGP SR Policy is the Protocol-Origin, the BGP process receiving the route 
provides the distinguisher (refer to Section 2.1 of 
[I-D.ietf-idr-segment-routing-te-policy]) as the discriminator.

I’ll also make the clarification on the role of the distinguisher in BGP SRTE 
in the draft-ietf-idr-segment-routing-te-policy of which I am also a co-author.

Thanks,
Ketan

From: spring  On Behalf Of Stone, Andrew (Nokia - 
CA/Ottawa)
Sent: 29 April 2021 11:12
To: James Guichard ; spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hello Chairs, WG and Authors

I think there may need to be a wording adjustment required to the BGP related 
text in section 2.5, for more clarity regarding the use of BGP distinguisher in 
place of discriminator:


   When BGP SR Policy is the Protocol-Origin, it is the distinguisher

   (refer to Section 2.1 of 
[I-D.ietf-idr-segment-routing-te-policy<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-10#ref-I-D.ietf-idr-segment-routing-te-policy>]).

The sentence seems to be focused on the context of a headend node importing SR 
policy from BGP into an SR Policy module, and could be interpreted differently 
(and incorrectly) when applied in the context of a controller defined SR Policy 
which is then injected into BGP. I have spoken to Ketan regarding this, so may 
be updated shortly. (additional clarification in idr document may also come).

Aside from that, I support WGLC adoption. The document describes the behaviour 
and associated contexts within the SR Policy model well, and it’s an important 
draft to have finalized.

Thanks
Andrew

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Kamran Raza (skraza)]

Looking at the latest rev of this important draft, I support the publication of 
it.
Rgds,
--
Kamran

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy
Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Satoru-san,

Thanks for your review and comment.

I believe your point is to also cover SRv6 BSID and to that I would propose the 
following text :

When the active candidate path has a specified BSID, the SR Policy uses that 
BSID if this value (label in MPLS, IPv6 address in SRv6) is available (i.e., 
not associated with any other usage: e.g. to another MPLS client, to another 
SRv6 client, to another SID, to another SR Policy, outside the range of SRv6 
Locators).

Thanks,
Ketan

From: spring  On Behalf Of Satoru Matsushima
Sent: 29 April 2021 18:36
To: spring-cha...@ietf.org
Cc: James Guichard ; spring@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi spring chairs,

I think that the document is ready to move forward.

Here one minor comment is bellow:

Section 6.2 says on BSID as follow:


   When the active candidate path has a specified BSID, the SR Policy

   uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is

   available (i.e., not associated with any other usage: e.g. to another

   MPLS client, to another SID, to another SR Policy).

My suggestion for that above text as follow:


   When the active candidate path has a specified BSID, the SR Policy

   uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is

   available (i.e., not associated with any other usage: e.g. to another

   MPLS client, to another SID, to another SR Policy, within the range of 
locators in SRv6).

Best regards,
--satoru


On Apr 16, 2021, at 3:57, James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Mike Koldychev (mkoldych)]

I have read the latest version of the document and I believe it is ready for 
publication. The document is very detailed and useful as it allows different 
implementations to follow the same information model for SR Policy.

Thanks,
Mike.

From: spring  On Behalf Of James Guichard
Sent: Thursday, April 15, 2021 2:57 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven't read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Dhruv,

Please check inline below.

From: Dhruv Dhody 
Sent: 29 April 2021 15:46
To: Ketan Talaulikar (ketant) 
Cc: James Guichard ; spring@ietf.org; 
spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan,

Thanks for the discussion. Sniping to -


If a node is identified by multiple addresses, from the point of view of the SR 
policy they would be considered as different nodes, correct?
[KT] This relates to the computation of SR Policy which is outside the scope of 
this document. There was some text around computation aspects in an earlier 
version of the draft that has been moved into 
draft-filsfils-spring-sr-policy-considerations around the WG adoption time. To 
answer your question, the endpoint address can be mapped to a node which 
becomes the tail-end and then path is computed to that node. In that case, 
multiple addresses may all map to a single node. This would be an 
implementation aspect.

[Dhruv]: I was thinking from the SR policy identification point of view, i.e. 
 and  will be considered as 
different SR policies even though H1-IP1 and H1-IP2 belong to the same headend 
H1.
[KT] Yes, they would be different SR Policies.


- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there an 
existing registry that is used here? Is it - 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
 , should it be listed in this document perhaps?
[KT] These are not code points but suggested default values for the Priority 
assigned to each protocol. An implementation may use a completely different 
scheme and/or make theme configurable. I see that 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
 does not clearly indicate this and perhaps the authors should clarify that the 
Protocol Origin in that PCEP TLV is used to tweak/signal the Priority value to 
be used for that particular CP in the tiebreaker.


[Dhruv]: I am referring to this text -

   Protocol-Origin of a candidate path is an 8-bit value which
   identifies the component or protocol that originates or signals the
   candidate path.

Which says that an "8-bit value" identifies the protocol as PCEP, BGP, etc. 
What you are describing is the priority associated with the protocol. I feel 
the term "Protocol-Origin" and "Protocol-Origin Priority" is used 
interchangeably, leading to this misunderstanding.

To confirm, in the example - Candidate-path CP1 . The value 20 identify BGP or the 
Priority value associated with BGP? I am assuming it is the priority!

In which case some cleanup of text is needed to make things clear.
[KT] I see your point. The use of “priority” and that too inconsistently might 
be the cause for the confusion. Will clean-up the text around this.


- Section 10, It might be a good idea to acknowledge security considerations 
from the SR policy architecture point of view: how various SR policy parameters 
and attributes could be exploited to make a headend to forward the traffic 
incorrectly. It is better to add details that clearly show that the authors/WG 
have given it a thought and analyzed the implications.
[KT] As a reminder the SR Policy has been introduced in RFC8402 which covers 
these aspects of incorrect routing and other challenges associated with source 
routing. This document is only providing the details of the implementation 
construct/framework for the SR Policy.


[Dhruv]: In my reading, RFC 8402 security considerations are focused on the 
data plane and not much on the interaction between the controller and SR nodes 
where the SR policy architecture comes in.
[KT] This document does not cover the actual protocols used for interactions 
between controller and routers – that is covered via PCEP and BGP documents.


- Section 11, What is the range of the value for Segment Types? A-Z only? It 
would be good to be clear about this. With A-K already allocated, worth 
thinking if this is too restrictive and not future-proof. Perhaps we could 
think of the value as a string that is currently populated with a single 
alphabetic character.
[KT] String can become freeform. How about A-Z, then AA-AZ … ZA-ZZ – that 
should be a large enough space?

[Dhruv]: That works. Maybe you could add this to the table to clearly indicate 
the range:
L-Z: Unassigned
AA-ZZ: Unassigned
[KT] I’ll try to describe this in the text since the AA-ZZ might not be very 
clear.


Related question: is there a value in putting aside a few of these for 
Experimental Use?
[KT] I don’t think so because these are not signaled in any protocol.


- Since the I-D talks about policy configuration, explicit candidate paths, 
verification, SR-DB, etc. I don't want to add work for the authors but I do 
feel in this case a dedicated manageability consideration section would be 
useful :)
[KT] Good catch. I will add it. It is not much work really since we need to 
point to R

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Satoru Matsushima]

Hi spring chairs, 

I think that the document is ready to move forward.

Here one minor comment is bellow:

Section 6.2 says on BSID as follow:

   When the active candidate path has a specified BSID, the SR Policy
   uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
   available (i.e., not associated with any other usage: e.g. to another
   MPLS client, to another SID, to another SR Policy).

My suggestion for that above text as follow:

   When the active candidate path has a specified BSID, the SR Policy
   uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
   available (i.e., not associated with any other usage: e.g. to another
   MPLS client, to another SID, to another SR Policy, within the range of 
locators in SRv6).

Best regards,
--satoru

> On Apr 16, 2021, at 3:57, James Guichard  
> wrote:
> 
> Dear WG:
>  
> This email starts a 2 week Working Group Last Call for 
> draft-ietf-spring-segment-routing-policy [1].
>  
> Please read this document if you haven’t read the most recent version and 
> send your comments to the SPRING WG list no later than April 29th 2021.
>  
> If you are raising a point which you expect will be specifically debated on 
> the mailing list, consider using a specific email/thread for this point.
>  
> Lastly, if you are an author or contributors for this document please 
> response to the IPR call in the previous email thread.
>  
> Thanks!
>  
> Jim, Joel & Bruno
>  
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>  
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Dhruv Dhody]

Hi Ketan,

Thanks for the discussion. Sniping to -


>
>
> If a node is identified by multiple addresses, from the point of view of
> the SR policy they would be considered as different nodes, correct?
>
> *[KT] This relates to the computation of SR Policy which is outside the
> scope of this document. There was some text around computation aspects in
> an earlier version of the draft that has been moved into
> draft-filsfils-spring-sr-policy-considerations around the WG adoption time.
> To answer your question, the endpoint address can be mapped to a node which
> becomes the tail-end and then path is computed to that node. In that case,
> multiple addresses may all map to a single node. This would be an
> implementation aspect.*
>

[Dhruv]: I was thinking from the SR policy identification point of view,
i.e.  and  will be
considered as different SR policies even though H1-IP1 and H1-IP2 belong to
the same headend H1.


> - Section 2.3, What are the 8-bit values for the Protocol-Origin, is
> there an existing registry that is used here? Is it -
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
> , should it be listed in this document perhaps?
>
> *[KT] These are not code points but suggested default values for the
> Priority assigned to each protocol. An implementation may use a completely
> different scheme and/or make theme configurable. I see that
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
> 
> does not clearly indicate this and perhaps the authors should clarify that
> the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority
> value to be used for that particular CP in the tiebreaker.*
>
>
>
[Dhruv]: I am referring to this text -

   Protocol-Origin of a candidate path is an 8-bit value which
   identifies the component or protocol that originates or signals the
   candidate path.

Which says that an "8-bit value" identifies the protocol as PCEP, BGP, etc.
What you are describing is the priority associated with the protocol. I
feel the term "Protocol-Origin" and "Protocol-Origin Priority" is used
interchangeably, leading to this misunderstanding.

To confirm, in the example - Candidate-path CP1 . The value 20 identify BGP or
the Priority value associated with BGP? I am assuming it is the priority!

In which case some cleanup of text is needed to make things clear.


>
> - Section 10, It might be a good idea to acknowledge security
> considerations from the SR policy architecture point of view: how various
> SR policy parameters and attributes could be exploited to make a headend to
> forward the traffic incorrectly. It is better to add details that clearly
> show that the authors/WG have given it a thought and analyzed the
> implications.
>
> *[KT] As a reminder the SR Policy has been introduced in RFC8402 which
> covers these aspects of incorrect routing and other challenges associated
> with source routing. This document is only providing the details of the
> implementation construct/framework for the SR Policy.*
>
>
>
[Dhruv]: In my reading, RFC 8402 security considerations are focused on the
data plane and not much on the interaction between the controller and SR
nodes where the SR policy architecture comes in.



> - Section 11, What is the range of the value for Segment Types? A-Z only?
> It would be good to be clear about this. With A-K already allocated, worth
> thinking if this is too restrictive and not future-proof. Perhaps we could
> think of the value as a string that is currently populated with a single
> alphabetic character.
>
> *[KT] String can become freeform. How about A-Z, then AA-AZ … ZA-ZZ – that
> should be a large enough space?*
>
>
[Dhruv]: That works. Maybe you could add this to the table to clearly
indicate the range:
L-Z: Unassigned
AA-ZZ: Unassigned

Related question: is there a value in putting aside a few of these for
Experimental Use?


>
> - Since the I-D talks about policy configuration, explicit candidate
> paths, verification, SR-DB, etc. I don't want to add work for the authors
> but I do feel in this case a dedicated manageability consideration section
> would be useful :)
>
> *[KT] Good catch. I will add it. It is not much work really since we need
> to point to RFC8402 which introduced the SR Policy and an informative
> reference to draft-ietf-spring-sr-policy-yang that the WG is already
> working on.*
>
>
>
[Dhruv]: That helps, but also think in lines of documenting some key
considerations as per
https://datatracker.ietf.org/doc/html/rfc5706#section-2


> Hope the authors and WG find these suggestions useful.
>
> *[KT] Yes, definitely.*
>
>
Thanks!
Dhruv



>
>
> *Thanks,*
>
> *Ketan*
>
> Thanks!
> Dhruv
>
> On Fri, Apr 16, 2021 at 12:27 AM James Guichard <
> james.n.guich...@futurewei.com> wrote:
>
> Dear WG:
>
>
>
> This email starts a 2 week Working 

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Dhruv,

Thanks for your detail review and great comments/feedback.

Please check inline bellow.

From: spring  On Behalf Of Dhruv Dhody
Sent: 29 April 2021 11:51
To: James Guichard 
Cc: spring@ietf.org; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi WG, Authors,

Support publication. The document reads well and describes key concepts 
clearly. Just some friendly suggestions for the authors to consider -

- IMHO introduction section should be expanded as it can provide helpful clues 
to new-bees, our published document is not just for the insiders.
[KT] RFC8402 provides the more broader and generalized introduction for SR 
Policy while this document is quite focussed on the details of the 
implementation and steering concepts. I will add some text in the introduction 
to point the reader to RFC8402 for the broader overview.

- Section 2.1, is there any guidance for the IP address for the headend and 
endpoint?
[KT] Nothing specific – especially so it is not construed as being normative. 
Generally, the IP address associated with the endpoint node (e.g. Router ID) 
may be the most appropriate for use or in other cases, the IP address that is 
set as the BGP next-hop for Service Routes may be used. So it is very use-case 
specific.

If a node is identified by multiple addresses, from the point of view of the SR 
policy they would be considered as different nodes, correct?
[KT] This relates to the computation of SR Policy which is outside the scope of 
this document. There was some text around computation aspects in an earlier 
version of the draft that has been moved into 
draft-filsfils-spring-sr-policy-considerations around the WG adoption time. To 
answer your question, the endpoint address can be mapped to a node which 
becomes the tail-end and then path is computed to that node. In that case, 
multiple addresses may all map to a single node. This would be an 
implementation aspect.

- Section 2.1, I am worried that the use of the noun "intent" to describe 
'color'. It does not align with the other use of the term in industry/NMRG. I 
see 'SLA associated with color' in other places. There was a jabber discussion 
in 110, maybe I am in rough here but wanted to reconfirm!
[KT] In this context, intent is the objective and that objective may be for 
carrying traffic to meet a specific SLA. This is conveyed by color. I will try 
to clarify this further in the text.

- Section 2.3, Reference to RFC 8664 for PCEP is wrong here, as  is signalled via draft-ietf-pce-segment-routing-policy-cp instead.
[KT] RFC8664 does specify in its intro that it is for signaling of SR Policy 
CP. However, the ability signal multiple CPs and signaling of color was 
introduced by the draft-ietf-pce-segment-routing-policy-cp. So perhaps we 
should use both references? I will update for the PCEP draft reference where 
appropriate.

- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there an 
existing registry that is used here? Is it - 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
 , should it be listed in this document perhaps?
[KT] These are not code points but suggested default values for the Priority 
assigned to each protocol. An implementation may use a completely different 
scheme and/or make theme configurable. I see that 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
 does not clearly indicate this and perhaps the authors should clarify that the 
Protocol Origin in that PCEP TLV is used to tweak/signal the Priority value to 
be used for that particular CP in the tiebreaker.

- Section 2.4, For ASN, maybe add "If 2-byte ASNs are in use, the low-order 16 
bits MUST be used, and the high-order bits MUST be set to zero.". For IPv4 Node 
Address, I would suggest adding the high-order bits MUST be set to zero!
[KT] Ack – will update that.

- Section 2.5, in draft-ietf-pce-segment-routing-policy-cp, no further 
clarification is given about the Discriminator and it simply points to this 
I-D. This draft says it is left for the future for PCEP. Since the I-D says 
tuple  uniquely identifies a 
candidate path; we need to specify clearly how to populate the discriminator 
value in PCEP in this I-D or in PCE WG I-D (it cant be left for the future 
IMHO)!
[KT] I can see that 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2
 does allow for signaling the Discriminator value as part of PCEP TLV. I will 
put an informative reference to that document instead of “future”.

- Section 2.7, we need to say that preference is a 32-bit value (as done for 
other fields).
[KT] Ack

- Section 2.11, why only a SHOULD and not MUST in "Only the active candidate 
path SHOULD be used for forwarding traffic that is being steered onto that 
policy."?
[KT] It is a SHOULD to allow for a non-active or second best CP to b

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Dhruv Dhody]

Hi WG, Authors,

Support publication. The document reads well and describes key concepts
clearly. Just some friendly suggestions for the authors to consider -

- IMHO introduction section should be expanded as it can provide helpful
clues to new-bees, our published document is not just for the insiders.
- Section 2.1, is there any guidance for the IP address for the headend and
endpoint? If a node is identified by multiple addresses, from the point of
view of the SR policy they would be considered as different nodes, correct?
- Section 2.1, I am worried that the use of the noun "intent" to describe
'color'. It does not align with the other use of the term in industry/NMRG.
I see 'SLA associated with color' in other places. There was a jabber
discussion in 110, maybe I am in rough here but wanted to reconfirm!
- Section 2.3, Reference to RFC 8664 for PCEP is wrong here, as  is signalled via draft-ietf-pce-segment-routing-policy-cp instead.
- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there
an existing registry that is used here? Is it -
https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4
, should it be listed in this document perhaps?
- Section 2.4, For ASN, maybe add "If 2-byte ASNs are in use, the low-order
16 bits MUST be used, and the high-order bits MUST be set to zero.". For
IPv4 Node Address, I would suggest adding the high-order bits MUST be set
to zero!
- Section 2.5, in draft-ietf-pce-segment-routing-policy-cp, no further
clarification is given about the Discriminator and it simply points to this
I-D. This draft says it is left for the future for PCEP. Since the I-D says
tuple  uniquely identifies a
candidate path; we need to specify clearly how to populate the
discriminator value in PCEP in this I-D or in PCE WG I-D (it cant be left
for the future IMHO)!
- Section 2.7, we need to say that preference is a 32-bit value (as done
for other fields).
- Section 2.11, why only a SHOULD and not MUST in "Only the active
candidate path SHOULD be used for forwarding traffic that is being steered
onto that policy."?
- Section 3, The focus is on SR headend, some text on SR-DB at the
controller would be nice. Further, in "A non-attached (remote) domain
topology MAY be learned via BGP-LS or NETCONF."; could we clarify that this
is at the controller? The PCEP references should be changed to
draft-ietf-pce-segment-routing-policy-cp.
- Section 4, there should be rules regarding which combinations of segment
types are allowed to form a valid segment list. Cant mix SR-MPLS and SRv6
for example!
- Section 10, It might be a good idea to acknowledge security
considerations from the SR policy architecture point of view: how various
SR policy parameters and attributes could be exploited to make a headend to
forward the traffic incorrectly. It is better to add details that clearly
show that the authors/WG have given it a thought and analyzed the
implications.
- Section 11, What is the range of the value for Segment Types? A-Z only?
It would be good to be clear about this. With A-K already allocated, worth
thinking if this is too restrictive and not future-proof. Perhaps we could
think of the value as a string that is currently populated with a single
alphabetic character.
- Since the I-D talks about policy configuration, explicit candidate paths,
verification, SR-DB, etc. I don't want to add work for the authors but I do
feel in this case a dedicated manageability consideration section would be
useful :)

Nits
- Expand on first use: SRv6, SRGB, SRLB,SRLG, SRH, BSID, PW, BFD,
- s/SR DB/SR-DB/g
- Section 2.2, s/via protocols like/via protocol extensions like/

Hope the authors and WG find these suggestions useful.

Thanks!
Dhruv
On Fri, Apr 16, 2021 at 12:27 AM James Guichard <
james.n.guich...@futurewei.com> wrote:

> Dear WG:
>
>
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-spring-segment-routing-policy [1].
>
>
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SPRING WG list no later than April 29th 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributors for this document please
> response to the IPR call in the previous email thread.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Andrew,

Thanks for your review and comments.

We can update that text to clarify as below:

When BGP SR Policy is the Protocol-Origin, the BGP process receiving the route 
provides the distinguisher (refer to Section 2.1 of 
[I-D.ietf-idr-segment-routing-te-policy]) as the discriminator.

I’ll also make the clarification on the role of the distinguisher in BGP SRTE 
in the draft-ietf-idr-segment-routing-te-policy of which I am also a co-author.

Thanks,
Ketan

From: spring  On Behalf Of Stone, Andrew (Nokia - 
CA/Ottawa)
Sent: 29 April 2021 11:12
To: James Guichard ; spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hello Chairs, WG and Authors

I think there may need to be a wording adjustment required to the BGP related 
text in section 2.5, for more clarity regarding the use of BGP distinguisher in 
place of discriminator:


   When BGP SR Policy is the Protocol-Origin, it is the distinguisher

   (refer to Section 2.1 of 
[I-D.ietf-idr-segment-routing-te-policy<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-10#ref-I-D.ietf-idr-segment-routing-te-policy>]).

The sentence seems to be focused on the context of a headend node importing SR 
policy from BGP into an SR Policy module, and could be interpreted differently 
(and incorrectly) when applied in the context of a controller defined SR Policy 
which is then injected into BGP. I have spoken to Ketan regarding this, so may 
be updated shortly. (additional clarification in idr document may also come).

Aside from that, I support WGLC adoption. The document describes the behaviour 
and associated contexts within the SR Policy model well, and it’s an important 
draft to have finalized.

Thanks
Andrew

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Stone, Andrew (Nokia - CA/Ottawa)]

Hello Chairs, WG and Authors

I think there may need to be a wording adjustment required to the BGP related 
text in section 2.5, for more clarity regarding the use of BGP distinguisher in 
place of discriminator:


   When BGP SR Policy is the Protocol-Origin, it is the distinguisher

   (refer to Section 2.1 of 
[I-D.ietf-idr-segment-routing-te-policy]).

The sentence seems to be focused on the context of a headend node importing SR 
policy from BGP into an SR Policy module, and could be interpreted differently 
(and incorrectly) when applied in the context of a controller defined SR Policy 
which is then injected into BGP. I have spoken to Ketan regarding this, so may 
be updated shortly. (additional clarification in idr document may also come).

Aside from that, I support WGLC adoption. The document describes the behaviour 
and associated contexts within the SR Policy model well, and it’s an important 
draft to have finalized.

Thanks
Andrew

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Pengshuping (Peng Shuping)]

Hi,

This is an important draft. I support the WGLC of this draft.

Thank you!

Best regards,
Shuping

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Friday, April 16, 2021 2:57 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven't read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Rakesh Gandhi]

Hi WG,
I have read the latest version of the draft and I believe it is ready for
publication.

Thanks,
Rakesh


*From: *spring  on behalf of James Guichard <
> james.n.guich...@futurewei.com>
> *Date: *Thursday, April 15, 2021 at 2:57 PM
> *To: *"spring@ietf.org" 
> *Cc: *"spring-cha...@ietf.org" 
> *Subject: *[spring] WGLC for draft-ietf-spring-segment-routing-policy
>
>
>
> Dear WG:
>
>
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-spring-segment-routing-policy [1].
>
>
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SPRING WG list no later than April 29th 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributors for this document please
> response to the IPR call in the previous email thread.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Boris,

Thanks for your review and feedback.

Did you imply that we add an implementation status section in the draft? Or are 
you suggesting that the chairs poll for implementation and deployment status? I 
ask because the Implementation Status section is generally removed before 
publication as RFC.

Regarding implementation, I am aware of support for this draft in Cisco’s 
Routing products for many years now with multiple deployments. I am also aware 
of other vendor support & operator deployment. However, would request other WG 
members to respond/confirm.

Thanks,
Ketan

From: spring  On Behalf Of Boris Hassanov
Sent: 28 April 2021 02:43
To: spring@ietf.org; James Guichard 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi James and all,

I read the draft and strongly support its publication as WG document. Very 
detailed, helpful and interesting document.
I would only add implementation status part because currently it is not easy to 
get such info about implementation details.

Thank you.

SY,
Boris

On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:



Dear WG:



This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].



Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.



If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.



Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.



Thanks!



Jim, Joel & Bruno



[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/






___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Ketan Talaulikar (ketant)]

Hi Pablo,

Thank for your review and we've just posted an update that addresses the IANA 
changes pointed out by you.

https://www.ietf.org/archive/id/draft-ietf-spring-segment-routing-policy-10.txt

Thanks,
Ketan

From: spring  On Behalf Of Pablo Camarillo (pcamaril)
Sent: 27 April 2021 18:06
To: James Guichard ; spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi,

I've read the latest revision of this document and I believe it's ready for 
publication.
This is an important draft, implemented by multiple vendors and deployed.

Minor nit: The IANA considerations request the creation of a new top-level 
registry "Segment Routing Parameters", and a new sub-registry called "Segment 
Types". The SR top-level registry was created with RFC8986; hence you only need 
the new sub-registry.

Thanks,
Pablo.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of James Guichard
Sent: jueves, 15 de abril de 2021 20:57
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven't read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Boris Hassanov]

 Hi James and all,
I read the draft and strongly support its publication as WG document. Very 
detailed, helpful and interesting document.I would only add implementation 
status part because currently it is not easy to get such info about 
implementation details.
Thank you.

SY,Boris

On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
 wrote:  
 
  
Dear WG:
 
  
 
This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].
 
  
 
Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.
 
  
 
If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.
 
  
 
Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.
 
  
 
Thanks!
 
  
 
Jim, Joel & Bruno
 
  
 [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ 
   
  
 
  
 ___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
  ___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Pablo Camarillo (pcamaril)]

Hi,

I've read the latest revision of this document and I believe it's ready for 
publication.
This is an important draft, implemented by multiple vendors and deployed.

Minor nit: The IANA considerations request the creation of a new top-level 
registry "Segment Routing Parameters", and a new sub-registry called "Segment 
Types". The SR top-level registry was created with RFC8986; hence you only need 
the new sub-registry.

Thanks,
Pablo.

From: spring  On Behalf Of James Guichard
Sent: jueves, 15 de abril de 2021 20:57
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven't read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Bernier, Daniel]

Hello,

I am not aware of any IPR and support the WGLC

Dan B

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [EXT][spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Majumdar, Kausik]

I support the WGLC on the segment routing policy draft. This is an important 
draft. It is a well written and ready for publication.

Thanks,
Kausik


From: spring  On Behalf Of James Guichard
Sent: Thursday, April 15, 2021 11:57 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG: This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1]. Please read this document if you 
haven't read the most recent version and send your commen
External (james.n.guich...@futurewei.com)
  Report This 
Email
  FAQ  Protection by 
INKY

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven't read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] 
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Zafar Ali (zali)]

Dear chairs and the WG,

I have re-read the latest version of the draft carefully and I support the WGLC.
I find it quite well written and ready for the publication.

Thanks

Regards … Zafar

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring