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

From: Yimin Shen <[email-masked]>
Date: Mon, 3 Aug 2020 14:21:02 +0000

Support the WG adoption for this document.

Thanks,
-- Yimin Shen

From: spring <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Thursday, July 30, 2020 at 8:24 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

[External Email. Be cautious of content]

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<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07__;!!NEt6yMaO-gk!Vx6mNp2UQ9shRIPWwJ7x5_ow58S9Obzc3GOnp1keA3cHDSiTG-JmYDQyw0Ig-lc$>
(*) 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.

Juniper Business Use Only

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Mon, 3 Aug 2020 21:00:18 +0200

Support for adoption.

The draft covers important piece of the missing puzzle in the overall SR protection story.

Thanks,
Krzysztof

> From: spring <[email-masked] <mailto:[email-masked]>> on behalf of "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> [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!Vx6mNp2UQ9shRIPWwJ7x5_ow58S9Obzc3GOnp1keA3cHDSiTG-JmYDQyw0Ig-lc$>
> _______________________________________________
> spring mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 4 Aug 2020 10:46:58 +0530

Hi WG,

Support the adoption of this draft. However I think some text should be
added to explain it's interaction with
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments.

Authors,

If you prefer, I can provide some text for your perusal.

Thanks and regards,
-Pushpasis

On Thu, Jul 30, 2020 at 5:55 PM <[email-masked]> wrote:

> 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
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 4 Aug 2020 17:48:21 +0000

Hi Pushpasis,

Thanks for the review and comments.

Pls check if the below text looks good.

"
draft-ietf-spring-mpls-anycast-segments proposes a mechanism to allow the use of anycast SIDs in a network
where all devices do not share a common SRGB.  draft-ietf-spring-mpls-anycast-segments utilizes the concept of
a virtual LFIB, which is an application of  the concept of Context-Specific Label Spaces [RFC5331].  The current draft
uses the mechanism of context tables, a different application of Context-Specific Label Spaces, to facilitate node
protection.  The current draft does not make provisions to support the virtual LFIB mechanism together with
node protection context tables.  The use of anycast-SIDs together with anycast-aware TI-LFA provides effective
protection against node failure.  Therefore, when SRTE paths are constructed using anycast-SIDs, the anycast-SIDs
may not require node protection via context tables. "

Rgds
Shraddha

