Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

From: <[email-masked]>
Date: Wed, 9 Sep 2020 15:16:56 +0000

Hi authors, all,

As an individual contributor, I have two non-blocking comments.

1)      I feel that the terminology “node protection”  in the name of the draft could be misleading.

“Node Protection” is already used in [LFA] and [RLFA]. It refers to a property of the alternate path avoiding the next node on the path to the egress/destination. It does not change the destination/egress.
It looks to me that the function been proposed in the draft is more along [Egress Protection] which protects from the failure of the egress/destination, and hence do change the destination/egress. (full disclosure, I’m co-author of [Egress Protection] )

I think that both are different and that properties are different, hence using the same name is misleading.
In particular, in the first one, the destination/egress is unchanged and hence properties of the destination/egress is unchanged: no problem. While in the second case, a node (a ‘protector’ in [Egress Protection]) is claiming to provide a similar service, but possibly only a subset of the original services or without the stateful states). Cf some discussion on the mailing list along “How do I know that I can safely pretend that I’m the original destination?”

Personally I would propose to replace “Node Protection” by “Segment Protection” or “Segment Egress Protection” or “IGP Segment Egress Protection” since the proposal seem restricted to IGP knowledge.

[LFA] https://tools.ietf.org/html/rfc5286
[RLFA node protection] https://tools.ietf.org/html/rfc8102
[Egress Protection] https://tools.ietf.org/html/rfc8679

2)      At best, the proposal ignores [Egress Protection]. At worst, the draft breaks [Egress Protection]

Both do not seem to co-operate. The draft applies the egress protection even though it can only protections IGP segments/labels while [Egress Protection] would provide a much broader protection, including service (e.g. VPNs) protection. Hence it seems to break [Egress Protection] VPN service protection.
I would propose that the draft refers a bit more to [Egress Protection], uses its terminology if/when appropriate and then elaborate on the above issue. From a technical standpoint, I would propose to privilege the use of a (complete) Protector (as per [Egress Protection] ) if available.

