Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

[[e-mail]]

Dear WG,

Thank you for all comments received during this WG last call and for the detailed review of the document.

In term of requirement, there is support for the need to protect SR-Policy traffic from node failure both:
a) for the protection/FRR duration (from failure detection to the start of the IGP convergence)
b) during the subsequent IGP restoration (from the beginning of the IGP convergence in the routing domain to the end of the re-computation and installation of SR-policy on all ingress).

"a" is addressed by [2], with the exception of binding SIDs.

Regarding "b", in term of the solution, two aspects have been discussed:
I) the relation with the solution proposed in [2]
II) the IGP extension for Proxy Forwarding proposed in [1]

[1] https://datatracker.ietf.org/doc/html/draft-hu-spring-segment-routing-proxy-forwarding
[2] https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protection-sr-te-paths

I) Regarding the relation with the solution proposed in [2]:
- there is a claim that [1] provides better benefits in terms of incremental deployment. During discussions it appeared to be true in some cases but that the increased benefit seems relatively limited
- there has been a claim that [2] already solves the problem. During discussions, it appeared that the solution proposed in [2] does not seem to work as claimed.
- problem space is twofold: a local fast reroute solution "a" and a global IGP rerouting solution "b". In principle, both may be described in a single or two documents.

II) Regarding the IGP extension proposed in [1], the discussion during this adoption call has not clarified the need to define a new IGP extension compared to re-using the existing Mirror SID defined in RFC 8402 (SR Architecture) and RFC 8667 (IS-IS extension).
Authors of [1] are suggested to dig on this point.
In the meantime, the need for a new IGP extension for Proxy Forwarding has not been demonstrated.


Coming back to "a", [1] also covers a solution for the FRR protection of binding SIDs.
The problem seems real for networks using binding SIDs. The document proposes to advertise them in IGP. However, during discussions, it appears that:
- main IS-IS PDU (hello, LSP) are not well suited for the requirements (scope of messages, capability of messages, scaling). During the call, the document has been changed to using CS-LSP which may not be well deployed and does not fully address the IGP scalability point.
- it seems debatable to choose to advertise the backup states in the IGP when the nominal states have not been installed by the IGP but through existing protocols extensions.

Authors of [1] are suggested to dig on this point and study in depth the existing configuration/signaling protocols used to install the nominal path and study how they can be used, including extended if needed, to address the need to install the backup states on the PLR.

In the meantime, the call for adoption of draft-hu-spring-segment-routing-proxy-forwarding is suspended.

Finally, there is the question of whether these different aspects are better addressed in one document or in two documents.
This will be further evaluated by chairs when we'll have a revised [1] document addressing the two requested points. However we note that [1] covers both a global IGP aspect (restoration) and a local restoration aspect (binding SID) hence having two documents based on this dichotomy would not even solve the interactions between the two documents. In addition,  _assuming that [1] does its homework and fully addresses the two above points_, if they wish so, authors of both documents may discuss and may come back with proposals on how to structure the whole solution space.

Yours,
--Bruno, Jim, Joel.



Orange Restricted
From: spring <[e-mail]> On Behalf Of [e-mail]
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG <[e-mail]>
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Dear WG,

This message starts a 2 week WG adoption call, ending 27/01/2022, for draft-hu-spring-segment-routing-proxy-forwarding
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/

After review of the document please indicate support (or not) for WG adoption of the document to the mailing list.

Please also provide comments/reasons for your support (or lack thereof) as this is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on or review the document, please state this explicitly. This gives the chairs an indication of the energy level of people in the working group willing to work on the document.

Thanks!
Bruno, Jim, Joel

_________________________________________________________________________________________________________________________



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.