Hi Shraddha,
Thank you for the reply.
My responses are inline below with [HC].
Best Regards,
Huaimo
________________________________
From: Shraddha Hegde <shrad...@juniper.net>
Sent: Friday, January 28, 2022 12:05 AM
To: Huaimo Chen <huaimo.c...@futurewei.com>; bruno.decra...@orange.com
<bruno.decra...@orange.com>; SPRING WG <spring@ietf.org>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
Huaimo,
Juniper Business Use Only
From: Huaimo Chen <huaimo.c...@futurewei.com>
Sent: Friday, January 28, 2022 2:39 AM
To: Shraddha Hegde <shrad...@juniper.net>; bruno.decra...@orange.com; SPRING WG
<spring@ietf.org>
Subject: Re: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
[External Email. Be cautious of content]
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.
<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.
[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.
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.
<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.
[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.
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.)
[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.
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.
[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
________________________________
From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on
behalf of Shraddha Hegde
<shraddha=40juniper....@dmarc.ietf.org<mailto:shraddha=40juniper....@dmarc.ietf.org>>
Sent: Thursday, January 27, 2022 2:15 AM
To: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>; SPRING WG
<spring@ietf.org<mailto:spring@ietf.org>>
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.
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:
[cid:image001.png@01D8142C.DBA09380]
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.
2. 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 spring-boun...@ietf.org<mailto:spring-boun...@ietf.org> On Behalf
Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Thursday, January 13, 2022 3:49 PM
To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
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://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>
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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