Finally, as also raised by Zhibo, the scalability properties of the draft is not optimal, and in particular less optimal than [Egress Protection]. Indeed, most of the work/states is on a Protector node (having the context mpls forwarding table). For a given failure, [Egress Protection] allows for a single Protector while this drafts requires N Protectors (one per neighbour). So more states in the network and on nodes. Also [Egress Protection] allows to distribute this load while the draft requires the PLR to handle the protection for all its neighbhors.
Since this draft restricts to IGP Segments, the scalability impact his limited but still exist.
(on the pro side, the draft avoids the additional transport cost/delay required to reach the Protector (since PLR and Protector are co-located)/

Regards,
Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 30, 2020 2:25 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Hi SPRING WG,

Authors of draft-hegde-spring-node-protection-for-sr-te-paths  [1] have asked for WG adoption.

Please indicate your support, comments, or objection, for adopting this draft as a working group item by August 20th 2020. (*)

Could those who are willing to work on this document, please notify the list. That gives us an indication of the energy level in the working group to work on this.

Thanks,
Regards,
Bruno, Jim, Joel

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07
(*) 3 weeks to account for the IETF meeting week and the august/summer period.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 9 Sep 2020 15:16:57 +0000

Hi authors, SPRING WG.

There is support for this Informational document and no blocking objections so we have a new WG document.
Authors, please resubmit as a WG document.

In the next (-01) revision, please include a section (or at least text) discussing to the applicability of the protection as there has been a significant thread on this point. Such as when to avoid bypass / how to tell when to avoid bypass  and highlighting the limitations that a network operator might face.

Thanks,
Regards,
Bruno, Jim, Joel

Hi SPRING WG,

Thanks,
Regards,
Bruno, Jim, Joel

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 9 Sep 2020 15:40:37 +0000

Sure. I'll submit the name changed and will close few other comments including the ones you mentioned received during adoption call in the -01 version.

Rgds
Shraddha

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Wednesday, September 9, 2020 8:47 PM
To: [email-masked]; [email-masked]
Subject: RE: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

[External Email. Be cautious of content]

Hi authors, SPRING WG.

Thanks,
Regards,
Bruno, Jim, Joel

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 30, 2020 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Hi SPRING WG,

Thanks,
Regards,
Bruno, Jim, Joel

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07__;!!NEt6yMaO-gk!StwC572jaHfbReWB2DbV3LjA8jWbJmudP-LTYgZSo8TxEBBYAUodINk9eG1QldCz$>
(*) 3 weeks to account for the IETF meeting week and the august/summer period.

Thank you.

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 10 Sep 2020 16:36:57 +0000

Dhruv,

Thanks for the detailed review and comments.

Pls see inline for replies.

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Thursday, August 20, 2020 7:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Hi WG, Authors,

I support adoption.

Looking forward to changes as per the discussion in the other thread started by Joel. I found a few things that can increase the readability of the document.

Minor
- The document doesn't use normative keywords of RFC 2119 (RFC 2119 is in reference somehow still). I am wondering if section 3 and 4 could use them esp section 4.
<shraddha> This document is intended to be informational document and will not use normative language. Will remove reference to 2119. Section 4 is a guidance on
                       How this feature interacts with micro-loop avoidance. The normative text should most likely go to micro-loop avoidance draft on how the node failures
                        Should be consistently detected.

- Section 6, I feel we should at least add a reference to Section 8.1 of RFC 8402 [ https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8402*section-8.1__;Iw!!NEt6yMaO-gk!SLaOSAoItlCpdxOjxp4lwQYk7pKG1Y42tXizJ2oljTOh8n3md5P97QOeGYPHkW6l$  ] to provide a helpful pointer. Can we add some text regarding the context labels - that they do not impose any security issues with a suitable reference (provided that is true :)?
<Shraddha> Sure will add.

- Can we expand "externally visible forwarding behavior", the reference to draft-bashandy-rtgwg-segment-routing-ti-lfa but I don't see that term being used there
<Shraddha> section 6.2 in draft draft-bashandy-rtgwg-segment-routing-ti-lfa Talks about the externally visible behavior. Will refer to the section to make it clear.

- Section 5 could use an example to describe the concept clearly
<Shraddha> ok. Will add

Nits
- Expand sids in abstract
- Expand SRGB on first use
- Should we state it clearly that this document is applicable for SR-MPLS only!
- Suggest to use RFC 8402 notations for the all sids: Node-SIDs, Adj-SIDs, BSIDs instead of node-sids, adjacency-sids, binding-sids
- Section 2, not sure about "SPRING enabled on each node"
- Section tile for 2.1 and 2.3: I am not sure about the terms "node-sid explicit paths" and "adj-sid explicit paths" where the later is actually a mix of node-sids and adj-sids. Perhaps rename them as - section 2.1 to "Node protection for explicit paths with Node-SIDs" and
2.3 to "Node-protection for explicit paths with Adj-SIDs"?
- Figures, add a legend stating what does the values "10", "30", "60"
on the links mean - it is clear that it is cost, but would be good to be explicit.

<shraddha> Thanks for pointing out. Will fix them in the upcoming version.

Thanks!
Dhruv

On Thu, Jul 30, 2020 at 5:54 PM <[email-masked]> wrote:
> Please indicate your support, comments, or objection, for adopting 
> this draft as a working group item by August 20th 2020. (*)
>
>
>
> [1] 
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-sp
> ring-node-protection-for-sr-te-paths-07__;!!NEt6yMaO-gk!SLaOSAoItlCpdx
> Ojxp4lwQYk7pKG1Y42tXizJ2oljTOh8n3md5P97QOeGTxjGU8f$
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> _______________________________________________
> spring mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!SLaOSAoItlCpdxOjxp4lwQYk7pKG1Y42tXizJ2oljTOh8n3md5P
> 97QOeGa8BZYp4$

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 11 Sep 2020 11:43:03 +0000

Hi Bruno,

Thanks for the review and comments.
Pls see inline for replies.

To: [email-masked]
Cc: [email-masked]

Hi authors, all,

  1.  I feel that the terminology "node protection"  in the name of the draft could be misleading.

"Node Protection" is already used in [LFA] and [RLFA]. It refers to a property of the alternate path avoiding the next node on the path to the egress/destination. It does not change the destination/egress.
It looks to me that the function been proposed in the draft is more along [Egress Protection] which protects from the failure of the egress/destination, and hence do change the destination/egress. (full disclosure, I'm co-author of [Egress Protection] )

I think that both are different and that properties are different, hence using the same name is misleading.
In particular, in the first one, the destination/egress is unchanged and hence properties of the destination/egress is unchanged: no problem. While in the second case, a node (a 'protector' in [Egress Protection]) is claiming to provide a similar service, but possibly only a subset of the original services or without the stateful states). Cf some discussion on the mailing list along "How do I know that I can safely pretend that I'm the original destination?"

Personally I would propose to replace "Node Protection" by "Segment Protection" or "Segment Egress Protection" or "IGP Segment Egress Protection" since the proposal seem restricted to IGP knowledge.
<Shraddha> I agree that using the term node protection is confusing. I think that "segment protection" is the  right  term.  Using egress keyword may cause other confusions because term egress is used in egress protection RFCs to mean the egress nodes on which the services reside. In this draft the focus is on nodes that are not egresses.

[LFA] https://tools.ietf.org/html/rfc5286<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc5286__;!!NEt6yMaO-gk!R3XqSiUA_cgf3gc_cZUjOGXAwIop0rKnceS8EvU9vxvgY_DVneweAP5Zs8bjDj_k$>
[RLFA node protection] https://tools.ietf.org/html/rfc8102<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8102__;!!NEt6yMaO-gk!R3XqSiUA_cgf3gc_cZUjOGXAwIop0rKnceS8EvU9vxvgY_DVneweAP5ZszUA3CEW$>
[Egress Protection] https://tools.ietf.org/html/rfc8679<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8679__;!!NEt6yMaO-gk!R3XqSiUA_cgf3gc_cZUjOGXAwIop0rKnceS8EvU9vxvgY_DVneweAP5ZswTcjaLe$>

  1.  At best, the proposal ignores [Egress Protection]. At worst, the draft breaks [Egress Protection]

Both do not seem to co-operate.
<Shraddha> Actually, egress protection as defined in RFC 8679 works well with procedures defined in this draft. Section 3.4 briefly talks about this.
Initial versions of this draft had examples to describe how egress protection works in conjunction with procedures described in this draft.
Basically, egress protection described in RFC 8679 uses a context-id and context label. When the penultimate hop creates protection for the context-id routes
It follows the procedures described in RFC 8679 ( in conjunction with mirror-sid for SR networks). We also have a simplified version of RFC 8679 which uses anycast SIDs and static service labels
Described in draft-hegde-rtgwg-egress-protection-sr-network. This anycast based egress protection also works well with protection procedures described in this document.
I'll add a section with examples to describe this which can help clarify.

The draft applies the egress protection even though it can only protections IGP segments/labels while [Egress Protection] would provide a much broader protection, including service (e.g. VPNs) protection. Hence it seems to break [Egress Protection] VPN service protection.
<Shraddha> No this draft does not break VPN service protection. I'll add detailed examples.

I would propose that the draft refers a bit more to [Egress Protection], uses its terminology if/when appropriate and then elaborate on the above issue. From a technical standpoint, I would propose to privilege the use of a (complete) Protector (as per [Egress Protection] ) if available.
<Shraddha> This draft makes use of looking up the second label in the stack for protection. It is different from protector based approach.
draft-hu-spring-segment-routing-proxy-forwarding Is more closer to protector based approach I think. It comes with an overhead of  configuring the
primary and proxy pairs for set of nodes.

Finally, as also raised by Zhibo, the scalability properties of the draft is not optimal, and in particular less optimal than [Egress Protection].
<Shraddha>I'll add some more text on scalability.  Section 5 of the draft proposes an optimisation to reduce scale.
Indeed, most of the work/states is on a Protector node (having the context mpls forwarding table). For a given failure, [Egress Protection] allows for a single Protector while this drafts requires N Protectors (one per neighbour). So more states in the network and on nodes. Also [Egress Protection] allows to distribute this load while the draft requires the PLR to handle the protection for all its neighbhors.
Since this draft restricts to IGP Segments, the scalability impact his limited but still exist.
(on the pro side, the draft avoids the additional transport cost/delay required to reach the Protector (since PLR and Protector are co-located)/
<Shraddha> Fair point. I would see the advantage of this draft is more from operational perspective since it does not require primary protector configs.
Enabling the feature with one single knob on the router will be good enough.
Regards,
Bruno

Hi SPRING WG,

Thanks,
Regards,
Bruno, Jim, Joel

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07__;!!NEt6yMaO-gk!R3XqSiUA_cgf3gc_cZUjOGXAwIop0rKnceS8EvU9vxvgY_DVneweAP5ZsxQ-MBcB$>
(*) 3 weeks to account for the IETF meeting week and the august/summer period.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 14 Sep 2020 09:40:41 +0000

Hi Shraddha,

Thanks for your reply.
Please see inline [Bruno]  [/Bruno]

From: spring [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: Friday, September 11, 2020 1:43 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Hi Bruno,

Juniper Business Use Only
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 9, 2020 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Hi authors, all,

1)      I feel that the terminology "node protection"  in the name of the draft could be misleading.

Personally I would propose to replace "Node Protection" by "Segment Protection" or "Segment Egress Protection" or "IGP Segment Egress Protection" since the proposal seem restricted to IGP knowledge.
<Shraddha> I agree that using the term node protection is confusing. I think that "segment protection" is the  right  term.
[Bruno] works for me.

  Using egress keyword may cause other confusions because term egress is used in egress protection RFCs to mean the egress nodes on which the services reside. In this draft the focus is on nodes that are not egresses.
[Bruno] Regarding the term "Egress", it looks to me that you're considering the position of the ingress (PE) which is well aware of the distinction between the service egress and the SR policy used to steer on a specific path. From a P/PLR standpoint, I'd argue that the P is forwarding based on the top label and for him, the destination for the label/FEC is the egress. This seem to match the definition from RFC 3031
  In other words, we can speak of the level m LSP for Packet P as the
   sequence of routers:
[...]
3. which ends (at an "LSP Egress") when a forwarding decision is
         made by label Switching on a level m-k label, where k>0

IOW, if there are N labels on a packet, there are N egresses.
https://tools.ietf.org/html/rfc3031#section-3.15

Regarding [Egress Protection] I agree that in general, the text could be read as only protecting a "service".
However I believe that it covers the case of hierarchical transport LSPs:
>From the abstract: "This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures."
>From the introduction: "In MPLS networks, Label Switched Paths (LSPs) are widely used as transport tunnels to carry IP and MPLS services across MPLS domains. Examples of MPLS services are Layer 2 VPNs, Layer 3 VPNs, hierarchical LSPs, and others."
[/Bruno]

Both do not seem to co-operate.
<Shraddha> Actually, egress protection as defined in RFC 8679 works well with procedures defined in this draft. Section 3.4 briefly talks about this.
Initial versions of this draft had examples to describe how egress protection works in conjunction with procedures described in this draft.
Basically, egress protection described in RFC 8679 uses a context-id and context label. When the penultimate hop creates protection for the context-id routes
It follows the procedures described in RFC 8679 ( in conjunction with mirror-sid for SR networks). We also have a simplified version of RFC 8679 which uses anycast SIDs and static service labels
Described in draft-hegde-rtgwg-egress-protection-sr-network. This anycast based egress protection also works well with protection procedures described in this document.
I'll add a section with examples to describe this which can help clarify.
[Bruno] I did read section 3.4 but it just states that RFC 8679 "is applicable". May be adding a section with an example will help, thanks for this.
In the meantime, my concern is that:

-          §3.1 populates the contect label only with SR Prefix & Adjacency SIDs

-          A priori, during the lookup in a MPLS (context) table, if no match is found, the packet is dropped. https://tools.ietf.org/html/rfc3031#section-3.18
Hence my conclusion that the proposition would drop the service packet rather than sending it to a protector node as per RFC 8679.
[/Bruno]

I would propose that the draft refers a bit more to [Egress Protection], uses its terminology if/when appropriate and then elaborate on the above issue. From a technical standpoint, I would propose to privilege the use of a (complete) Protector (as per [Egress Protection] ) if available.
<Shraddha> This draft makes use of looking up the second label in the stack for protection. It is different from protector based approach.
[Bruno] IMHO, conceptually this draft combines both the PLR (first packet lookup) and Protector (second packet lookup) on the same node.
That been said, RFC8679 is a large doc and relatively complex given the general scope that it is trying to achieve, hence making its reading mandatory would probably add complexity for little benefit. Yet, since you have a section dedicated on Egress Protection (§3.4) may be a better description of how both document interact may be useful. Up to you.
draft-hu-spring-segment-routing-proxy-forwarding Is more closer to protector based approach I think. It comes with an overhead of  configuring the
primary and proxy pairs for set of nodes.

Finally, as also raised by Zhibo, the scalability properties of the draft is not optimal, and in particular less optimal than [Egress Protection].
<Shraddha>I'll add some more text on scalability.  Section 5 of the draft proposes an optimisation to reduce scale.
[Bruno] ok, thanks.
[/Bruno]
Indeed, most of the work/states is on a Protector node (having the context mpls forwarding table). For a given failure, [Egress Protection] allows for a single Protector while this drafts requires N Protectors (one per neighbour). So more states in the network and on nodes. Also [Egress Protection] allows to distribute this load while the draft requires the PLR to handle the protection for all its neighbhors.
Since this draft restricts to IGP Segments, the scalability impact his limited but still exist.
(on the pro side, the draft avoids the additional transport cost/delay required to reach the Protector (since PLR and Protector are co-located)/
<Shraddha> Fair point. I would see the advantage of this draft is more from operational perspective since it does not require primary protector configs.
Enabling the feature with one single knob on the router will be good enough.
[Bruno] In addition, this draft is better in term of incremental deployment with incremental benefit as you have an incremental benefit with the first new node.
In some cases, it could be seen a providing a better delay/jitter as it does not add the extra path up to the protector. (but this is very deployment specific)
Thanks,
--Bruno
[/Bruno]

Regards,
Bruno

Hi SPRING WG,

Thanks,
Regards,
Bruno, Jim, Joel

Thank you.

Thank you.