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

From: <[email-masked]>
Date: Thu, 13 Jan 2022 10:19:20 +0000

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.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 13 Jan 2022 16:25:24 +0000

Hi Everyone,

    Happy New Year!

    I support its adoption. It provides protections for a node SID, adjacency SID and binding SID of SR-MPLS TE path after the IGP converges.

Best Regards,
Huaimo as co-author
________________________________
From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, January 13, 2022 5:19 AM
To: SPRING WG <[email-masked]>
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

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%7Ca0324c4b302a4d82157e08d9d67e32dd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776659786642269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=D1uXJpyYR6RSBJBTr%2FQj6lqfEXQC5gxntuaif57SdSQ%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 14 Jan 2022 01:19:10 +0000

Support WG adoption.

Linda Dunbar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 13, 2022 5:19 AM
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

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%7Clinda.dunbar%40futurewei.com%7Cd34d534fd5404e5fca3208d9d6b157ed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637776879466008063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vM3MvCDMe3uEm6cXtLy7NREozhc8WNksBXIFYoU5cXI%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

Thank you.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 14 Jan 2022 03:08:16 -0500

I have read the draft and support WG adoption of this draft.

SR provides local protection only via TI-LFA at the PLR node but does not
provide bypass loop NNH node protection around the failure.

This draft provides a Midpoint protection mechanism using a new proxy
forwarding IGP extension  capability for restoration of routes to Adjacency
segment, Node segment, and Binding segment  after IGP convergence.

Kind Regards

Gyan

On Thu, Jan 13, 2022 at 8:19 PM Linda Dunbar <[email-masked]>
wrote:

