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 <spring-boun...@ietf.org> on behalf of bruno.decra...@orange.com
<bruno.decra...@orange.com>
Sent: Thursday, February 24, 2022 6:17 AM
To: SPRING WG <spring@ietf.org>
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 <spring-boun...@ietf.org> On Behalf Of bruno.decra...@orange.com
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG <spring@ietf.org>
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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
