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

From: James Guichard <[email-masked]>
Date: Thu, 15 Apr 2021 18:56:45 +0000

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/

---

From: "Majumdar, Kausik" <[email-masked]>
Date: Mon, 26 Apr 2021 16:58:49 +0000

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 <[email-masked]> On Behalf Of James Guichard
Sent: Thursday, April 15, 2021 11:57 AM
To: [email-masked]
Cc: [email-masked]
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 ([email-masked]<mailto:[email-masked]>)
  Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tL2IyNTlhYzFmZTQwMzliNzM5OTdlMzZmMTUwMDY5MDAxLzE2MTg1MTMwMjYuMDY=#key=c55ffaa13a8f04707efcdb7556087252>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

Dear WG:

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/<https://secure-web.cisco.com/1PkGVggK9YILWC4Buu8ZYmPgOoYOQJqrLqYzrY1kJd1EMZdtiAq2WQMubHDWCbFICimSrzU2blNob4p23q_znuF5ZfHL_nGDONFpMlBrI2lr4acc4dECeSzpmzPElqXvFL1zTdGKPkV_bDaZ-wZR0Yst539PFV7L-7F_T36ST5IWasS_1P7rd9Y9YyK7UmgAiQX3ignqyRSEXs6HcRKanqFC32piDRyK9kl3B3xKlKhIRUc9LCV3amofmAker7GGtvVIOOYRrnCiKcRLyu3dIy57BcPYG891dHA7OVHL2M0R06NRyPcxjmvtjJyUyuE8i/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-segment-routing-policy%2F>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 27 Apr 2021 12:36:24 +0000

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 <[email-masked]> On Behalf Of James Guichard
Sent: jueves, 15 de abril de 2021 20:57
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Boris Hassanov <[email-masked]>
Date: Tue, 27 Apr 2021 21:13:10 +0000 (UTC)

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 <[email-masked]> wrote:  

Dear WG:

 
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.

 

Thanks!

Jim, Joel & Bruno

  
 _______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 28 Apr 2021 05:02:54 +0000

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 <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: 27 April 2021 18:06
To: James Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi,

Thanks,
Pablo.

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

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 28 Apr 2021 05:47:55 +0000

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 <[email-masked]> On Behalf Of Boris Hassanov
Sent: 28 April 2021 02:43
To: [email-masked]; James Guichard <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Thanks!

Jim, Joel & Bruno

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 29 Apr 2021 03:12:17 +0000

Hi,

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

Thank you!

Best regards,
Shuping

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

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 29 Apr 2021 11:50:44 +0530

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 <color,
endpoint> 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 <Protocol-Origin, originator, discriminator> 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 <
[email-masked]> 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
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 29 Apr 2021 08:26:52 +0000

Hi Dhruv,

Thanks for your detail review and great comments/feedback.

Please check inline bellow.

From: spring <[email-masked]> On Behalf Of Dhruv Dhody
Sent: 29 April 2021 11:51
To: James Guichard <[email-masked]>
Cc: [email-masked]; [email-masked]
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 <color, endpoint> 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 <Protocol-Origin, originator, discriminator> 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 be used in FRR scenarios – Sec 9.3 and there may be other reasons for implementations/use-cases to trigger similar behaviors.

- 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?
[KT] Actually it should be SR Policy computation node – so it covers both headend and controller. Will clarify.

The PCEP references should be changed to draft-ietf-pce-segment-routing-policy-cp.
[KT] Ack

- 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!
[KT] Ack

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

- 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?

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

Nits
[KT] ack

[KT] Yes, definitely.

Thanks,
Ketan

Thanks!
Dhruv
On Fri, Apr 16, 2021 at 12:27 AM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 29 Apr 2021 15:45:54 +0530

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. <H1-IP1, color, endpoint> and <H1-IP2, color, endpoint> 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 -
> *[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 <protocol-origin = 20,
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] 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] 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

> *[KT] Yes, definitely.*
Thanks!
Dhruv

> *Thanks,*
> *Ketan*

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 29 Apr 2021 22:05:34 +0900

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 <[email-masked]> wrote:
> 
> Dear WG:
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 29 Apr 2021 14:08:39 +0000

Hi Dhruv,

Please check inline below.

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

Hi Ketan,

[Dhruv]: I was thinking from the SR policy identification point of view, i.e. <H1-IP1, color, endpoint> and <H1-IP2, color, endpoint> 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.

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 <protocol-origin = 20, 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.

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

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

[Dhruv]: That helps, but also think in lines of documenting some key considerations as per https://datatracker.ietf.org/doc/html/rfc5706#section-2
[KT] This is not really a new protocol per-se and I am not sure if this is necessary. However, if there are any text proposals, we can discuss within the WG.

