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

From: <[email-masked]>
Date: Wed, 2 Feb 2022 13:26:02 +0000

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)
- use another proxy off the shortest path (increase congestion but reduce loss)
- possibly help identifying the proxy (nominal is not in the reachable topology anymore)
...
Or agree on the absence of significant benefits?

  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.

  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) whose signaling is already standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1

  1.  What about the following solution:

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

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

Thanks,
Regards,
--Bruno

Orange Restricted
From: [email-masked] <[email-masked]>
Sent: Tuesday, January 25, 2022 6:13 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; 'SPRING WG' <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: jeudi 13 janvier 2022 11:19
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
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.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 3 Feb 2022 17:04:49 +0000

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 <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, February 2, 2022 8:26 AM
To: [email-masked] <[email-masked]>; 'SPRING WG' <[email-masked]>; Huzhibo <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

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

e.g.

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

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

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

…

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

“If the Node-SID or Prefix-SID becomes

   (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?

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://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>) whose signaling is already standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1<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>

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

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

  *   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

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.

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.

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.

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

  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

Dear WG,

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%7C12af08c51f9646ac60e308d9e64f9c0c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637794051887643063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=mTBBwsQquqH7GTfnwgHB8BRMndNK3IhgV5fJr7eXx9E%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 7 Feb 2022 04:09:26 +0000

Bruno,

Snipped...

  *   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.
<SH> I will add text to capture this point and also add detailed text on possible solutions.

<SH> Agreed.

  *   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.
<SH> I don't think we need any protocol extension for solutions described in this document but if  WG thinks it should be a standard rather than informational
we should upgrade this document status IMO.

Rgds
Shraddha

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, February 2, 2022 6:56 PM
To: [email-masked]; 'SPRING WG' <[email-masked]>; Huzhibo <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

[External Email. Be cautious of content]

  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:/datatracker.ietf.org/doc/html/rfc8402*section-5.1__;Iw!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oKxHlihC$>) whose signaling is already standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8667*section-2.4.1__;Iw!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oLCHtOYr$>

  *   Use mirror SID

Thanks,
Regards,
--Bruno

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

Hi,

Brgds,

Stephane

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:/datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/__;!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oKTgLzsj$>

Thanks!
Bruno, Jim, Joel

Thank you.

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 7 Feb 2022 04:33:22 +0000

<SH> Good point. Will add more details in the next revision.

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

Hi Bruno,

Best Regards,
Huaimo
on behalf of co-authors

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

e.g.

...

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

  *   Use mirror SID

 [HC]: We can see these.

Thanks,

Regards,

--Bruno

Orange Restricted

Hi,

Brgds,

Stephane

Dear WG,

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

Thanks!

Bruno, Jim, Joel

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 8 Feb 2022 11:01:25 +0000

[speaking as WG contributor]

Hi authors, all

I have some comments specific to the binding SID aspect.

§2
"   For a binding segment of a possible failed node, the node advertises
   the information about the binding segment, including the binding SID
   and the list of SIDs associated with the binding SID, to its direct
   neighbors only.  Note that the information is not advertised in the
   network domain. »