Juniper Business Use Only
From: Pushpasis Sarkar <[email-masked]>
Sent: Tuesday, August 4, 2020 10:47 AM
To: Bruno Decraene <[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,

Support the adoption of this draft. However I think some text should be added to explain it's interaction with https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments__;!!NEt6yMaO-gk!WSdKaLoKoizMDGgGGY18Ts9fecEVjMTPM1qV80owypiCqJeM3clobB2odRfosxGC$>.

Authors,

Thanks and regards,
-Pushpasis

On Thu, Jul 30, 2020 at 5:55 PM <[email-masked]<mailto:[email-masked]>> wrote:
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!WSdKaLoKoizMDGgGGY18Ts9fecEVjMTPM1qV80owypiCqJeM3clobB2odeRL1YEg$>
(*) 3 weeks to account for the IETF meeting week and the august/summer period.

Thank you.
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!WSdKaLoKoizMDGgGGY18Ts9fecEVjMTPM1qV80owypiCqJeM3clobB2odX_jSQlh$>

---

From: Aditya Kaul <[email-masked]>
Date: Wed, 5 Aug 2020 12:52:06 +0800

Support the WG adoption.

Regards,
Aditya

> On Jul 30, 2020, at 8:24 PM, [email-masked] wrote:
> 
> Hi SPRING WG,
>  
> [1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07 <https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07>

---

From: Martin Horneffer <[email-masked]>
Date: Thu, 13 Aug 2020 16:02:34 +0200

Hi Shraddha, Pushpasis,

it's a very good point to see this interaction being documented. Thank you!
I support it.

Best regards, Martin

Am 04.08.20 um 19:48 schrieb Shraddha Hegde:
> “
> where all devices do not share a common SRGB.  
> draft-ietf-spring-mpls-anycast-segments utilizes the concept of
>
> a virtual LFIB, which is an application of  the concept of 
> Context-Specific Label Spaces [RFC5331].  The current draft
>
> uses the mechanism of context tables, a different application of 
> Context-Specific Label Spaces, to facilitate node
>
> protection against node failure. Therefore, when SRTE paths are 
> constructed using anycast-SIDs, the anycast-SIDs
>
> may not require node protection via context tables. “
>
> Rgds
>
> Shraddha
>
> *From:* Pushpasis Sarkar <[email-masked]>
> *Sent:* Tuesday, August 4, 2020 10:47 AM
> *To:* Bruno Decraene <[email-masked]>
> *Cc:* [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 WG,
>
> Support the adoption of this draft. However I think some text should 
> be added to explain it's interaction with 
> https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments 
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments__;!!NEt6yMaO-gk!WSdKaLoKoizMDGgGGY18Ts9fecEVjMTPM1qV80owypiCqJeM3clobB2odRfosxGC$>. 
>
>
> Authors,
>
> On Thu, Jul 30, 2020 at 5:55 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi SPRING WG,
>
>     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://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07__;!!NEt6yMaO-gk!WSdKaLoKoizMDGgGGY18Ts9fecEVjMTPM1qV80owypiCqJeM3clobB2odeRL1YEg$>
>
>     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,
>
>     This message and its attachments may contain confidential or
>     privileged information that may be protected by law;
>
>     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.
>
>     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!WSdKaLoKoizMDGgGGY18Ts9fecEVjMTPM1qV80owypiCqJeM3clobB2odX_jSQlh$>
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 13 Aug 2020 11:16:45 -0700

yes/support

Cheers,
Jeff
On Jul 30, 2020, 5:25 AM -0700, [email-masked], wrote:
> [1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 Aug 2020 16:27:52 -0400

I reviewed the draft and support WG adoption.

Thank you

Gyan

On Thu, Aug 13, 2020 at 2:17 PM Jeff Tantsura <[email-masked]>
wrote:

> https://tools..ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07
> <https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 13 Aug 2020 22:58:54 -0500

Strongly support adoption -- the document addresses an important missing
piece of functionality (also helps that the document is more than
sufficiently baked for the WG to take it forward).

Regards,
-Pavan

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Aug 2020 10:20:50 +0200

I support the adoption of this draft. It is Informational and provides set
of guidance to implementations.

Reading it quickly I think I am not seeing a section or exception in
handling cases where next sid is a binding sid.Skipping it may break the
game.

Also section 2.3 is IMO debatable. I know some which would prefer to drop
rather then go direct between R3 & R4 as there can be already much more
important traffic taking that link. So just always applying node protection
based on processing of next SID may not always be a desired behaviour. I
think to some level Joel's recent messages discussed similar concerns.

Thx a lot,
R.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 14 Aug 2020 12:24:51 +0000

Hi All,

I believe this topic is relevant and something for the WG to adopt and work on.

I have some concerns though on it's applicability and more specifically it's implications on existing deployments/use-cases. I've share the same on the thread started by Joel on this specific aspect [1]. Some discussion and clarity on this would help before adoption.

One other bit, for the example in Sec 2.3, perhaps some text is required to clarify that this applies only for segments signalled via IGPs and if the 9054 was a BSID or BGP-EPE SID then this approach would not work. May I suggest to add a section 2.4 to capture these aspects (it would be some what on the lines of Sec 3.4 but not related to the context table solution).

The document is well-written and detailed. It does a very good job of describing the node protection scenarios and options.

Thanks,
Ketan

[1] https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/

From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: 30 July 2020 17:55
To: [email-masked]
Cc: [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

Thank you.

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 15 Aug 2020 02:24:18 -0400

I support WG adoption adoption of this draft.

For operators moving towards SR technology, RSVP FRR is widely deployed by
operators, so SR node protection is a critical feature for operators.

>From the thread started by Joel Halpern I think path protection is as well
critical to operators.

With regards to SR FRR node protection,  how does TI-LFA FRR work in
conjunction with SR FRR node protection for the  same PLR junction to the
merge point bypass loop.

Is the concept of context table a requirement for node FRR as it will
consume more resources.  In the bypass loop if their is only one next next
hop path Neighbor or a few would a context table be necessary.  For the
node protection this does seem similar conceptually to RSVP node protection
with the additional label to signal lsp  to the merge point.

Kind Regards

Gyan

On Fri, Aug 14, 2020 at 8:25 AM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> I have some concerns though on it’s applicability and more specifically
> it’s implications on existing deployments/use-cases. I’ve share the same on
> the thread started by Joel on this specific aspect [1]. Some discussion and
> clarity on this
>
> would help before adoption.
>
>
>
>
>
> One other bit, for the example in Sec 2.3, perhaps some text is required
> to clarify that this applies only for segments signalled via IGPs and if
> the 9054 was a BSID or BGP-EPE SID then this approach would not work. May I
> suggest to add
>
> a section 2.4 to capture these aspects (it would be some what on the lines
> of Sec 3.4 but not related to the context table solution).
>
>
>
>
>
> The document is well-written and detailed. It does a very good job of
> describing the node protection scenarios and options.
>
>
>
>
>
> Thanks,
>
>
> Ketan
>
>
>
>
>
> [1]
>
> https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/
>
>
>
>
>
>
>
>
>
> *From:* spring <[email-masked]>
>
> *On Behalf Of [email-masked]
>
>
>
>
> *Sent:* 30 July 2020 17:55
>
>
> *To:* [email-masked]
>
>
> *Cc:* [email-masked]
>
>
> *Subject:* [spring] WG adoption call for

*Gyan Mishra*

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 17 Aug 2020 05:52:45 +0000

Hi Gyan,

Thank you for the support.
Pls see inline or replies

Juniper Business Use Only
From: Gyan Mishra <[email-masked]>
Sent: Saturday, August 15, 2020 11:54 AM
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

For operators moving towards SR technology, RSVP FRR is widely deployed by operators, so SR node protection is a critical feature for operators.

>From the thread started by Joel Halpern I think path protection is as well critical to operators.

With regards to SR FRR node protection,  how does TI-LFA FRR work in conjunction with SR FRR node protection for the  same PLR junction to the merge point bypass loop.
<Shraddha>SR path consists of a stack of labels. At any node the forwarding in based on top label.
When there is node failure, the PLR of the failure node applies the procedures described in drat-hegde-spring-node-protection-for-sr-te-paths When the top label is adjacency SID or when the top label is a node-sid which is the nexthop.
If the top label is a node-sid which is multiple hops away TI-LFA protection is applied.

Is the concept of context table a requirement for node FRR as it will consume more resources.
<shraddha> It is not absolutely necessary. Section 5 of the draft explains a mechanism that does not use context tables.

In the bypass loop if their is only one next next hop path Neighbor or a few would a context table be necessary.
<shraddha> Context table is generally necessary if the SRGB in the network is not uniform and if there are locally significant adjacency-sids used in the network. Since SR uses IGP SIDs and the paths for the labels change based on cost change etc
The concept of next-nexthop is very dynamic. The recommendation is to use non context table based solution only when the
Whole network has same SRGB and  has global adj-sids deployed.

For the node protection this does seem similar conceptually to RSVP node protection with the additional label to signal lsp  to the merge point.
<shraddha> You are right, this draft solves the same problem that RSVP node-protection solved.
Kind Regards

Gyan

On Fri, Aug 14, 2020 at 8:25 AM Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

I have some concerns though on it's applicability and more specifically it's implications on existing deployments/use-cases. I've share the same on the thread started by Joel on this specific aspect [1]. Some discussion and clarity on this

One other bit, for the example in Sec 2.3, perhaps some text is required to clarify that this applies only for segments signalled via IGPs and if the 9054 was a BSID or BGP-EPE SID then this approach would not work. May I suggest to add

a section 2.4 to capture these aspects (it would be some what on the lines of Sec 3.4 but not related to the context table solution).

Thanks,

Ketan

[1]

https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/__;!!NEt6yMaO-gk!QzQI1170ozGt2-POB1lhKY0DsjgDQPWB4RHkvxot707UY1_o3x7ZuestASWY56dz$>

From: spring <[email-masked]<mailto:[email-masked]>>

On Behalf Of [email-masked]<mailto:[email-masked]>

Sent: 30 July 2020 17:55

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

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

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!QzQI1170ozGt2-POB1lhKY0DsjgDQPWB4RHkvxot707UY1_o3x7ZuestAXKFzg0B$>

Thank you.

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QzQI1170ozGt2-POB1lhKY0DsjgDQPWB4RHkvxot707UY1_o3x7ZuestARYLRezd$>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!QzQI1170ozGt2-POB1lhKY0DsjgDQPWB4RHkvxot707UY1_o3x7ZuestAXMBxTLz$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 17 Aug 2020 06:44:32 +0000

Hi ketan,

Thanks for the review and suggestion.

I'll add a section on B-SID and EPE SID in the next revision.

Rgds
Shraddha

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Friday, August 14, 2020 5:55 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Hi All,

Thanks,
Ketan

[1] https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/__;!!NEt6yMaO-gk!WUff9-QZJE06_mQ6lmrdCs1sBxXTank0sdFrYyQ9cMhWdXeopnx_CGRWmNWJyfqi$>

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 30 July 2020 17:55
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!WUff9-QZJE06_mQ6lmrdCs1sBxXTank0sdFrYyQ9cMhWdXeopnx_CGRWmMlJwq_a$>
(*) 3 weeks to account for the IETF meeting week and the august/summer period.

Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 20 Aug 2020 19:37:50 +0530

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.
- Section 6, I feel we should at least add a reference to Section 8.1
of RFC 8402 [ https://tools.ietf.org/html/rfc8402#section-8.1 ] 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 :)?
- 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
- Section 5 could use an example to describe the concept clearly

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.

Thanks!
Dhruv