Thanks,
Ketan

Thanks!
Dhruv

Thanks,
Ketan

Thanks!
Dhruv

Thanks!

Jim, Joel & Bruno

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Thu, 29 Apr 2021 14:13:27 +0000

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 <[email-masked]> On Behalf Of James Guichard
Sent: Thursday, April 15, 2021 2:57 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 29 Apr 2021 14:14:25 +0000

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 <[email-masked]> On Behalf Of Satoru Matsushima
Sent: 29 April 2021 18:36
To: [email-masked]
Cc: James Guichard <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi spring chairs,

Best regards,
--satoru

On Apr 16, 2021, at 3:57, James Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Thu, 29 Apr 2021 14:45:28 +0000

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

From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Date: Thursday, April 15, 2021 at 2:57 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [spring] WGLC for draft-ietf-spring-segment-routing-policy
Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Matt Anderson <[email-masked]>
Date: Thu, 29 Apr 2021 14:27:34 -0400

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.

-- 
Matt

---

From: Nandan Saha <[email-masked]>
Date: Thu, 29 Apr 2021 16:03:24 -0700

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

Thanks,
Nandan

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 30 Apr 2021 08:28:58 +0900

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

Cheers,
--satoru

> On Apr 29, 2021, at 23:14, Ketan Talaulikar (ketant) <[email-masked]> wrote:
> 
> 
> Hi Satoru-san,
>

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 30 Apr 2021 11:42:31 +0530

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) <[email-masked]>
wrote:

