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

[Shraddha Hegde <[e-mail]>]

Dhruv,

Thanks for the detailed review and comments.

Pls see inline for replies.


Juniper Business Use Only

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

[External Email. Be cautious of content]


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 <[e-mail]> wrote:
>
> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-sp
> ring-node-protection-for-sr-te-paths-07__;!!NEt6yMaO-gk!SLaOSAoItlCpdx
> Ojxp4lwQYk7pKG1Y42tXizJ2oljTOh8n3md5P97QOeGTxjGU8f$
>
> (*) 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.
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!SLaOSAoItlCpdxOjxp4lwQYk7pKG1Y42tXizJ2oljTOh8n3md5P
> 97QOeGa8BZYp4$