§3.2.2

   "For supporting binding SID proxy forwarding, a new IS-IS TLV, called

   Binding Segment TLV, is defined.  It contains a binding SID and a

   list of segments (SIDs).  This TLV may be advertised in IS-IS Hello

   (IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP)

   [RFC7356<https://datatracker.ietf.org/doc/html/rfc7356>]. »

>From an IS-IS standpoint, it seems to me that:

-    Advertising it in the LSP PDU would flood the information in the whole area/level, hence does not match the goal stated in §2

-    Advertising it in the Hello PDU is not a reliable way to sync information (except if duplicated in all hello which implies others issues such as lack of space) and adding the reliability seem like a major change to IS-IS

In all cases, as already raised by Stéphane, this is a subject for the LSR WG.

More importantly, the binding SIDs are probably coming from "somewhere" such as configuration, PCE, BGP, BGP-LS... Why not using the exact same signaling to duplicate it on the neighbors? (this may probably require some extensions for some protocols but a priori light ones and would not impact the IGP with information which may not belong to the IGP.)

Thanks,
Regards,
--Bruno

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

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 8 Feb 2022 13:38:25 -0800

Dear Authors, et al.,
I've read the draft and would appreciate it if the authors can clarify one
question:

   - What do you consider as the significant advantage of the mechanism
   defined in your draft compared with the mechanism defined in
   draft-ietf-spring-segment-protection-sr-te-paths?

As I've compared the two solutions, I couldn't find any significant
advantage of the proxy forwarding to have two standardized mechanisms for
SR path e2e protection. It might be reasonable to have one standard while
other proposals get experimental status?

Regards,
Greg

On Thu, Jan 13, 2022 at 2:19 AM <[email-masked]> wrote:

> Dear WG,
>
>
>
> This message starts a 2 week WG adoption call, ending 27/01/2022, for
> 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
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 9 Feb 2022 01:48:00 +0000

Hi Bruno,

Best Regards,
Huaimo
on behalf of co-authors
________________________________
From: [email-masked] <[email-masked]>
Sent: Tuesday, February 8, 2022 6:01 AM
To: [email-masked] <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi authors, all

§2

“   For a binding segment of a possible failed node, the node advertises

   network domain. »

§3.2.2

   “For supporting binding SID proxy forwarding, a new IS-IS TLV, called

   [RFC7356<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7356&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3bdfa9878fe446f8400c08d9eaf25fb3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799148995699216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bQ9%2FdRR2rDhNWV4KYFkKhJ%2BO8xzw6d7JU9ZNc%2Btg3zU%3D&reserved=0>]. »

[HC]: We will remove IS-IS Hello (IIH) PDUs and LSPs, and update the
related text accordingly.

More importantly, the binding SIDs are probably coming from “somewhere” such as configuration, PCE, BGP, BGP-LS… Why not using the exact same signaling to duplicate it on the neighbors? (this may probably require some extensions for some protocols but a priori light ones and would not impact the IGP with information which may not belong to the IGP.)

[HC]: Using the same signaling (configuration, PCE, or BGP, ...) to

duplicate it on the neighbors works well if there are sessions between
the neighbors and PCE, or BGP, ...

Thanks,

Regards,

--Bruno

Orange Restricted

Dear WG,

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%7C3bdfa9878fe446f8400c08d9eaf25fb3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799148995699216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pkRnDva6Nk0r10gE7Z3Nj1e7w6Rz187cj6gsrJ5aBrk%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

Thank you.

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 9 Feb 2022 02:35:23 +0000

Hi Greg,

    Thank you very much for your comments.

Best Regards,
Huaimo
on behalf of co-authors

________________________________
From: spring <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Dear Authors, et al.,
I've read the draft and would appreciate it if the authors can clarify one question:

  *   What do you consider as the significant advantage of the mechanism defined in your draft compared with the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths?

As I've compared the two solutions, I couldn't find any significant advantage of the proxy forwarding to have two standardized mechanisms for SR path e2e protection. It might be reasonable to have one standard while other proposals get experimental status?
[HC]: It provides more protection coverage in some cases as compared to
the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths.
This improves the reliability of networks, and QoE. This should be a
significant advantage. There is no solution for BSID protection in the
other existing draft. The solution for BSID protection in our draft has
been there for a few years. In addition, after a node failed, in
our solution, the nodes of the entire network converge to the latest
state consistently in time. After a node failed, the mechanism defined
in the other existing draft holds off the FIB during the HoldTimer
period configured, when the network changes again, our solution continues
to converge at any time.
The mechanisms in two drafts are different. It seems ok and reasonable
to have the two drafts to be adopted in the WG.

Regards,
Greg

On Thu, Jan 13, 2022 at 2:19 AM <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG,

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%7Cac2dd1d7357c4424598c08d9eb4b66bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799531373515436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TG7KuyAlTpbdIQksgm0QoKY%2FBYcNcmBvBlijQqaCPXE%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cac2dd1d7357c4424598c08d9eb4b66bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799531373515436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ktnbwc0TVvPj70GbJNAst9BIAP9W0T1yS6SxQulvH2s%3D&reserved=0>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 8 Feb 2022 20:25:43 -0800

Hi Huaimo,
thank you for the expedient response. Please find my follow-up notes
in-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen <[email-masked]>
wrote:

> ------------------------------
> *From:* spring <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Sent:* Tuesday, February 8, 2022 4:38 PM
> *To:* Bruno Decraene <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>
> *Subject:* Re: [spring] WG adoption call -
GIM>> I find it hard to quantify your characterization. I imagine that if
an operator uses the protection mechanism defined in
draft-ietf-spring-segment-protection-sr-te-paths it designs the network
with that in mind and thus minimizes if not completely avoids any possible
limitation the protection mechanism may have. Perhaps you can help with
some more specific scenarios.

> other existing draft.
GIM>> Though BSID may be used inside the network, I find such use case
questionable making no significant impact on the usefulness of the
protection mechanism.

> The solution for BSID protection in our draft has
> period configured, when the network changes again,
>
GIM>> I consider that property of the protection defined in
draft-ietf-spring-segment-protection-sr-te-paths as a benefit that allows
better control for the proper coordination between protection mechanisms
that operate on different network layers.

> our solution continues
GIM>> I agree with you, drafts are fundamentally different and, in my
opinion, merging them would not change the situation. But I don't see that
as the justification for producing two standards. It seems to me, releasing
two standard-based specifications might be detrimental and I propose the
authors consider taking this draft onto the experimental track. I'd support
the adoption of it as the experimental track document.

> <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%7Cac2dd1d7357c4424598c08d9eb4b66bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799531373515436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TG7KuyAlTpbdIQksgm0QoKY%2FBYcNcmBvBlijQqaCPXE%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cac2dd1d7357c4424598c08d9eb4b66bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799531373515436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ktnbwc0TVvPj70GbJNAst9BIAP9W0T1yS6SxQulvH2s%3D&reserved=0>
>
>

---

From: <[email-masked]>
Date: Wed, 9 Feb 2022 13:52:55 +0000

Shraddha,

Many thanks for your replies.
Some minor follow up inline [Bruno]

Orange Restricted
From: Shraddha Hegde <[email-masked]>
Sent: Monday, February 7, 2022 5:09 AM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]; 'SPRING WG' <[email-masked]>; Huzhibo <[email-masked]>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Bruno,

