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

[[e-mail]]

Dear WG,

A year ago, we initiated a call for adoption on draft-hu-spring-segment-routing-proxy-forwarding [proxy-forwarding].

The summary of the technical points of the discussion has been summarized on the list [1], in particular on the two following aspects:
a) the protection/FRR part (from failure detection to the start of the IGP convergence)
b) the restoration part (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).

[1] https://mailarchive.ietf.org/arch/msg/spring/_e7gCFQSNcNE-JrVPIFuXxrradU/  (and also below)

Authors of the draft were suggested to dig on some points and in the meantime the call for adoption had been suspended.


Since then, there has been further discussions and progress involving both the WG document and [proxy-forwarding].

In summary:
With regards to "b" (restoration) both drafts were proposing a different solution to cross the part of the network experiencing changes/IGP convergence. Following WG discussions,
- authors of the WG document agreed to move to a third solution (near side tunneling) addressing the comments raised.
- authors of [proxy-forwarding] agreed to remove the new IGP extension and re-use the existing mirror SID. They also agreed that this is optional.

Hence chairs are considering that the discussion on "b" has been resolved, pending the WG document to be updated to reflect this.

With regards to "a", "a" was already addressed by the WG document with the exception of the binding SID.
Following WG discussions:
- authors of [proxy-forwarding] have removed the IGP extension and published two drafts for PCEP and BGP extensions for consideration by the relevant WGs.
- editor of the WG document has agreed to add a sentence clarifying that this part was not covered in the WG document and that in order to protect binding-SID, the protector would need to learn the binding SID of the protected node through some signaling out of scope of the draft.

Hence chairs are considering that the discussion on "a" has been resolved. Further work on the signaling is to be done in the PCEP & IDR WGs. If common aspects are ever to be specified by the SPRING WG, the easiest option seems to add a couple of sentence in the WG document.

Given this, we are closing the adoption call on draft-hu-spring-segment-routing-proxy-forwarding and we are not adopting it.

Best regards,
Joel, Jim, Bruno




Orange Restricted
From: spring <[e-mail]> On Behalf Of [e-mail]
Sent: Thursday, February 24, 2022 12:17 PM
To: SPRING WG <[e-mail]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

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.


From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG <[e-mail]<mailto:[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.