>
>
> Support WG adoption.
>
>
>
> Linda Dunbar
>
>
>
>
>
> *From:* spring <[email-masked]> on behalf of
> [email-masked] <[email-masked]>
> *Sent:* Thursday, January 13, 2022 5:19 AM
> *To:* SPRING WG <[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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hu-spring-segment-routing-proxy-forwarding%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd34d534fd5404e5fca3208d9d6b157ed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637776879466008063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vM3MvCDMe3uEm6cXtLy7NREozhc8WNksBXIFYoU5cXI%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
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Huzhibo <[email-masked]>
Date: Fri, 14 Jan 2022 09:02:20 +0000

Hi WG,

    I support its adoption as author. It provides a complete FRR mechanism for SR-TE Node/Link/Binding Sid failure. Including before IGP convergence,and  after IGP convergence to before TE convergence.

Best Regards,
Zhibo Hu

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 13, 2022 6:19 PM
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: Haoyu Song <[email-masked]>
Date: Fri, 14 Jan 2022 17:00:31 +0000

I support the adoption.

Best,
Haoyu

From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, January 13, 2022 2:19 AM
To: SPRING WG <[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/<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%7Chaoyu.song%40futurewei.com%7Ca0324c4b302a4d82157e08d9d67e32dd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776659787367185%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BHb8JfY3DT%2BHzB0x3uxxObCHtuypYigAgF8xkU1lgG0%3D&reserved=0>

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 15 Jan 2022 15:44:50 +0800

Hi WG，

I support the adoption.

Regards,
Peng Liu

[email-masked]
 
From: [email-masked]
Date: 2022-01-13 18:19
To: SPRING WG
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
Dear WG,

 

Thanks!
Bruno, Jim, Joel

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 15 Jan 2022 19:02:35 +0800

I support the adoption of this draft. Thanks.
B.R.
Yongqing Zhu

[email-masked]

 

 
Thanks!
Bruno, Jim, Joel

---

From: "Meiling Chen" <[email-masked]>
Date: Mon, 17 Jan 2022 10:33:06 +0800

Hi All，

I support the adoption.

Best,
Meiling

 

 
Thanks!
Bruno, Jim, Joel

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 17 Jan 2022 14:43:02 -0500

Support for WG adoption.
Thanks,
- Xufeng

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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

> this is a stronger way to indicate your (non) support as this is not a vote.
>
>
>
>

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Tue, 18 Jan 2022 09:49:16 +0800

I support the adoption. 

Best Regards,

Weiqiang Cheng

  _____  

From: spring <[email-masked]> on behalf of
[email-masked] <[email-masked]>
Sent: Thursday, January 13, 2022 5:19 AM
To: SPRING WG <[email-masked]>
Subject: [spring] WG adoption call -
draft-hu-spring-segment-routing-proxy-forwarding 

Dear WG,

https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwa
rding/
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fdraft-hu-spring-segment-routing-proxy-forwarding%2F&data
=04%7C01%7Chuaimo.chen%40futurewei.com%7Ca0324c4b302a4d82157e08d9d67e32dd%7C
0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776659786642269%7CUnknown%7CTW
FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C3000&sdata=D1uXJpyYR6RSBJBTr%2FQj6lqfEXQC5gxntuaif57SdSQ%3D&reserved=0> 

 

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.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 18 Jan 2022 14:53:22 +0800

Hi all,

            I support this adoption. The draft is completed and useful.

Best regards,

Haojie Wang
ChinaMobile
[email-masked]

 

 
Thanks!
Bruno, Jim, Joel

---

From: 龚立艳 <[email-masked]>
Date: Thu, 20 Jan 2022 09:55:15 +0800 (CST)

Hi WG，

I support this adoption.

Best Regards,

Liyan Gong

----邮件原文----发件人："bruno.decraene" <[email-masked]>收件人：SPRING WG  <[email-masked]>抄　送: (无)发送时间：2022-01-13 18:19:20主题：[spring] WG adoption call -draft-hu-spring-segment-routing-proxy-forwarding

Dear WG,

 

 

 

 

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 l39expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d39alteration,
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: "Aijun Wang" <[email-masked]>
Date: Thu, 20 Jan 2022 10:45:48 +0800

Hi, All:

I have read this draft and support its adoption.

It can provide the restoration of the routes to an adjacency segment, a node
segment and a binding segment of the path when one proxied node failures..

Best Regards

Aijun Wang

China Telecom

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

Dear WG,

 

Thanks!

Bruno, Jim, Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 21 Jan 2022 06:27:22 +0000

Hi WG,

I've read this document and support its adoption.

Best regards,
Jie

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: yaojunda <[email-masked]>
Date: Mon, 24 Jan 2022 06:16:16 +0000

Hi WG,

I support its adoption as a co-author. It Provides a complete FRR mechanism for SR-TE Node/Link/Binding Sid failure. Including before IGP convergence, and after IGP convergence to before TE convergence.

Best Regards,
Junda Yao

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: <[email-masked]>
Date: Tue, 25 Jan 2022 18:13:29 +0100

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.

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

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

4.	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]> On Behalf Of
[email-masked]
Sent: jeudi 13 janvier 2022 11:19
To: SPRING WG <[email-masked]>
Subject: [spring] WG adoption call -
draft-hu-spring-segment-routing-proxy-forwarding

Dear WG,

 

Thanks!

Bruno, Jim, Joel

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 27 Jan 2022 07:15:06 +0000

WG,

I  don't support the adoption of this document as a WG document.

I am in agreement with stephane's comments on the list.

  1.  May cause congestion somewhere else in the network
There is already WG adopted document that is addressing the problem space
draft-ietf-spring-segment-protection-sr-te-paths.
This draft does not provide significant advantages over the proposed solutions in
draft-ietf-spring-segment-protection-sr-te-paths.
draft-hu-spring-segment-routing-proxy-forwarding claims to provide better solution when all nodes
have not been upgraded. draft-hu-spring-segment-routing-proxy-forwarding introduces protocol extensions
and the nodes that aren't upgraded to understand the extensions will drop the traffic so there isn't
any significant improvement in the approach.

In fact, the approach described in draft-hu-spring-segment-routing-proxy-forwarding may
cause other issues such as bandwidth double booking since it proposes that  any neighbor that
claims proxy forwarding will be used to forward the protected traffic.

For ex:

In above diagram
SR-TE path is RT1->RT3->RT7->RT5
Only RT4 supports proxy-forwarding
On failure of RT3, RT1 would send traffic to RT4 via RT1->RT6->RT7-RT4
RT4 will then send to RT7 as per the SR-TE path
RT7 will then send to RT5 via RT7->RT4->RT5

In this example, same traffic is traversing the RT7->RT4 link 3 times.

Operationally this solution is very complex to manage. A network that starts with no segment protection,
It may be ok to drop the traffic if some nodes have not been upgraded but causing congestion
somewhere else would be difficult to debug.

  1.  BSID solution
draft-ietf-spring-segment-protection-sr-te-paths does not explicitly discuss the solution for BSIDs.
Most of the BSID deployments use anycast based solution where same BSID is assigned on anycast nodes and BSID is always preceded by the anycast SID. Section 2.2 in draft-ietf-spring-segment-protection-sr-te-paths discusses this approach.
             draft-hu-spring-segment-routing-proxy-forwarding  provides a protection solution for BSIDs when anycast is not in use.

 If WG is inclined to solve the BSID protection problem when anycast solution is not in use, I would prefer the
              Approach to be more aligned with draft-ietf-spring-segment-protection-sr-te-paths. I do not support Introducing completely   different solution based on proxy forwarding which has other implications described in point 1.

Rgds
Shraddha

Juniper Business Use Only
From: spring [email-masked]<mailto:[email-masked]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, January 13, 2022 3:49 PM
To: SPRING WG <[email-masked]>
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

[External Email. Be cautious of content]

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!TWaV4x51MCL2h93fiW-3XI8ElTsP963AWA5gjKCMU6g9E1WN0cRkqV6D5Qi50WbR$>

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: Huzhibo <[email-masked]>
Date: Thu, 27 Jan 2022 09:29:13 +0000

Hi Shraddha:

     Thanks for your comments, Please see inline.

Thanks

Zhibo Hu

From: spring [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: Thursday, January 27, 2022 3:15 PM
To: [email-masked]; SPRING WG <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

WG,

I  don’t support the adoption of this document as a WG document.

I am in agreement with stephane’s comments on the list.

and the nodes that aren’t upgraded to understand the extensions will drop the traffic so there isn’t

For ex:

In above diagram

Operationally this solution is very complex to manage. A network that starts with no segment protection,
It may be ok to drop the traffic if some nodes have not been upgraded but causing congestion
somewhere else would be difficult to debug.
------》[HZB] Traffic detour may exist in all local FRR mechanisms and is not unique to this solution, including TI-LFA.SR-TE Path protection etc，
              The solution described in [draft-ietf-spring-segment-protection-sr-te-paths] also has this problem.for example you have mentioned,
If using the solution of [ draft-ietf-spring-segment-protection-sr-te-paths], On failure of RT3, If the last calculated reachable path to RT3 is RT1->RT6->RT7->RT4->RT3, RT1 maintains the path of RT1->RT6->RT7->RT4->RT3 for forwarding during the Holdtimer period. Then, RT4 performs Proxy Forwarding and RT1->RT6->RT7->RT4->RT7->RT4->RT5. It also traverses the link 3 times from RT7 to RT4.
I think extending the protocol is a much simpler way than slow route deletion and loop solving.

2.       BSID solution

 If WG is inclined to solve the BSID protection problem when anycast solution is not in use, I would prefer the
              Approach to be more aligned with draft-ietf-spring-segment-protection-sr-te-paths. I do not support Introducing completely   different solution based on proxy forwarding which has other implications described in point 1.
------》[HZB]I don`t think that most of the BSID deployments use anycast based solution，Strict path control is required in most scenarios, and anycast is not introduced.
                 If Bsid is not addressed, it will not be a complete protection solution.

Rgds
Shraddha

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 27 Jan 2022 21:09:03 +0000

Hi Shraddha,

    Thank you for your comments.

    I remember that I talked to you face to face in IETF meeting and
suggested merging your draft and our draft a long time ago before
your draft is adopted. You said it would be ok to have the two drafts
in WG. In addition, I sent you an email to ask for merging the two drafts,
but did not receive any reply from you.

    I also remember that Zhibo supported the adoption of your draft.

    These two drafts have some overlaps and differences. Our draft
refers to yours for the overlaps, but focuses on the different
method for protection and the area your draft does not cover.

    For example, your draft talks about using anycast SID to protect
node failure. I remember that this was discussed in IETF meeting and
some issues were raised by others. We do not use anycast SID for
protection.

    Regarding to "May cause congestion somewhere else in the network",
this seems true for the two drafts when a node failed.

Best Regards,
Huaimo

________________________________
From: spring <[email-masked]> on behalf of Shraddha Hegde <shraddha=[email-masked]>
Sent: Thursday, January 27, 2022 2:15 AM
To: [email-masked] <[email-masked]>; SPRING WG <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

WG,

For ex:

In above diagram

  1.  BSID solution

Rgds

Shraddha

Dear WG,

https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hu-spring-segment-routing-proxy-forwarding%2F__%3B!!NEt6yMaO-gk!TWaV4x51MCL2h93fiW-3XI8ElTsP963AWA5gjKCMU6g9E1WN0cRkqV6D5Qi50WbR%24&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf11b3573b9f441267f6008d9e164cfef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637788645400164200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S2%2BmuO29w3Yy%2F3pqvU1A2xByY7xrciCzp%2FUqZfPPUN4%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 28 Jan 2022 04:19:38 +0000

Huzhibo,

Pls see inline for replies..

Juniper Business Use Only
From: Huzhibo <huzhibo=[email-masked]>
Sent: Thursday, January 27, 2022 2:59 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi Shraddha:

Thanks

Zhibo Hu

From: spring [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: Thursday, January 27, 2022 3:15 PM
To: [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

WG,

For ex:

In above diagram

<SH> The problem I am indicating is not traffic detour, it is about bandwidth double booking on interfaces.

              The solution described in [draft-ietf-spring-segment-protection-sr-te-paths] also has this problem.for example you have mentioned,
If using the solution of [ draft-ietf-spring-segment-protection-sr-te-paths], On failure of RT3, If the last calculated reachable path to RT3 is RT1->RT6->RT7->RT4->RT3,

RT1 maintains the path of RT1->RT6->RT7->RT4->RT3 for forwarding during the Holdtimer period. Then, RT4 performs Proxy Forwarding and RT1->RT6->RT7->RT4->RT7->RT4->RT5. It also traverses the link 3 times from RT7 to RT4.
I think extending the protocol is a much simpler way than slow route deletion and loop solving.

<SH> This is incorrect example. Here the traffic is sent twice on RT7->RT4 interface twice even before the failure.
           This is problem with how SR-TE calculated the path and not a problem with procedures described in
            draft-ietf-spring-segment-protection-sr-te-paths

  1.  BSID solution

Rgds
Shraddha

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 28 Jan 2022 05:05:53 +0000

Huaimo,

Juniper Business Use Only
From: Huaimo Chen <[email-masked]>
Sent: Friday, January 28, 2022 2:39 AM
To: Shraddha Hegde <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>
Subject: Re: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi Shraddha,

    I remember that I talked to you face to face in IETF meeting and
suggested merging your draft and our draft a long time ago before
your draft is adopted. You said it would be ok to have the two drafts
in WG.
<SH> I honestly don't remember the conversation. I would be OK with two drafts
If the proxy forwarding was adding value but I see that it has no significant benefits
As compared to the existing WG adopted draft.

In addition, I sent you an email to ask for merging the two drafts,
but did not receive any reply from you.

    These two drafts have some overlaps and differences. Our draft
refers to yours for the overlaps, but focuses on the different
method for protection and the area your draft does not cover.
<SH> BSID protection when anycast is not in use is the area your draft
Covers and is not covered by draft-ietf-spring-segment-protection-sr-te-paths.
proxy forwarding is a solution that overlaps existing solution space and is completely different
from existing solution space. For BSID protection, proxy forwarding is not necessary.
It can be solved using context tables by learning the details of the BSID from neighbors.
It would be good to see how many operators are really interested in this kind of BSID protection.

    For example, your draft talks about using anycast SID to protect
node failure. I remember that this was discussed in IETF meeting and
some issues were raised by others.
<SH> There are no open issues AFAIKT.
We do not use anycast SID for
protection.
<SH>The draft draft-ietf-spring-segment-protection-sr-te-paths  proposes
anycast SID as one of the ways to achieve protection (It is the most common deployed
mechanisms to achieve protection in SR networks in my knowledge.)

    Regarding to "May cause congestion somewhere else in the network",
this seems true for the two drafts when a node failed.
<SH> The issue I brought up was more for the bandwidth double booking on interfaces and it
May happen in proxy forwarding as the proxy forwarder may not lie in the shortest path
But may be on the otherside.

Best Regards,
Huaimo

________________________________
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>
Sent: Thursday, January 27, 2022 2:15 AM
To: [email-masked]<mailto:[email-masked]> <[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

WG,

For ex:

In above diagram

2.       BSID solution

Rgds

Shraddha

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*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-hu-spring-segment-routing-proxy-forwarding*2F__*3B!!NEt6yMaO-gk!TWaV4x51MCL2h93fiW-3XI8ElTsP963AWA5gjKCMU6g9E1WN0cRkqV6D5Qi50WbR*24&data=04*7C01*7Chuaimo.chen*40futurewei.com*7Cf11b3573b9f441267f6008d9e164cfef*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637788645400164200*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=S2*2BmuO29w3Yy*2F3pqvU1A2xByY7xrciCzp*2FUqZfPPUN4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XMSkGU0Zm98twzSzoy2RDjLw78tzsjdPlxfqK9Lg-anMbxc8t7yOyePOmhMHgiwU$>

Thanks!

Bruno, Jim, Joel

Thank you.

---

From: Huzhibo <[email-masked]>
Date: Fri, 28 Jan 2022 06:33:52 +0000

Shraddha,

Pls see inline for replies.

From: Shraddha Hegde [mailto:shraddha=[email-masked]]
Sent: Friday, January 28, 2022 12:20 PM
To: Huzhibo <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Huzhibo,

Juniper Business Use Only
From: Huzhibo <huzhibo=[email-masked]<mailto:huzhibo=[email-masked]>>
Sent: Thursday, January 27, 2022 2:59 PM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi Shraddha:

Thanks

Zhibo Hu

WG,

For ex:

In above diagram

<SH> This is incorrect example. Here the traffic is sent twice on RT7->RT4 interface twice even before the failure.
           This is problem with how SR-TE calculated the path and not a problem with procedures described in
            draft-ietf-spring-segment-protection-sr-te-paths
------》[HZB2]  draft-ietf-spring-segment-protection-sr-te-paths mentioned：
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.
   The traffic will continue to follow the previous path and get FRR
   protection on the PLR.
         On failure of RT3，RT1 detects the Link RT3-RT2, Link RT3-RT6 and Link RT3-RT7 failure first. RT1`s  shorest Path to RT3 is RT1->RT6->RT7->RT4->RT3, And then RT1 detects the Link RT3-RT4 failure.  The Node-Sid of RT3 become unreachable.
         RT1 will keep the previous path RT1->RT6->RT7->RT4->RT3. Packets are forwarded to RT4 for PLR, RT4 will send next segment RT7，RT7 will then send to RT5 via RT7->RT4->RT5.
The path described in this case is exactly the same as the forwarding path described in your example（In both cases, RT4 is selected as the PLR, and the results are the same.） I don't know why you think one is 3 times and   the other is 2 times. So, for draft-ietf-spring-segment-protection-sr-te-paths，Even if all nodes support this draft, it is possible that traversing the RT7->RT4 link 3 times. You actually gave an example of reacting [draft-ietf-spring-segment-protection-sr-te-paths] disadvantages.

2.       BSID solution

Rgds
Shraddha

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 28 Jan 2022 08:40:44 +0000

Huzhibo,

Pls see inline..

Sent: Friday, January 28, 2022 12:04 PM

Shraddha,

From: Shraddha Hegde [mailto:shraddha=[email-masked]]
Sent: Friday, January 28, 2022 12:20 PM
To: Huzhibo <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Huzhibo,

Hi Shraddha:

Thanks

Zhibo Hu

WG,

For ex:

In above diagram

<SH> What you are describing in above text is a case when the link down events are reaching RT1 in a particular
           Order and one particular link down event is reaching very late on all the nodes on the path which is a corner case. There are already existing solutions such as spf-delay that can ensure most correlated events are clubbed together in one SPF. The local computations on RT1 can also be optimized to detect node down events and the previous paths to hold down.
What you claim about fully upgraded network is not correct in this particular  example is not true.
When all the nodes are supporting context tables, RT6 will make sure to lookup next label and send to RT7.

I don’t see any strong justification how proxy forwarding is improving the situation of partially upgraded network
which it claims to be doing.

  1.  BSID solution

Rgds
Shraddha

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 28 Jan 2022 10:57:27 +0800

This document provides a comprehensive SR-TE node failure protection solution.
I think it is useful for SR network reliability.
B.R.
Lijie Deng

网络技术研究所-邓丽洁
18922187259
[email-masked]

 

 
Thanks!
Bruno, Jim, Joel

---

From: Huzhibo <[email-masked]>
Date: Fri, 28 Jan 2022 09:14:28 +0000

<SH> What you are describing in above text is a case when the link down events are reaching RT1 in a particular
           Order and one particular link down event is reaching very late on all the nodes on the path which is a corner case. There are already existing solutions such as spf-delay that can ensure most correlated events are clubbed together in one SPF. The local computations on RT1 can also be optimized to detect node down events and the previous paths to hold down.
What you claim about fully upgraded network is not correct in this particular  example is not true.
When all the nodes are supporting context tables, RT6 will make sure to lookup next label and send to RT7.
------》[HZB]No,RT6 won`t, draft-ietf-spring-segment-protection-sr-te-paths mentioned:
During network convergence, the micro-loop avoidance mechansims as
   described in [I-D.bashandy-rtgwg-segment-routing-uloop] may be
   applied.For the failed node, all the nodes in the network should
   consistently detect the failure and maintain the pre-failure shortest
   path in the forwarding plane so that the traffic can follow pre-
   failure shortest path and take the node-protecting backup path at the
RT1 will converge to the avoidance-microloop path and needs to encapsulate the avoidance-microloop segment list. Therefore, even if RT6 supports SR-TE node protection, RT6 won't look up next label.

I don’t see any strong justification how proxy forwarding is improving the situation of partially upgraded network
which it claims to be doing.
------》[HZB] When the network is upgraded, you can use commands to control the advertisement of PF capabilities. When the network is stable, you can advertise PF capabilities of nodes on the entire network.
              Controls like this are common during network upgrades.

From: Shraddha Hegde [mailto:shraddha=[email-masked]]
Sent: Friday, January 28, 2022 4:41 PM
To: Huzhibo <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Huzhibo,

Pls see inline..

Shraddha,

Huzhibo,

Hi Shraddha:

Thanks

Zhibo Hu

WG,

For ex:

In above diagram

2.       BSID solution

Rgds
Shraddha

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 28 Jan 2022 16:27:10 +0000

Hi Shraddha,

    Thank you for the reply.

    My responses are inline below with [HC].

Best Regards,
Huaimo
________________________________
From: Shraddha Hegde <[email-masked]>
Sent: Friday, January 28, 2022 12:05 AM
To: Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>; SPRING WG <[email-masked]>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Huaimo,

Hi Shraddha,

in WG.

<SH> I honestly don’t remember the conversation. I would be OK with two drafts

[HC]: It provides more protection coverage in some cases as compared to

the existing WG adopted draft. This improves the reliability of networks,
and QoE. This is a significant benefit.

[HC]: There is no solution for BSID protection in your draft yet even though

you say that it can be solved using context tables ....

The solution for BSID protection in our draft has been there for a couple of years.

protection.

[HC]: How do you protect transit node failure using anycast SID in general?

It seems very hard. Your draft seems talking about some specific cases

for a given/specific network topology.

[HC]: Can you give a simple example for node failure and SR path with the SID of the node,

in which your solution does not have the bandwidth double booking and ours

has the bandwidth double booking?

Best Regards,

Huaimo

WG,

For ex:

In above diagram

2.       BSID solution

Rgds

Shraddha

Dear WG,

https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-hu-spring-segment-routing-proxy-forwarding*2F__*3B!!NEt6yMaO-gk!TWaV4x51MCL2h93fiW-3XI8ElTsP963AWA5gjKCMU6g9E1WN0cRkqV6D5Qi50WbR*24%26data%3D04*7C01*7Chuaimo.chen*40futurewei.com*7Cf11b3573b9f441267f6008d9e164cfef*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637788645400164200*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DS2*2BmuO29w3Yy*2F3pqvU1A2xByY7xrciCzp*2FUqZfPPUN4*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XMSkGU0Zm98twzSzoy2RDjLw78tzsjdPlxfqK9Lg-anMbxc8t7yOyePOmhMHgiwU%24&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C0bfa69e2a58f4e67fc4e08d9e21bdeb1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789431628757806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KXIjLcfaCgjy0tmelCAQSyiteEJHHJvGMQvqGbnZHug%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

Thank you.