Snipped...

[Bruno] Good. Thanks. Looking forward for the revised draft.

[Bruno] To clarify, I had in mind the implementation/roadmap and deployability aspects: the FRR/context table feature might not be implemented by some vendors/platforms, including for some hardware dataplane capability limitations; while the IGP restoration part would need to be implemented by all IGP nodes. So as a network operator, for the latter (IGP restoration) I would need to ask for the support of the RFC on all nodes, while for the former (FRR) some vendors could not be able to implement the RFC. This would result in a blocked situation preventing deployment. In one way, that's an editorial point. In another way, in a FRR feature which is local by nature, one can't ask for a new behavior on other nodes (not to mention all other nodes in the IGP).

Thanks,
Regards,
--Bruno

Rgds
Shraddha

To: [email-masked]<mailto:[email-masked]>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>; Huzhibo <[email-masked]<mailto:[email-masked]>>

  *   Use mirror SID

Thanks,
Regards,
--Bruno

Orange Restricted

Hi,

Brgds,

Stephane

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

Thank you.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 10 Feb 2022 03:41:10 +0000

Hi Greg,

    Thank you very much for your notes.

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

Best Regards,
Huaimo

________________________________
From: Greg Mirsky <[email-masked]>
Sent: Tuesday, February 8, 2022 11:25 PM
To: Huaimo Chen <[email-masked]>
Cc: Bruno Decraene <[email-masked]>; SPRING WG <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi Huaimo,
thank you for the expedient response. Please find my follow-up notes in-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best Regards,
Huaimo
on behalf of co-authors

________________________________
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Dear Authors, et al.,

