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

[Shraddha Hegde <[e-mail]>]

  1.  draft-ietf-spring-node-protection-for-sr-te-paths



"If the Node-SID or Prefix-SID becomes

   unreachable, the event and resulting forwarding changes should not

   communicated to the forwarding planes on all configured routers

   (including PLRs for the failed node) until the hold-timer expires."



  *   It's not crystal clear to me how it would work in reality, so I would welcome more prescriptive text. In particular:
     *   "node failure" is not an IGP message. IGP nodes sees multiple "adjacency loss" messages which are not atomic and could be handled in multiple SPFs. Hence different nodes will freeze their FIB based on a different topology (link1 for some, link2 for others) leading to inconsistent routing and forwarding loops.
     *   How is the FIB modified in cases of consecutives IGP events? (freezed on hold topology may lead to drops, updating entries would need to be specified.
  *   On a side node, this text requires a global behavior of all IGP nodes. That seem a bit out of scope of a non-normative sentence, in an informational document, describing a local behavior on the PLR.

 [HC]: In addition to the above, it seems better to describe procedures
about link/node up and down events regarding to FIB entries such as
those being held off (not to be changed) during the period from
HoldTimer start to end. For example, after a node is down, some FIB
entries are held off (not to be changed), then the node is up, but
some of its links are up and the other links are still down (maybe
for a long time). How to handle the FIB entries (hold off or change)
in this case?
<SH> Good point. Will add more details in the next revision.



Juniper Business Use Only
From: spring <[e-mail]> On Behalf Of Huaimo Chen
Sent: Thursday, February 3, 2022 10:35 PM
To: [e-mail]; 'SPRING WG' <[e-mail]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

[External Email. Be cautious of content]

Hi Bruno,

    Thank you very much for your valuable comments.

    My responses/explanations are inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors


________________________________
From: spring <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, February 2, 2022 8:26 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; 'SPRING WG' <[e-mail]<mailto:[e-mail]>>; Huzhibo <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding


Hi authors of both documents, WG,



[Speaking as individual contributor.]



It's good to see technical discussions on the restoration of failed SIDs used by SR policy.



  1.  From a functional point of view, can we summarize the benefit to signal the node proxy capability?

e.g.

- drop the traffic earlier if the PLR does not support proxy capability. (helps with congestion)

[HC]: When the PLR supports proxy capability, it provides protection
for the failure of its adjacent node with BSIDs. The BSIDs are protected.
When the PLR does not support proxy capability, it provides protection
for the failure of its adjacent node, but the BSIDs on the node are
not protected.

- use another proxy off the shortest path (increase congestion but reduce loss)

[HC]: When there is a node on the shortest path not supporting proxy,
another proxy capable node off the shortest path to a neighbor of the failed
node is used. The traffic is sent to the neighbor, which re-routes the traffic
around the failed node towards the destination. The traffic is protected.
In fact, the failed node is a loose hop on the SR path with the SID of the node.
>From a upstream node to the failed node, there are a few hops in general.
When any of these hops fails, the traffic will be re-routed around
the failure. This should be considered by the controller that computes
the SR path. This should not increase congestion.
Using proxy capable node off the shortest path to a neighbor of the failed
node to some extend should not increase congestion.
Using another proxy capable node off the shortest path reduces traffic
loss and should not increase congestion to some extend.

- possibly help identifying the proxy (nominal is not in the reachable topology anymore)

[HC]: When a node failed and becomes unreachable, it helps identifying
the proxy capable path to a neighbor of the failed node.

...

Or agree on the absence of significant benefits?

[HC]: It provides more protection coverage in some cases as compared to
the other existing draft. This improves the reliability of networks,
and QoE. This should be a significant benefit.
In addition, when a node fails, the nodes of the entire network converge
to the latest state consistently in time.
After a node failed, comparing to the other existing draft regarding to
holding off the FIB during the HoldTimer period,
when the network changes again, our solution continues to converge
at any time.



  1.  draft-ietf-spring-node-protection-for-sr-te-paths



"If the Node-SID or Prefix-SID becomes

   unreachable, the event and resulting forwarding changes should not

   communicated to the forwarding planes on all configured routers

   (including PLRs for the failed node) until the hold-timer expires."



  *   It's not crystal clear to me how it would work in reality, so I would welcome more prescriptive text. In particular:

     *   "node failure" is not an IGP message. IGP nodes sees multiple "adjacency loss" messages which are not atomic and could be handled in multiple SPFs. Hence different nodes will freeze their FIB based on a different topology (link1 for some, link2 for others) leading to inconsistent routing and forwarding loops.
     *   How is the FIB modified in cases of consecutives IGP events? (freezed on hold topology may lead to drops, updating entries would need to be specified.

  *   On a side node, this text requires a global behavior of all IGP nodes. That seem a bit out of scope of a non-normative sentence, in an informational document, describing a local behavior on the PLR.

 [HC]: In addition to the above, it seems better to describe procedures
about link/node up and down events regarding to FIB entries such as
those being held off (not to be changed) during the period from
HoldTimer start to end. For example, after a node is down, some FIB
entries are held off (not to be changed), then the node is up, but
some of its links are up and the other links are still down (maybe
for a long time). How to handle the FIB entries (hold off or change)
in this case?



  1.  draft-hu-spring-segment-routing-proxy-forwarding

Rather than defining a new "Proxy Forwarding" capability in IGP why don't you use the existing Mirroring Segment (from RFC https://datatracker.ietf.org/doc/html/rfc8402#section-5.1<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8402*23section-5.1&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C12af08c51f9646ac60e308d9e64f9c0c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637794051887643063*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=ENHobem9VChu*2Fh2wTK5QXtC60ypc18rRRy9LgMfXz4o*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!Wh6vOAEFBR3Tb0h_k0MIQn3d4QWoyOSeJJM-K1a7U9F30ps1LnMWzO9QRxXqvyDT$>) whose signaling is already standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8667*23section-2.4.1&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C12af08c51f9646ac60e308d9e64f9c0c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637794051887643063*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=*2BpplasnFxP69Ox3kv*2BoqhhsfdS7*2FQUooMyaygZ96f4Y*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Wh6vOAEFBR3Tb0h_k0MIQn3d4QWoyOSeJJM-K1a7U9F30ps1LnMWzO9QRz1kgE0c$>

 [HC]: "Proxy Forwarding" capability of a node may be alternatively
indicated by the mirror SIDs advertised by the node.
Mirror SID for a failed node can be used as context to forward
the traffic with the SID of the failed node to the next hop of the
failed node. A node advertises a mirror SID for each of its neighbor
nodes. When a node failed, its node SID is not reachable.
A remote node of the failed node sends the traffic with the SID of
the failed node to a neighbor of the failed node.
The neighbor sends (i.e., re-route) the traffic to the next hop of
the failed node when the neighbor advertises the mirror SID for the
failed node. When the neighbor does not advertise the mirror SID for
the failed node, it pushes the mirror SID advertised by another
neighbor (say AN) and sends the traffic to AN. AN pops its mirror SID
as context and uses the SID of the failed node to re-route the
traffic to the next hop of the failed node.



  1.  What about the following solution:

  *   Use mirror SID
  *   Tunnel to the "proxy-forwarding" advertising mirror SID

[HC]: If tunnels are used, there may be tunnels from each of the
remote nodes to each of the neighbors of a failed node. This may
use some network resources. It seems that tunnels may be replaced
by the shortest path to the neighbor along the nodes advertising
mirror SIDs.



I would see the following benefits:

  *   No new protocol extensions (cf "3)"
  *   Consistent routing in case of multiple SPFs (cf "2)")
  *   Benefit from the signaling of the proxy (cf "1)")

 [HC]: We can see these.


Thanks,

Regards,

--Bruno





Orange Restricted

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, January 25, 2022 6:13 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; 'SPRING WG' <[e-mail]<mailto:[e-mail]>>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding



Hi,



I'm NOT supporting this draft for the following reasons:



  1.  The WG already have a WG document which is dealing with this problem, I don't think that WG should come with multiple documents/solutions for the same solution space as it may just confuse the industry and create deployment issues as different vendors may pick different solutions.



  1.  Adding protocols extensions adds complexity in the solution without adding a strong value.



The document claims that "[I-D.ietf-spring-segment-protection-sr-te-paths] ... may not work for some cases such as some of nodes in the network not supporting this solution.". While this is true, the proposed solution in draft-hu-spring-segment-routing-proxy-forwarding has exactly the same caveat and requires all nodes in the network to support the solution.



Considering the following straight line network: A -B -C -D - E - F - G -H and an SR policy from A to H using SID_G, routers A to F have to support the extension to make the solution working, if one of the router doesn't support the extension, traffic will be dropped.



Then, there is no value compared to the timer-based solution of [I-D.ietf-spring-segment-protection-sr-te-paths]



Authors of draft-hu-spring-segment-routing-proxy-forwarding argued that G may have multiple upstream neighbors let's say F and F' and the solution allows for F' to support the extension while F may not support, so the solution will send the traffic to F'. Well yes, but this still requires all routers upstream to F' to support this extension and maybe F is on the path to F'. So, I don't think the argument is valid as it may possibly work tactically depending on the network topology when we look at a small portion of the network, but when we look at the whole network, operator will have to upgrade all their nodes to support the extension to ensure the benefit is there.



In addition, in term of traffic, forwarding traffic to a neighbor of the failed node which wasn't initially on the path, could lead to traffic congestion or high traffic peaks on links that were not sized to carry this traffic. We could easily expect some traffic tromboning, where traffic goes to this non-natural neighbor of the failed node and then goes back over some part of the same path before reaching the destination.



So these protocol extensions are bringing complexity for no value here.





  1.  Regarding BSID, I'm not fan of advertising BSIDs in IGP as there may be hundreds or thousands of BSID on a node which again will create a lot of burden in IGP. The proposed way will have to be discussed in LSR, not in SPRING (see next comment).



Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could also work with BSIDs as long as BSID information of failed node is available in the control-plane of PLRs by whatever mechanism. I think this BSID handling is orthogonal to the proxy-forwarding controlplane behavior. The forwarding operations for BSID will have to be discussed more in details, we could not expect all HW to be able to do 3 or 4 lookups without any perf degradation.



  1.  The document is currently a bit borderline between SPRING and LSR as it talks in good details about IGP protocol extensions. If it's a SPRING doc, it should detail reqs for protocols but nothing beyond.







Brgds,



Stephane





From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: jeudi 13 janvier 2022 11:19
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/<https://urldefense.com/v3/__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*7C12af08c51f9646ac60e308d9e64f9c0c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637794051887643063*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=mTBBwsQquqH7GTfnwgHB8BRMndNK3IhgV5fJr7eXx9E*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Wh6vOAEFBR3Tb0h_k0MIQn3d4QWoyOSeJJM-K1a7U9F30ps1LnMWzO9QR70Eukna$>



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.