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

[Huaimo Chen <[e-mail]>]

Hi Bruno,

    Thank you very much for your valuable points and comments.

    Your points are addressed in the updated draft and
    my responses/explanations inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors

________________________________
From: spring <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: Thursday, February 24, 2022 6:17 AM
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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hu-spring-segment-routing-proxy-forwarding&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cd6bcf622173e4c4d5ced08d9f787462c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812982662302147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=r50yMfeiqwv2LeBUsUfsYKCw%2FFU2UREh7FLQY4I7o7k%3D&reserved=0>

[2] https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protection-sr-te-paths<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-spring-segment-protection-sr-te-paths&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cd6bcf622173e4c4d5ced08d9f787462c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812982662302147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EmDWy0AmKdEUyjT7o18DaylcysX56Tr4Qga1wgNOCFc%3D&reserved=0>



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).

[HC]: Re-using the existing Mirror SID is added into the draft.

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.

[HC]: For an IS-IS CS-LSP (Circuit Scoped LSP) defined in RFC 7356,

it is advertised by its originator to the direct neighbors of the
originator. The neighbors will not advertise the CS-LSP any further.
It seems that there is no IGP (IS-IS) scalability issue here.


- 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.

[HC]: It seems that our draft does not advertise any backup state in

the IGP. The normal states (i.e., the shortest path to each destination
computed based on the current topology/LSDB) are installed normally
by the IGP. This is independent of the protocol extensions if any.
Only for the destination/SID of the failed node, which is not reachable
through the current topology/LSDB (i.e., there is no path to the
destination/SID of the failed node in the current network after the
IGP converges on the current network with the failure), the backup
state (the shortest path to the proxy destination/SID of the failed
node, i.e., the proxy node of the failed node) is installed.



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.

[HC]: The backup states on the PLR (i.e., the backup forwarding

table/entries for a failed node on the proxy neighboring node P
as PLR of the failed node) are those described in our draft.
When P as PLR receives the packet with the destination/SID of the
failed node, P uses the backup forwarding table for the failed node
to do a SR proxy forwarding for the failed node and forward the
packet towards its final destination without going through the
failed node. This is independent of re-using the existing protocol
or using some new protocol extensions.
If the neighboring node P of the failed node does not support proxy
forwarding (i.e., P does not have the capability of doing proxy
forwarding for the failed node), after receiving the packet with
the destination/SID of the failed node, P will do normal FRR.
The normal FRR on P includes one of the following two cases:
1). P's neighbor supports the proxy forwarding indicated by the
mirror SID for the failed node advertised by the neighbor:
P pushes the mirror SID into the packet and forwards the packet
to the neighbor, which uses the mirror SID for the failed node
as context to the backup forwarding table/entries for the failed node
to do a SR proxy forwarding for the failed node and forward the
packet towards its final destination without going through the
failed node. In this case, any binding SID of the failed node is
also protected since the neighbor supports the proxy forwarding.
2). P's neighbor does not support the proxy forwarding:
P forwards the packet with the SID of the failed node towards its
final destination without going through the failed node. In this
case, any binding SID of the failed node is not protected since P

does not support the proxy forwarding.



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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hu-spring-segment-routing-proxy-forwarding%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cd6bcf622173e4c4d5ced08d9f787462c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812982662302147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a2MX%2BVf%2Bxf64sl3tYWOhH84AsPJOBP0pysX%2BbtttGWc%3D&reserved=0>



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.