As I've compared the two solutions, I couldn't find any significant advantage of the proxy forwarding to have two standardized mechanisms for SR path e2e protection. It might be reasonable to have one standard while other proposals get experimental status?
[HC]: It provides more protection coverage in some cases as compared to
the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths.
GIM>> I find it hard to quantify your characterization. I imagine that if an operator uses the protection mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths it designs the network with that in mind and thus minimizes if not completely avoids any possible limitation the protection mechanism may have. Perhaps you can help with some more specific scenarios.
[HC2]: Assume that a SR path has the SID of a node N and node N failed.
For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths,
if a node X on the shortest path from a upstream node to N does not
support the mechanism, node X drops the traffic transported by the path.
For the solution in our draft, proxy capable nodes off node X on the shortest
path to a neighbor of N are used. The neighbor re-routes the traffic around
failed node N towards the destination. The traffic is protected.
This improves the reliability of networks, and QoE. This should be a
significant advantage. There is no solution for BSID protection in the
other existing draft.
GIM>> Though BSID may be used inside the network, I find such use case questionable making no significant impact on the usefulness of the protection mechanism.
[HC2]: Considering two drafts A and B. Draft A supports protection
of a SR path, which contains two types of components, say C1 and C2.
If the path contains a third type of components, say, C3, then
protection of the path for C3 is not supported.
Draft B supports protection of a SR path, containing C1, C2 and C3.
In this case, draft B seems having a significant advantage over draft A.
The solution for BSID protection in our draft has
been there for a few years. In addition, after a node failed, in
our solution, the nodes of the entire network converge to the latest
state consistently in time. After a node failed, the mechanism defined
in the other existing draft holds off the FIB during the HoldTimer
period configured, when the network changes again,
GIM>> I consider that property of the protection defined in draft-ietf-spring-segment-protection-sr-te-paths as a benefit that allows better control for the proper coordination between protection mechanisms that operate on different network layers.
our solution continues
to converge at any time.
The mechanisms in two drafts are different. It seems ok and reasonable
to have the two drafts to be adopted in the WG.
GIM>> I agree with you, drafts are fundamentally different and, in my opinion, merging them would not change the situation. But I don't see that as the justification for producing two standards. It seems to me, releasing two standard-based specifications might be detrimental and I propose the authors consider taking this draft onto the experimental track. I'd support the adoption of it as the experimental track document.

Regards,
Greg

Dear WG,

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%7C4baac6ced8b241b8e8a008d9eb8444e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799775601962149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=BIJm6UvUkp9QxNFwgzH9yyZE%2F59AXZo2x6aYUEqi7Aw%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C4baac6ced8b241b8e8a008d9eb8444e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799775602118366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0TaWVJRQEEpWAng%2FE62IG2%2Fzv9CbwEWVp4Q0PiD7Nvs%3D&reserved=0>

---

From: <[email-masked]>
Date: Thu, 10 Feb 2022 10:40:33 +0000

Hi Huaimo,

Thanks for the follow up.
Please see one point inline [Bruno]

Orange Restricted
From: spring <[email-masked]> On Behalf Of Huaimo Chen
Sent: Wednesday, February 9, 2022 2:48 AM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi Bruno,

Best Regards,
Huaimo
on behalf of co-authors
________________________________
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 8, 2022 6:01 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi authors, all

§2

   network domain. »

§3.2.2

[Bruno] Indeed, signaling session would be needed. That seems doable à priori (especially if we assume that BSID may already be needed on other nodes)
My point is that _today_, using BSID requires configuration/signaling of this BSID on the BSID node itself and on all ingress nodes using it. None of these signaling involves the IGP. So it's not clear to me that IGP would be the obvious choice specifically for the neighbors of the protected node, while a different protocol would be used for the BSID on the protected and ingress nodes. Theoretically feasible but, IMHO as a network operator subject, subject to a risk of lack of feature parity in short and long term. At minimum I would expect the document to (also) explore how this could be performed using the protocols signaling the BSID on the protected node and ingress (e.g. PCE, BGP, configuration). Also in my experience, the LSR WG is usually not that found of using the IGP for configuration/signaling.

Thanks,

Regards,

--Bruno

Orange Restricted

Dear WG,

Thanks!

Bruno, Jim, Joel

Thank you.

Thank you.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 10 Feb 2022 13:51:51 +0000

Hi Bruno,

    Thank you very much for your valuable point.

    We have updated the draft to address it.

Best Regards,
Huaimo
________________________________
From: [email-masked] <[email-masked]>
Sent: Thursday, February 10, 2022 5:40 AM
To: Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi Huaimo,

Orange Restricted

Hi Bruno,

Best Regards,

Huaimo

on behalf of co-authors

Hi authors, all

§2

   network domain. »