> *From:* Dhruv Dhody <[email-masked]>
> *Sent:* 29 April 2021 15:46
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* James Guichard <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
>
>
>
> Hi Ketan,
>
>
>
> *[KT] Yes, they would be different SR Policies.*
>
>
>
>
> 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
> *[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.*
>
>
>
>
> [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.*
>
>
>
>
>
> *[KT] I’ll try to describe this in the text since the AA-ZZ might not be
> very clear.*
>
>
>
> *[KT] I don’t think so because these are not signaled in any protocol.*
>
>
>
>
> *[KT] This is not really a new protocol per-se and I am not sure if this
> is necessary. However, if there are any text proposals, we can discuss
> within the WG.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 30 Apr 2021 03:06:46 -0400

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 flow” implies per packet used in EVPN MHD/MHN or with IPv6
flow label stateless uniform load balancing.  Flow based implies flow based
load balancing of the entire flow which is subject to polarization uneven
load balancing. In MPLS framework which SR-MPLS reused the MPLS data plane
even with entropy label the ECMP control and data plane extra per path
label state is eliminated but the flows are still flow based load balanced
and not per packet as is implied with “per flow” statement.  In the MPLS
framework all interesting packets flow along LSP path to egress PE FEC
destination for all VPNs unless per VPN to TE next hop rewrite feature is
utilized and then each VPN can map to a different RSVP tunnel.  Long story
short - reasons above as to the rewrite of Abstract as well as Introduction
sentence where “per flow” is mentioned.

What is eliminated with SR is LDP and RSVP TE control plane signaling state
not flow state.  In both SR and MPLS the flow state exist but now with SR
the per flow steering has much more granularity.  This does bring up
another very critical point.  I can understand SRv6 as it used the IPv6
data plane and with RFC 6437 flow label you get per flow per packet uniform
distribution load balancing however with SR-MPLSv4 you would still be
subject to flow based load balancing hash meaning all packets that are part
of the same flow would be steered along the same ECMP prefix sid path
instantiated as oppose to SRv6 which can take advantage of flow label
uniform load balancing.  At the bottom of the draft where you get into
coloring of flows per destination coloring would work but section 8.6 per
flow steering would not work as you are still subject to IPv4 flow based
load balancing polarization of packets.  On the other hand if SR-MPLSv6 was
used that would be MPLS over v6 core and you now have flow label providing
entropy for load balancing now the per flow load balancing per flow
coloring would now work.

In the draft you mentioned that all of the draft uses MPLS data plane for
the examples but given the issue I am bringing up I think maybe at least
mention SRv6 if you don’t want to mention SR-MPLSv6 which would be not as
common. As their can be more nuances between MPLS data plane and IPv6 data
plane I 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 <[email-masked]> wrote:

> On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
>> Hi Dhruv,
>>
>>
>>
>> *[KT] String can become freeform. How about A-Z, then AA-AZ … ZA-ZZ –
>> that should be a large enough space?*
>>
>>
>>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 30 Apr 2021 03:15:43 -0400

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 <[email-masked]> wrote:

> What is eliminated with SR is LDP and RSVP TE control plane signaling
> state not flow state.  In both SR and MPLS the flow state exist but now
> with SR the per flow steering has much more granularity.  This does bring
> up another very critical point.  I can understand SRv6 as it used the IPv6
>    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
> The Segment Routing architecture [RFC8402 <https://tools.ietf.org/html/rfc8402>] specifies that any
>> 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
>>> 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.
>>>
>>> *[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 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] 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
>>> 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.
>>>
>>>
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 30 Apr 2021 07:25:28 +0000

Hi Dhruv,

Sent: 30 April 2021 11:43

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dhruv,

From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: 29 April 2021 15:46
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: James Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan,

Thanks,
Ketan

Thanks!
Dhruv

Thanks,
Ketan

Thanks!
Dhruv

Thanks!

Jim, Joel & Bruno

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 30 Apr 2021 03:31:26 -0400

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 <[email-masked]> wrote:

>>>> 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?
>>>>
>>>> [Dhruv]: I was thinking from the SR policy identification point of
>>>> view, i.e. <H1-IP1, color, endpoint> and <H1-IP2, color, endpoint> will be
>>>> *[KT] I’ll try to describe this in the text since the AA-ZZ might not
>>>> be very clear.*
>>>>
>>>>
>>>>
>>>> *[KT] This is not really a new protocol per-se and I am not sure if
>>>> this is necessary. However, if there are any text proposals, we can discuss
>>>> within the WG.*
>>>>
>>>>
>>>>
>>>> *Thanks,*
>>>>
>>>> *Ketan*
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 30 Apr 2021 13:03:42 +0000

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 <[email-masked]>
Sent: 30 April 2021 13:01
To: Dhruv Dhody <[email-masked]>
Cc: James Guichard <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; [email-masked]
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.

Kind Regards

Gyan

On Fri, Apr 30, 2021 at 3:15 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG Authors

Few minor comments

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 flow” implies per packet used in EVPN MHD/MHN or with IPv6 flow label stateless uniform load balancing.  Flow based implies flow based load balancing of the entire flow which is subject to polarization uneven load balancing. In MPLS framework which SR-MPLS reused the MPLS data plane even with entropy label the ECMP control and data plane extra per path label state is eliminated but the flows are still flow based load balanced and not per packet as is implied with “per flow” statement.  In the MPLS framework all interesting packets flow along LSP path to egress PE FEC destination for all VPNs unless per VPN to TE next hop rewrite feature is utilized and then each VPN can map to a different RSVP tunnel.  Long story short - reasons above as to the rewrite of Abstract as well as Introduction sentence where “per flow” is mentioned.

What is eliminated with SR is LDP and RSVP TE control plane signaling state not flow state.  In both SR and MPLS the flow state exist but now with SR the per flow steering has much more granularity.  This does bring up another very critical point.  I can understand SRv6 as it used the IPv6 data plane and with RFC 6437 flow label you get per flow per packet uniform distribution load balancing however with SR-MPLSv4 you would still be subject to flow based load balancing hash meaning all packets that are part of the same flow would be steered along the same ECMP prefix sid path instantiated as oppose to SRv6 which can take advantage of flow label uniform load balancing.  At the bottom of the draft where you get into coloring of flows per destination coloring would work but section 8.6 per flow steering would not work as you are still subject to IPv4 flow based load balancing polarization of packets.  On the other hand if SR-MPLSv6 was used that would be MPLS over v6 core and you now have flow label providing entropy for load balancing now the per flow load balancing per flow coloring would now work.

In the draft you mentioned that all of the draft uses MPLS data plane for the examples but given the issue I am bringing up I think maybe at least mention SRv6 if you don’t want to mention SR-MPLSv6 which would be not as common. As their can be more nuances between MPLS data plane and IPv6 data plane I 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

   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

[RFC8402<https://tools.ietf.org/html/rfc8402>] specifies that any

NEW

The Segment Routing architecture [RFC8402<https://tools.ietf.org/html/rfc8402>] specifies that any

Kind Regards

Gyan

On Fri, Apr 30, 2021 at 2:13 AM Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan

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

Hi Ketan,

Thanks,
Ketan

Thanks!
Dhruv

Thanks,
Ketan

Thanks!
Dhruv

Thanks!

Jim, Joel & Bruno

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 30 Apr 2021 13:07:43 +0000

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 <[email-masked]>
Cc: James Guichard <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Dhruv,

Hi Ketan

Thanks,
Ketan

Just my 2 paisa :)
Stay Safe!

Thanks!
Dhruv

Hi Ketan,

Thanks,
Ketan

Thanks!
Dhruv

Thanks,
Ketan

Thanks!
Dhruv

Thanks!

Jim, Joel & Bruno

---

From: Boris Hassanov <[email-masked]>
Date: Fri, 30 Apr 2021 15:18:51 +0000 (UTC)

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) <ketant=[email-masked]> wrote:  

Hi Boris,

 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. 

 
Thanks,
 
Ketan

From: spring <[email-masked]>On Behalf Of Boris Hassanov

Hi James and all,

 

Thank you.

SY,
 
Boris

 

Dear WG:

 

 

Thanks!

Jim, Joel & Bruno

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 30 Apr 2021 16:12:00 +0000

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 <bhassanov=[email-masked]>
Sent: 30 April 2021 20:49
To: [email-masked]; James Guichard <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi Ketan,

Thank you.

SY,
Boris

On Wednesday, April 28, 2021, 8:48:06 AM GMT+3, Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>> wrote:

Hi Boris,

Thanks,

Ketan

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Boris Hassanov
Sent: 28 April 2021 02:43
To: [email-masked]<mailto:[email-masked]>; James Guichard <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi James and all,

Thank you.

SY,

Boris

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Boris Hassanov <[email-masked]>
Date: Fri, 30 Apr 2021 16:37:38 +0000 (UTC)

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) <ketant=[email-masked]> 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,

 

Thanks,
 
Ketan

 
Hi Ketan,

 

Thank you.

SY,
 
Boris

 

Hi Boris,

 

 
Thanks,
 
Ketan

 
Hi James and all,

 

Thank you.

SY,
 
Boris

 

Dear WG:

 

 

Thanks!

Jim, Joel & Bruno

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 30 Apr 2021 16:52:35 +0000

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

Dear WG:

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-segment-routing-policy%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cacf87bb5c7a8401115a908d90bf6509d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637553974852253455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uhM%2B2U1fjrq3tkhxYGzPWCLJEjoD7LKPYQyUfMeQx1k%3D&reserved=0>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cacf87bb5c7a8401115a908d90bf6509d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637553974852263449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1H2JGzCyoP9%2BJpSAYjpi6dLLygwsNzmwXFq4glEq9MY%3D&reserved=0>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 30 Apr 2021 12:57:11 -0400

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:
> 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 <bhassanov=[email-masked]>
> *Sent:* 30 April 2021 20:49
> *To:* [email-masked]; James Guichard <[email-masked]>; 
> Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* [email-masked]
> On Wednesday, April 28, 2021, 8:48:06 AM GMT+3, Ketan Talaulikar 
> (ketant) <ketant=[email-masked] 
> <mailto:ketant=[email-masked]>> wrote:
> 
> Hi Boris,
> 
> 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 <[email-masked] <mailto:[email-masked]>> 
> *On Behalf Of *Boris Hassanov
> *Sent:* 28 April 2021 02:43
> *To:* [email-masked] <mailto:[email-masked]>; James Guichard 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> 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 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> Dear WG:
> 
> and send your comments to the SPRING WG list no later than April 29^th 
> 2021.
> 
> [1] 
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ 
> <https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/>
> 
> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/spring>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 30 Apr 2021 17:20:30 +0000

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 <[email-masked]> 
Sent: 30 April 2021 22:27
To: Ketan Talaulikar (ketant) <[email-masked]>; Boris Hassanov <bhassanov=[email-masked]>; [email-masked]; James Guichard <[email-masked]>
Cc: [email-masked]
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:
> 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
> 
> *To:* [email-masked]; James Guichard 
> <[email-masked]>; Ketan Talaulikar (ketant) 
> <[email-masked]>
> 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.
> 
> 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 <[email-masked] 
> <mailto:[email-masked]>> *On Behalf Of *Boris Hassanov
> I would only add implementation status part because currently it is 
> not easy to get such info about implementation details.
> 
> Thank you.
> 
> SY,
> 
> Boris
> 
> debated on the mailing list, consider using a specific email/thread for this point.
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 30 Apr 2021 13:46:00 -0700

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

---

From: Boris Hassanov <[email-masked]>
Date: Fri, 30 Apr 2021 22:23:51 +0000 (UTC)

Agree Jeff.
Thank you.
SY,Boris

    On Friday, April 30, 2021, 11:46:36 PM GMT+3, Jeff Tantsura <[email-masked]> wrote:  
 
 Boris/Ketan,

Thanks and have a great weekend
Cheers,JeffOn Apr 27, 2021, 10:48 PM -0700, Ketan Talaulikar (ketant) <ketant=[email-masked]>, wrote:

Hi Boris,

Thanks,

Ketan

Hi James and all,

Thank you.

SY,

Boris

 

Dear WG:

Thanks!

Jim, Joel & Bruno