<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=40juniper....@dmarc.ietf.org]
Sent: Friday, January 28, 2022 4:41 PM
To: Huzhibo <huzh...@huawei.com>; bruno.decra...@orange.com; SPRING WG
<spring@ietf.org>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
Huzhibo,
Pls see inline..
Juniper Business Use Only
From: Huzhibo
<huzhibo=40huawei....@dmarc.ietf.org<mailto:huzhibo=40huawei....@dmarc.ietf.org>>
Sent: Friday, January 28, 2022 12:04 PM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>;
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; SPRING WG
<spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
[External Email. Be cautious of content]
Shraddha,
Pls see inline for replies.
From: Shraddha Hegde [mailto:shraddha=40juniper....@dmarc.ietf.org]
Sent: Friday, January 28, 2022 12:20 PM
To: Huzhibo <huzh...@huawei.com<mailto:huzh...@huawei.com>>;
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; SPRING WG
<spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
Huzhibo,
Pls see inline for replies..
Juniper Business Use Only
From: Huzhibo
<huzhibo=40huawei....@dmarc.ietf.org<mailto:huzhibo=40huawei....@dmarc.ietf.org>>
Sent: Thursday, January 27, 2022 2:59 PM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>;
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; SPRING WG
<spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
[External Email. Be cautious of content]
Hi Shraddha:
Thanks for your comments, Please see inline.
Thanks
Zhibo Hu
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, January 27, 2022 3:15 PM
To: 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.jpg@01D81469.29BEA070]
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.
------》[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，
<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
------》[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.
<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.
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.
------》[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
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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/__;!!NEt6yMaO-gk!TWaV4x51MCL2h93fiW-3XI8ElTsP963AWA5gjKCMU6g9E1WN0cRkqV6D5Qi50WbR$>
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