§3.2.2

   [RFC7356<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7356&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cee4806bcfe6143e86bba08d9ec81c58f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637800864401143210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ocQIQa5Qz0PwS5iKYOgW7WL9pCTnSrAEH%2BtYIVVoLmo%3D&reserved=0>]. »

My point is that _today_, using BSID requires configuration/signaling of this BSID on the BSID node itself and on all ingress nodes using it. None of these signaling involves the IGP. So it’s not clear to me that IGP would be the obvious choice specifically for the neighbors of the protected node, while a different protocol would be used for the BSID on the protected and ingress nodes. Theoretically feasible but, IMHO as a network operator subject, subject to a risk of lack of feature parity in short and long term. At minimum I would expect the document to (also) explore how this could be performed using the protocols signaling the BSID on the protected node and ingress (e.g. PCE, BGP, configuration). Also in my experience, the LSR WG is usually not that found of using the IGP for configuration/signaling.

Thanks,

Regards,

--Bruno

Orange Restricted

Dear WG,

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%7Cee4806bcfe6143e86bba08d9ec81c58f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637800864401143210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mhaqd%2F%2F6yZwZf5leZO11bs708jNSDe300L3RCSZZrA8%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

Thank you.

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 10 Feb 2022 12:40:45 -0800

Hi Huaimo,
thank you for responding to my notes and questions. I wanted to highlight
one issue (top-posting):

For the solution in our draft, proxy capable nodes off node X on the
shortest

path to a neighbor of N are used.

>From reading your response, it seems that you compare how different
solutions behave not in identical environments. I don't see that as a fair
comparison.

Regards,
Greg

On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen <[email-masked]>
wrote:

> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Tuesday, February 8, 2022 11:25 PM
> *To:* Huaimo Chen <[email-masked]>
> *Cc:* Bruno Decraene <[email-masked]>; SPRING WG <
> [email-masked]>
> <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%7C4baac6ced8b241b8e8a008d9eb8444e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799775601962149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=BIJm6UvUkp9QxNFwgzH9yyZE%2F59AXZo2x6aYUEqi7Aw%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C4baac6ced8b241b8e8a008d9eb8444e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799775602118366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0TaWVJRQEEpWAng%2FE62IG2%2Fzv9CbwEWVp4Q0PiD7Nvs%3D&reserved=0>
>
>

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 11 Feb 2022 03:41:13 +0000

Hi Greg,

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

Best Regards,
Huaimo

Sent: Thursday, February 10, 2022 3:40 PM

Hi Huaimo,
thank you for responding to my notes and questions. I wanted to highlight one issue (top-posting):
>From reading your response, it seems that you compare how different solutions behave not in identical environments. I don't see that as a fair comparison.
[HC3]: The environments are the same for two different solutions.
That is that the same environment for two different solutions.
A node X on the shortest path from a upstream node to N does not
support any protection/solution. That is that node X does not support
the mechanism in draft-ietf-spring-segment-protection-sr-te-paths or
our solution. Other nodes support the protection/solution. That is that
they support the mechanism in draft-ietf-spring-segment-protection-sr-te-paths or
our solution.

Regards,
Greg

On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best Regards,
Huaimo

________________________________
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 8, 2022 11:25 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: Bruno Decraene <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi Huaimo,

Regards,
Greg

Best Regards,
Huaimo
on behalf of co-authors

Dear Authors, et al.,

Regards,
Greg

Dear WG,

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%7C562185d788f440835c4108d9ecd5a5be%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637801224640802016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=e0ry4z9YrilB2FTe%2BZ3XjUhPWymkSrJQJa2dKgUcAWE%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C562185d788f440835c4108d9ecd5a5be%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637801224640802016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=VQnW%2BkJgo%2FgfVg3XJ4gC3JL8R75B5BhaYe15%2FcX1ZKM%3D&reserved=0>

---

From: <[email-masked]>
Date: Thu, 24 Feb 2022 11:17:19 +0000

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

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 1 Mar 2022 03:00:15 +0000

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

Sent: Thursday, February 24, 2022 6:17 AM

Dear WG,

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

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

Coming back to “a”, [1] also covers a solution for the FRR protection of binding SIDs.

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

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

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

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

Dear WG,

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>

Thanks!

Bruno, Jim, Joel

Thank you.