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

From: Huzhibo <[email-masked]>
Date: Wed, 26 Jan 2022 08:30:41 +0000

Hi slitkows :

Thanks for your comments, Please see inline.

Thanks

Zhibo Hu
From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 26, 2022 1:13 AM
To: [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.
-----> [I-D.ietf-spring-segment-protection-sr-te-paths] defines local behaviors to implement SR-TE node protection. draft-hu-spring-segment-routing-proxy-forwarding enhances SR-TE node protection. It optimized the number of entries in the Context Table. This solution solves the connectivity problem after IGP convergence, and protects binding segments.

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.
---------> Protocols extensions can accurately direct traffic to a node that can perform proxy forwarding and solve the problem that traffic cannot be forwarded to a proxy forwarding node after IGP convergence. This protocol extension is necessary.
This solution does not require that all network nodes support this extension, take the example you have mentioned :
but it still requires that all routers upstream to F' support this extension ---> This description is inaccurate, assuming that the previous segment is node B, when node G fails. When the node B converges, the node B finds the PF
node F' adjacent to G, and can push the node Sid of the node F',Even if C and D do not support this protocol extension, this is not affected.
In addition, the Hold timers solution mentioned in [I-D.ietf-spring-segment-protection-sr-te-paths] does not extend protocols, but is also complex. In addition, slow deletion is required for node faults. In addition, loop prevention is implemented to prevent loops.Moreover, it cannot accurately direct traffic to a node that can perform proxy forwarding.

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.
-------> Binding segments need to be exchanged only between neighbors and do not need to be flooded to the entire IGP domain. Therefore, binding segments do not exert pressure on IGP performance.The control-plane processing and forwarding-plane processing of the BSID are not strongly coupled.SR-TE protection
takes effect only from the time during a fault occurs to the TE path converges. Therefore, SR-TE protection does not take effect during normal forwarding,Compared with impaired connectivity, performance degradation is acceptable.

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.
                ------->As you said, this document defines the detail requests for IGP protocols

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.

---

From: <[email-masked]>
Date: Wed, 26 Jan 2022 09:53:56 +0100

Hi,

Please find more inline.

From: Huzhibo <[email-masked]> 
Sent: mercredi 26 janvier 2022 09:31
To: [email-masked]; [email-masked]; 'SPRING WG'
<[email-masked]>
Subject: RE: [spring] WG adoption call -
draft-hu-spring-segment-routing-proxy-forwarding

Hi slitkows :

Thanks

Zhibo Hu

From: spring [mailto:[email-masked]] On Behalf Of
[email-masked] <mailto:[email-masked]> 
Sent: Wednesday, January 26, 2022 1:13 AM
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

Hi 

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.

-----> [I-D.ietf-spring-segment-protection-sr-te-paths] defines local
behaviors to implement SR-TE node protection.
draft-hu-spring-segment-routing-proxy-forwarding enhances SR-TE node
protection. 

It optimized the number of entries in the Context Table. This solution
solves the connectivity problem after IGP convergence, and protects binding
segments.

[SLI] While I think your arguments are not completely valid (see discussion
below), this has nothing to do with the one draft vs two drafts discussion.
As there is already a WG doc, I don't see any reason for creating another
one except creating artificial work for the IETF and confusing readers.

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.

---------> Protocols extensions can accurately direct traffic to a node that
can perform proxy forwarding and solve the problem that traffic cannot be
forwarded to a proxy forwarding node after IGP convergence. This protocol
extension is necessary.

This solution does not require that all network nodes support this
extension, take the example you have mentioned :

but it still requires that all routers upstream to F' support this extension
---> This description is inaccurate, assuming that the previous segment is
node B, when node G fails. When the node B converges, the node B finds the
PF

node F' adjacent to G, and can push the node Sid of the node F',Even if C
and D do not support this protocol extension, this is not affected.

[SLI] Your statement is purely theoretical and life in real networks is not
theoretical. You cannot predict which router will converge first (routers
may have different CPUs, may have different tasks to execute.). B may
converge first maybe, but maybe it will be C or D. no one knows and it's
unpredictable. So at the end, if you want to guarantee the mechanism to
work, all routers have to support the mechanism.

In addition, the Hold timers solution mentioned in
[I-D.ietf-spring-segment-protection-sr-te-paths] does not extend protocols,
but is also complex. In addition, slow deletion is required for node faults.
In addition, loop prevention is implemented to prevent loops.Moreover, it
cannot accurately direct traffic to a node that can perform proxy
forwarding.

[SLI] Directing traffic to few nodes that could do proxy forwarding can have
serious traffic impact and at the end cause damages to traffic that has
nothing to do with the failure. It's the solution, but it has major
drawbacks from an operational point of view.

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.

-------> Binding segments need to be exchanged only between neighbors and do
not need to be flooded to the entire IGP domain. Therefore, binding segments
do not exert pressure on IGP performance.The control-plane processing and
forwarding-plane processing of the BSID are not strongly coupled.

[SLI] Control plane aspects of IGPs have to be discussed in LSR, not in
SPRING. So please take the discussion to LSR for the control plane and
forwarding aspects could be further described in
[I-D.ietf-spring-segment-protection-sr-te-paths] if WGs agrees that BSID is
interesting to solve.

SR-TE protection    

takes effect only from the time during a fault occurs to the TE path
converges. Therefore, SR-TE protection does not take effect during normal
forwarding,Compared with impaired connectivity, performance degradation is
acceptable.

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.

                ------->As you said, this document defines the detail
requests for IGP protocols

[SLI] No it goes beyond requirements and already talks about encoding: 

"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].

This is not a requirement; this is an IS-IS solution description that has to
be discussed in LSR not in SPRING.

 

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-forwa
rding/

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: Huzhibo <[email-masked]>
Date: Wed, 26 Jan 2022 11:49:07 +0000

Hi,

Please find more inline.

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 26, 2022 4:54 PM
To: Huzhibo <[email-masked]>; [email-masked]; 'SPRING WG' <[email-masked]>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi,

Please find more inline.

From: Huzhibo <[email-masked]<mailto:[email-masked]>>
Sent: mercredi 26 janvier 2022 09:31
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

Hi slitkows :

Thanks

Zhibo Hu
From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, January 26, 2022 1:13 AM
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

Hi

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.
-----> [I-D.ietf-spring-segment-protection-sr-te-paths] defines local behaviors to implement SR-TE node protection. draft-hu-spring-segment-routing-proxy-forwarding enhances SR-TE node protection.

It optimized the number of entries in the Context Table. This solution solves the connectivity problem after IGP convergence, and protects binding segments.

[SLI] While I think your arguments are not completely valid (see discussion below), this has nothing to do with the one draft vs two drafts discussion. As there is already a WG doc, I don't see any reason for creating another one except creating artificial work for the IETF and confusing readers.

[SLI] Your statement is purely theoretical and life in real networks is not theoretical. You cannot predict which router will converge first (routers may have different CPUs, may have different tasks to execute...). B may converge first maybe, but maybe it will be C or D... no one knows and it's unpredictable. So at the end, if you want to guarantee the mechanism to work, all routers have to support the mechanism.
                    --------->[HZB]IGP convergence is much faster than SR-TE rerouting, Therefore, even if node B is slower than node C and node D in the previous example, the convergence time of the SR-TE path is far shorter than the convergence time of the SR-TE path. If some nodes in the network do not support the convergence, convergence may exceed 50 ms in some scenarios. If all nodes in the network support the convergence, That would result in better convergence performance.

In addition, the Hold timers solution mentioned in [I-D.ietf-spring-segment-protection-sr-te-paths] does not extend protocols, but is also complex. In addition, slow deletion is required for node faults. In addition, loop prevention is implemented to prevent loops.Moreover, it cannot accurately direct traffic to a node that can perform proxy forwarding.
[SLI] Directing traffic to few nodes that could do proxy forwarding can have serious traffic impact and at the end cause damages to traffic that has nothing to do with the failure. It's the solution, but it has major drawbacks from an operational point of view.
   --------->[HZB] Similar to the existing FRR mechanism, this document only filters out the nodes that do not support PF. For the same fault point, different remote nodes select different PF nodes and load balance traffic to different PF nodes.

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.
-------> Binding segments need to be exchanged only between neighbors and do not need to be flooded to the entire IGP domain. Therefore, binding segments do not exert pressure on IGP performance.The control-plane processing and forwarding-plane processing of the BSID are not strongly coupled.

[SLI] Control plane aspects of IGPs have to be discussed in LSR, not in SPRING. So please take the discussion to LSR for the control plane and forwarding aspects could be further described in  [I-D.ietf-spring-segment-protection-sr-te-paths] if WGs agrees that BSID is interesting to solve.
   --------->[HZB]Sure. We will consider whether we need to divest some of it into the LSR.

SR-TE protection

This is not a requirement; this is an IS-IS solution description that has to be discussed in LSR not in SPRING.
--------->[HZB]Sure. We will consider whether we need to divest some of it into the LSR.

Brgds,

Stephane

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: <[email-masked]>
Date: Thu, 27 Jan 2022 18:40:52 +0100

Hi,

                  --------->[HZB]IGP convergence is much faster than SR-TE
rerouting, Therefore, even if node B is slower than node C and node D in the
previous example, the convergence time of the SR-TE path is far shorter than
the convergence time of the SR-TE path. If some nodes in the network do not
support the convergence, convergence may exceed 50 ms in some scenarios. If
all nodes in the network support the convergence, That would result in
better convergence performance.

[SLI2]of course SR-TE will converge slower, I never discussed about the head
end. My point:  If C is faster than B and C does not support your mechanism,
it will drop traffic and your FRR is not guaranteed anymore. To get FRR
working, no choice, all the nodes must support the extension (seems you are
mixing convergence and protection which are two different things: networks
are never converging in 50ms). 

 

--------->[HZB] Similar to the existing FRR mechanism, this document only
filters out the nodes that do not support PF. For the same fault point,
different remote nodes select different PF nodes and load balance traffic to
different PF nodes.

[SLI2] The goal of TI-LFA is to try to keep the traffic on a path that has
been sized properly (this is one of the key point of TI-LFA). History of FRR
shown that this is important to constraint/steer FRR path on path that can
fit traffic. (See RFC7916).

So, letting traffic going to any neighbor of the failed node without any
control is wrong and may create more damages. When FRR traffic creates
congestion on some links the protected traffic was not intended to flow on,
you'll start to impact and drop other traffic which was not initially
flowing through the failed link/node (usually hard to explain to customers).
Keeping control of FRR path is a very important topic. 

Stephane

 

Sent: mercredi 26 janvier 2022 12:49

Hi,

Please find more inline.

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] 
Sent: Wednesday, January 26, 2022 4:54 PM
To: Huzhibo <[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

Hi,

Please find more inline.

From: Huzhibo <[email-masked] <mailto:[email-masked]> > 
Sent: mercredi 26 janvier 2022 09:31
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

Hi slitkows :

Thanks

Zhibo Hu

Hi 

 

                    --------->[HZB]IGP convergence is much faster than SR-TE
rerouting, Therefore, even if node B is slower than node C and node D in the
previous example, the convergence time of the SR-TE path is far shorter than
the convergence time of the SR-TE path. If some nodes in the network do not
support the convergence, convergence may exceed 50 ms in some scenarios. If
all nodes in the network support the convergence, That would result in
better convergence performance.

   --------->[HZB] Similar to the existing FRR mechanism, this document only
filters out the nodes that do not support PF. For the same fault point,
different remote nodes select different PF nodes and load balance traffic to
different PF nodes.

   --------->[HZB]Sure. We will consider whether we need to divest some of
it into the LSR.

SR-TE protection    

   [RFC7356].

--------->[HZB]Sure. We will consider whether we need to divest some of it
into the LSR.

 

Brgds,

Stephane

Dear WG,

<https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw
arding/>
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwa
rding/

 

Thanks!

Bruno, Jim, Joel

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 27 Jan 2022 22:02:38 +0000

Hi Stephane,

    Thank you for your comments.

[SLI2].... To get FRR working, no choice, all the nodes must support the extension. ...
[HC]: When some nodes (not all) support the extension, FRR may work for some failures.

Best Regards,
Huaimo
________________________________
From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, January 27, 2022 12:40 PM
To: 'Huzhibo' <[email-masked]>; [email-masked] <[email-masked]>; 'SPRING WG' <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi,

[SLI] Your statement is purely theoretical and life in real networks is not theoretical. You cannot predict which router will converge first (routers may have different CPUs, may have different tasks to execute…). B may converge first maybe, but maybe it will be C or D… no one knows and it’s unpredictable. So at the end, if you want to guarantee the mechanism to work, all routers have to support the mechanism.

[SLI2]of course SR-TE will converge slower, I never discussed about the head end. My point:  If C is faster than B and C does not support your mechanism, it will drop traffic and your FRR is not guaranteed anymore. To get FRR working, no choice, all the nodes must support the extension (seems you are mixing convergence and protection which are two different things: networks are never converging in 50ms).

[SLI] Directing traffic to few nodes that could do proxy forwarding can have serious traffic impact and at the end cause damages to traffic that has nothing to do with the failure. It’s the solution, but it has major drawbacks from an operational point of view.

[SLI2] The goal of TI-LFA is to try to keep the traffic on a path that has been sized properly (this is one of the key point of TI-LFA). History of FRR shown that this is important to constraint/steer FRR path on path that can fit traffic. (See RFC7916).

So, letting traffic going to any neighbor of the failed node without any control is wrong and may create more damages. When FRR traffic creates congestion on some links the protected traffic was not intended to flow on, you’ll start to impact and drop other traffic which was not initially flowing through the failed link/node (usually hard to explain to customers). Keeping control of FRR path is a very important topic.

Stephane

From: Huzhibo <[email-masked]>
Sent: mercredi 26 janvier 2022 12:49
To: [email-masked]; [email-masked]; 'SPRING WG' <[email-masked]>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi,

Please find more inline.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, January 26, 2022 4:54 PM
To: Huzhibo <[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

Hi,

Please find more inline.

Hi slitkows :

Thanks

Zhibo Hu

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.

[SLI] While I think your arguments are not completely valid (see discussion below), this has nothing to do with the one draft vs two drafts discussion. As there is already a WG doc, I don’t see any reason for creating another one except creating artificial work for the IETF and confusing readers.

  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.

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.

[SLI] Your statement is purely theoretical and life in real networks is not theoretical. You cannot predict which router will converge first (routers may have different CPUs, may have different tasks to execute…). B may converge first maybe, but maybe it will be C or D… no one knows and it’s unpredictable. So at the end, if you want to guarantee the mechanism to work, all routers have to support the mechanism.

[SLI] Directing traffic to few nodes that could do proxy forwarding can have serious traffic impact and at the end cause damages to traffic that has nothing to do with the failure. It’s the solution, but it has major drawbacks from an operational point of view.

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

SR-TE protection

  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.

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

   [RFC7356].

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%7Cec704a1a740841cf330108d9e1bc3617%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789020781089815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AP4sfZJYO%2Fq8ICziVDI4pO0I7u%2B0jCzB%2BwhawN8nyiQ%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

Thank you.

---

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

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 28, 2022 1:41 AM
To: Huzhibo <[email-masked]>; [email-masked]; 'SPRING WG' <[email-masked]>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi,

[SLI2]of course SR-TE will converge slower, I never discussed about the head end. My point:  If C is faster than B and C does not support your mechanism, it will drop traffic and your FRR is not guaranteed anymore. To get FRR working, no choice, all the nodes must support the extension (seems you are mixing convergence and protection which are two different things: networks are never converging in 50ms).
---------->[HZB2]As the example you have mentioned,  Packet loss occurs only when C converges, but B does not converge.
                The packet loss time depends on the IGP convergence time and is much shorter than the SR-TE rerouting time.
                What I want to say is that even if some nodes you mentioned do not support proxy forwarding, this solution is useful for speeding up convergence.

[SLI2] The goal of TI-LFA is to try to keep the traffic on a path that has been sized properly (this is one of the key point of TI-LFA). History of FRR shown that this is important to constraint/steer FRR path on path that can fit traffic. (See RFC7916).
So, letting traffic going to any neighbor of the failed node without any control is wrong and may create more damages. When FRR traffic creates congestion on some links the protected traffic was not intended to flow on, you'll start to impact and drop other traffic which was not initially flowing through the failed link/node (usually hard to explain to customers). Keeping control of FRR path is a very important topic.
---------->[HZB2]First: This document does not require that all affected traffic be directed to "one" neighbor node, and traffic is still balanced on all different neighbor nodes.
Second: All local FRR mechanisms take effect before convergence. In this case, other nodes on the network still route to the faulty node. Can you give an example?. FRR is performed when traffic does not need to be routed to the neighboring node of the faulty node.

Stephane

Hi,

Please find more inline.

Hi,

Please find more inline.

Hi slitkows :

Thanks

Zhibo Hu

Hi

SR-TE protection

Brgds,

Stephane

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

From: <[email-masked]>
Date: Fri, 28 Jan 2022 09:40:02 +0100

Hi,

[SLI2].... To get FRR working, no choice, all the nodes must support the
extension. ...

[HC]: When some nodes (not all) support the extension, FRR may work for some
failures.

[SLI3]: MAY or MAY NOT, there is absolutely no guarantee, then an SP who
wants to keep the guarantee of FRR (FRR is a guaranteed SLA to their
customers), they must deploy everywhere.

I'm always trying to think with realistic deployments in mind, not just
theoretical case on paper.

From: Huaimo Chen <[email-masked]> 
Sent: jeudi 27 janvier 2022 23:03
To: [email-masked]; 'Huzhibo' <[email-masked]>;
[email-masked]; 'SPRING WG' <[email-masked]>
Subject: Re: [spring] WG adoption call -
draft-hu-spring-segment-routing-proxy-forwarding

Hi Stephane,

[SLI2].... To get FRR working, no choice, all the nodes must support the
extension. ...

[HC]: When some nodes (not all) support the extension, FRR may work for some
failures.

Best Regards, 

Huaimo

  _____  

From: spring <[email-masked] <mailto:[email-masked]> > on
behalf of [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> >
Sent: Thursday, January 27, 2022 12:40 PM
To: 'Huzhibo' <[email-masked] <mailto:[email-masked]> >;
[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 

Hi,

 

 

Stephane

 

Hi,

Please find more inline.

Hi,

Please find more inline.

Hi slitkows :

Thanks

Zhibo Hu

Hi 

 

 

SR-TE protection    

   [RFC7356].

 

Brgds,

Stephane

Dear WG,

<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%7Cec704a1a740841cf330108d9e1bc3617%7C
0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789020781089815%7CUnknown%7CTW
FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C1000&sdata=AP4sfZJYO%2Fq8ICziVDI4pO0I7u%2B0jCzB%2BwhawN8nyiQ%3D&reserved=
0>
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwa
rding/

 

Thanks!

Bruno, Jim, Joel

---

From: <[email-masked]>
Date: Fri, 28 Jan 2022 09:58:13 +0100

Hi

[HZB2]First: This document does not require that all affected traffic be
directed to "one" neighbor node, and traffic is still balanced on all
different neighbor nodes.

[SLI3] Again, purely theoretical, it depends on the network topology, where
is the traffic coming from and number of neighbor nodes supporting the PF
behavior.  Traffic will follow SPT to the closest PF node: there could be
ECMP or not, the path to PF node could be well-sized or not. 

Sent: vendredi 28 janvier 2022 02:56

Hi,

---------->[HZB2]As the example you have mentioned,  Packet loss occurs only
when C converges, but B does not converge. 

                The packet loss time depends on the IGP convergence time and
is much shorter than the SR-TE rerouting time. 

                What I want to say is that even if some nodes you mentioned
do not support proxy forwarding, this solution is useful for speeding up
convergence.

---------->[HZB2]First: This document does not require that all affected
traffic be directed to "one" neighbor node, and traffic is still balanced on
all different neighbor nodes.

Second: All local FRR mechanisms take effect before convergence. In this
case, other nodes on the network still route to the faulty node. Can you
give an example?. FRR is performed when traffic does not need to be routed
to the neighboring node of the faulty node.

Stephane

 

Hi,

Please find more inline.

Hi,

Please find more inline.

Hi slitkows :

Thanks

Zhibo Hu

Hi 

 

 

SR-TE protection    

   [RFC7356].

 

Brgds,

Stephane

Dear WG,

 

Thanks!

Bruno, Jim, Joel

---

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

Please see inline.

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

Hi

[HZB2]First: This document does not require that all affected traffic be directed to "one" neighbor node, and traffic is still balanced on all different neighbor nodes.

[SLI3] Again, purely theoretical, it depends on the network topology, where is the traffic coming from and number of neighbor nodes supporting the PF behavior.  Traffic will follow SPT to the closest PF node: there could be ECMP or not, the path to PF node could be well-sized or not.

[HZB3]Sure,    I mean the same is true with other local FRR technologies, even with IGP, and IGP shortest path can't guarantee that traffic will not converge at certain node.

Hi,

Stephane

Hi,

Please find more inline.

Hi,

Please find more inline.

Hi slitkows :

Thanks

Zhibo Hu

Hi

SR-TE protection

Brgds,

Stephane

Dear WG,

Thanks!
Bruno, Jim, Joel

Thank you.

---

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

Hi Stephane,

     Thank you for your reply.
     My response is inline below with [HC2].

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

Hi,

[SLI3]: MAY or MAY NOT, there is absolutely no guarantee, then an SP who wants to keep the guarantee of FRR (FRR is a guaranteed SLA to their customers), they must deploy everywhere.

I’m always trying to think with realistic deployments in mind, not just theoretical case on paper.

[HC2]: In some real networks, there are some features that are deployed on some nodes but not all their nodes.

From: Huaimo Chen <[email-masked]>
Sent: jeudi 27 janvier 2022 23:03
To: [email-masked]; 'Huzhibo' <[email-masked]>; [email-masked]; 'SPRING WG' <[email-masked]>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Hi Stephane,

Best Regards,

Huaimo

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 27, 2022 12:40 PM
To: 'Huzhibo' <[email-masked]<mailto:[email-masked]>>; [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

Hi,

Stephane

Hi,

Please find more inline.

Hi,

Please find more inline.

Hi slitkows :

Thanks

Zhibo Hu

Hi

SR-TE protection

   [RFC7356].

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%7C5cfab285c5b4447ade8b08d9e239cad6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789560131929812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ERZ1QJnIk1pmU7EVklmVcec1xN5Z8DRcfv%2FZ%2Fl5nchQ%3D&reserved=0>

Thanks!

Bruno, Jim, Joel

Thank you.

---

From: <[email-masked]>
Date: Mon, 31 Jan 2022 14:06:44 +0100

[HZB3]Sure,    I mean the same is true with other local FRR technologies,
even with IGP, and IGP shortest path can't guarantee that traffic will not
converge at certain node.

[SLI4] Yes and No, in IP/SR FRR solutions (not talking about midpoint
protection), when upstream nodes are converging, they converge on a path
that will forward the traffic properly to the destination. Exception is if
uloop forms but this is solved using uloop avoidance mechanism. Here the
problem is slightly different, as even with uloop avoidance, traffic may
still break.

I just want to re-emphasis my point which is your solution doesn't solve
completely the problem in partial deployment, so complete deployment is
necessary, so the gain is questionable and not really measurable.

 

Sent: vendredi 28 janvier 2022 10:57

Please see inline.

Hi

[HZB3]Sure,    I mean the same is true with other local FRR technologies,
even with IGP, and IGP shortest path can't guarantee that traffic will not
converge at certain node.

 

Hi,

Stephane

 

Hi,

Please find more inline.

Hi,

Please find more inline.

Hi slitkows :

Thanks

Zhibo Hu

Hi 

 

 

SR-TE protection    

   [RFC7356].

 

Brgds,

Stephane

Dear WG,

 

Thanks!

Bruno, Jim, Joel

---

From: Huzhibo <[email-masked]>
Date: Tue, 1 Feb 2022 00:19:18 +0000

[SLI4] Yes and No, in IP/SR FRR solutions (not talking about midpoint protection), when upstream nodes are converging, they converge on a path that will forward the traffic properly to the destination. Exception is if uloop forms but this is solved using uloop avoidance mechanism. Here the problem is slightly different, as even with uloop avoidance, traffic may still break.

I just want to re-emphasis my point which is your solution doesn’t solve completely the problem in partial deployment, so complete deployment is necessary, so the gain is questionable and not really measurable.

 【HZB】When the nodes that support pf converge, the flow can be restored. Obviously, even if there are nodes that do not support it, the convergence will still be speed up.

胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: [email-masked]

发件人：slitkows.ietf <[email-masked]>
收件人：Huzhibo <[email-masked]>;bruno.decraene <[email-masked]>;'SPRING WG' <[email-masked]>
时 间：2022-01-31 21:06:57
主 题：RE: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

[HZB3]Sure,    I mean the same is true with other local FRR technologies, even with IGP, and IGP shortest path can't guarantee that traffic will not converge at certain node.
[SLI4] Yes and No, in IP/SR FRR solutions (not talking about midpoint protection), when upstream nodes are converging, they converge on a path that will forward the traffic properly to the destination. Exception is if uloop forms but this is solved using uloop avoidance mechanism. Here the problem is slightly different, as even with uloop avoidance, traffic may still break.
I just want to re-emphasis my point which is your solution doesn’t solve completely the problem in partial deployment, so complete deployment is necessary, so the gain is questionable and not really measurable.
From: Huzhibo <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 28 janvier 2022 10:57
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
Please see inline.

Hi

Hi,

[SLI] Your statement is purely theoretical and life in real networks is not theoretical. You cannot predict which router will converge first (routers may have different CPUs, may have different tasks to execute…). B may converge first maybe, but maybe it will be C or D… no one knows and it’s unpredictable. So at the end, if you want to guarantee the mechanism to work, all routers have to support the mechanism.
                 --------->[HZB]IGP convergence is much faster than SR-TE rerouting,Therefore, even if node B is slower than node C and node D in the previous example, the convergence time of the SR-TE path is far shorter than the convergence time of the SR-TE path. If some nodes in the network do not support the convergence, convergence may exceed 50 ms in some scenarios. If all nodes in the network support the convergence, That would result in better convergence performance.

>[HZB2]As the example you have mentioned,  Packet loss occurs only when C converges, but B does not converge.

Stephane

Hi,

Please find more inline.

Hi,

Please find more inline.

Hi slitkows :

Thanks

Zhibo Hu
From: spring [mailto:[email-masked]]On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, January 26, 2022 1:13 AM
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

Hi

Itoptimized the number of entries in the Context Table.This solution solves the connectivity problem after IGP convergence, and protects binding segments.

[SLI] Your statement is purely theoretical and life in real networks is not theoretical. You cannot predict which router will converge first (routers may have different CPUs, may have different tasks to execute…). B may converge first maybe, but maybe it will be C or D… no one knows and it’s unpredictable. So at the end, if you want to guarantee the mechanism to work, all routers have to support the mechanism.
                   --------->[HZB]IGP convergence is much faster than SR-TE rerouting,Therefore, even if node B is slower than node C and node D in the previous example, the convergence time of the SR-TE path is far shorter than the convergence time of the SR-TE path. If some nodes in the network do not support the convergence, convergence may exceed 50 ms in some scenarios. If all nodes in the network support the convergence, That would result in better convergence performance.

[SLI] Control plane aspects of IGPs have to be discussed in LSR, not in SPRING. So please take the discussion to LSR for the control plane and forwarding aspects could be further described in [I-D.ietf-spring-segment-protection-sr-te-paths]if WGs agrees that BSID is interesting to solve.
  --------->[HZB]Sure.We will consider whether we need to divest some of it into the LSR.

SR-TE protection

This is not a requirement; this is an IS-IS solution description that has to be discussed in LSR not in SPRING.
--------->[HZB]Sure.We will consider whether we need to divest some of it into the LSR.

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,

Thanks!
Bruno, Jim, Joel

Thank you.