Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

[Alexander Vainshtein]

Peter.
Again lot of thanks.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

-Original Message-
From: Peter Psenak  
Sent: Monday, May 4, 2020 11:06 AM
To: Alexander Vainshtein ; 
shrad...@juniper.net; cfils...@cisco.com; ket...@cisco.com; 
arkadiy.gu...@thomsonreuters.com
Cc: lsr@ietf.org; spr...@ietf.org; rt...@ietf.org; Michael Gorokhovsky 
; Ron Sdayoor 
Subject: Re: SRLG usage in the IGP Flexible Algorithm draft

Hi Sasha,

On 03/05/2020 09:46, Alexander Vainshtein wrote:
> Peter,
> 
> Lots of thanks for a prompt response.
> 
> My reading of your response is as following:
> 
> There are two different ways in which SRLG information can be used 
> with Flexible Algorithms:
> 
> 1.In a context of a single Flexible Algorithm, it can be used for 
> computation of backup paths (e.g., as described in the TI-LFA draft).
> This usage does not require association of any specific SRLG with the 
> given Flexible Algorithm.
> 
> 2.In the context of multiple Flexible Algorithms it can be used for 
> creating disjoint sets of paths by pruning the links belonging to a 
> specific SRLG from the topology on which a specific Flexible Algorithm 
> computes its paths. This usage:
> 
> a.Extends the definition of the topology used by a given Flexible 
> Algorithm that can be defined using Admin groups (a.k.a. affinities)
> 
> b.Facilitates usage of already deployed SRLG configurations where such 
> configuration have been in place
> 
> c.Requires explicit association of a given Flexible Algorithm with a 
> specific set of SRLG as defined in the current Flex Algo draft.
> 
> The two usages mentioned above are strictly orthogonal.

yes, above is exactly right

> 
> If the understanding above is correct, it makes to me sense to add the 
> corresponding clarifying text to the draft.

sure, I will add it in a next version.

thanks,
Peter


> 
> Regards,
> 
> Sasha
> 
> Office: +972-39266302
> 
> Cell:  +972-549266302
> 
> Email:   alexander.vainsht...@ecitele.com
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Friday, May 1, 2020 12:57 PM
> To: Alexander Vainshtein ;
> shrad...@juniper.net; cfils...@cisco.com; ket...@cisco.com; 
> arkadiy.gu...@thomsonreuters.com
> Cc: lsr@ietf.org; spr...@ietf.org; rt...@ietf.org; Michael Gorokhovsky 
> ; Ron Sdayoor 
> 
> Subject: Re: SRLG usage in the IGP Flexible Algorithm draft
> 
> Alexander,
> 
> On 30/04/2020 17:21, Alexander Vainshtein wrote:
> 
>  > Hi all,
> 
>  >
> 
>  > I have a question about the proposed usage of SRLG in the IGP 
> Flexible
> 
>  > Algorithm
>  2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-flex-algo-07>
> draft.
> 
>  >
> 
>  > This usage is defined Section 12 of the draft with the reference to
> 
>  > the SRLG exclude rule as following:
> 
>  >
> 
>  >
> 
>  >
> 
>  >    2.  Check if any exclude SRLG rule is part of the
> 
>  > Flex-Algorithm
> 
>  >
> 
>  >    definition.  If such exclude rule exists, check if the link 
> is
> 
>  >
> 
>  >    part of any SRLG that is also part of the SRLG exclude rule.
> 
>  > If
> 
>  >
> 
>  >    the link is part of such SRLG, the link MUST be pruned from 
> the
> 
>  >
> 
>  >    computation.
> 
>  >
> 
>  > This looks effectively undistinguishable from the usage of the 
> exclude
> 
>  > Admin groups rule as described in the same Section 12 of the draft:
> 
>  >
> 
>  >    1.  Check if any exclude rule is part of the Flex-Algorithm
> 
>  >
> 
>  >    definition.  If such exclude rule exists, check if any color
> 
>  > that
> 
>  >
> 
>  >    is part of the exclude rule is also set on the link.  If 
> such a
> 
>  >
> 
>  >    color is set, the link MUST be pruned from the computation.
> 
>  >
> 
>  >  From my POV, with such a definition, there is no need in the
> 
>  > dedicated “Exclude SRLG” rule as part of the specification of the
> 
>  > Flexible Algorithm, since such the SRLG Exclude rule can be 
> replaced
> 
>  > with a matching Exclude All rule  using Admin groups.
> 
> there is one very important point. Maintaining the affinities is 
> operationally complex. Some networks have already deployed SRLGs. If 
> SRLG exclude with flex-algo gives people what they want, asking them 
> to deploy affinities would be redundant. That's the main point.
> 
> Simple use case:
> 
> I have two SRLGs in the network. For some specific traffic I want to 
> send the data via two independent streams. I want to avoid single SRLG 
> failure to affect both streams. I define two flex-algos, each one 
> excluding one SRLG. No need to define extra affinities. This is btw 
> not an academical example, this has been requested by real users.
> 
>  >
> 
>  > I also think that such a usage of SRLG does not fit the needs of 
> the
> 
>  > TI-LFA
> 
>  > 
>  
>  > 
> 

Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

[Peter Psenak]

Hi Sasha,

On 03/05/2020 09:46, Alexander Vainshtein wrote:

Peter,

Lots of thanks for a prompt response.

My reading of your response is as following:

There are two different ways in which SRLG information can be used with 
Flexible Algorithms:


1.In a context of a single Flexible Algorithm, it can be used for 
computation of backup paths (e.g., as described in the TI-LFA draft). 
This usage does not require association of any specific SRLG with the 
given Flexible Algorithm.


2.In the context of multiple Flexible Algorithms it can be used for 
creating disjoint sets of paths by pruning the links belonging to a 
specific SRLG from the topology on which a specific Flexible Algorithm 
computes its paths. This usage:


a.Extends the definition of the topology used by a given Flexible 
Algorithm that can be defined using Admin groups (a.k.a. affinities)


b.Facilitates usage of already deployed SRLG configurations where such 
configuration have been in place


c.Requires explicit association of a given Flexible Algorithm with a 
specific set of SRLG as defined in the current Flex Algo draft.


The two usages mentioned above are strictly orthogonal.


yes, above is exactly right



If the understanding above is correct, it makes to me sense to add the 
corresponding clarifying text to the draft.


sure, I will add it in a next version.

thanks,
Peter




Regards,

Sasha

Office: +972-39266302

Cell:  +972-549266302

Email:   alexander.vainsht...@ecitele.com

-Original Message-
From: Peter Psenak 
Sent: Friday, May 1, 2020 12:57 PM
To: Alexander Vainshtein ; 
shrad...@juniper.net; cfils...@cisco.com; ket...@cisco.com; 
arkadiy.gu...@thomsonreuters.com
Cc: lsr@ietf.org; spr...@ietf.org; rt...@ietf.org; Michael Gorokhovsky 
; Ron Sdayoor 

Subject: Re: SRLG usage in the IGP Flexible Algorithm draft

Alexander,

On 30/04/2020 17:21, Alexander Vainshtein wrote:

 > Hi all,

 >

 > I have a question about the proposed usage of SRLG in the IGP Flexible

 > Algorithm 
 
draft.


 >

 > This usage is defined Section 12 of the draft with the reference to

 > the SRLG exclude rule as following:

 >

 >

 >

 >    2.  Check if any exclude SRLG rule is part of the

 > Flex-Algorithm

 >

 >    definition.  If such exclude rule exists, check if the link is

 >

 >    part of any SRLG that is also part of the SRLG exclude rule.

 > If

 >

 >    the link is part of such SRLG, the link MUST be pruned from the

 >

 >    computation.

 >

 > This looks effectively undistinguishable from the usage of the exclude

 > Admin groups rule as described in the same Section 12 of the draft:

 >

 >    1.  Check if any exclude rule is part of the Flex-Algorithm

 >

 >    definition.  If such exclude rule exists, check if any color

 > that

 >

 >    is part of the exclude rule is also set on the link.  If such a

 >

 >    color is set, the link MUST be pruned from the computation.

 >

 >  From my POV, with such a definition, there is no need in the

 > dedicated “Exclude SRLG” rule as part of the specification of the

 > Flexible Algorithm, since such the SRLG Exclude rule can be replaced

 > with a matching Exclude All rule  using Admin groups.

there is one very important point. Maintaining the affinities is 
operationally complex. Some networks have already deployed SRLGs. If 
SRLG exclude with flex-algo gives people what they want, asking them to 
deploy affinities would be redundant. That's the main point.


Simple use case:

I have two SRLGs in the network. For some specific traffic I want to 
send the data via two independent streams. I want to avoid single SRLG 
failure to affect both streams. I define two flex-algos, each one 
excluding one SRLG. No need to define extra affinities. This is btw not 
an academical example, this has been requested by real users.


 >

 > I also think that such a usage of SRLG does not fit the needs of the

 > TI-LFA

 >  2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rtgwg-segment-routing-ti-lfa-0

 > 3> draft that considers an SRLG as a resource that fails when any of

 > the links/nodes comprising it fails. E.g., it says in Section 2:

 >

 >     The Point of Local Repair (PLR), S, needs to find a node Q (a

 > repair

 >

 >     node) that is capable of safely forwarding the traffic to a

 >

 >     destination D affected by the failure of the protected link L, a

 > set

 >

 >     of links including L (SRLG), or the node F itself.  The PLR also

 >

 >     needs to find a way to reach Q without being affected by the

 >

 >     convergence state of the nodes over the paths it wants to use to

 >

 >     reach Q: the PLR needs a loop-free path to reach Q.

I see no conflict between the LFA draft and flex-algo one. If you do, 
please be precise 

Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

[Alexander Vainshtein]

Peter,

Lots of thanks for a prompt response.



My reading of your response is as following:

There are two different ways in which SRLG information can be used with 
Flexible Algorithms:

1.   In a context of a single Flexible Algorithm, it can be used for 
computation of backup paths (e.g., as described in the TI-LFA draft). This 
usage does not require association of any specific SRLG with the given Flexible 
Algorithm.

2.   In the context of multiple Flexible Algorithms it can be used for 
creating disjoint sets of paths by pruning the links belonging to a specific 
SRLG from the topology on which a specific Flexible Algorithm computes its 
paths. This usage:

a.   Extends the definition of the topology used by a given Flexible 
Algorithm that can be defined using Admin groups (a.k.a. affinities)

b.   Facilitates usage of already deployed SRLG configurations where such 
configuration have been in place

c.   Requires explicit association of a given Flexible Algorithm with a 
specific set of SRLG as defined in the current Flex Algo draft.

The two usages mentioned above are strictly orthogonal.



If the understanding above is correct, it makes to me sense to add the 
corresponding clarifying text to the draft.



Regards,

Sasha



Office: +972-39266302

Cell:  +972-549266302

Email:   alexander.vainsht...@ecitele.com



-Original Message-
From: Peter Psenak 
Sent: Friday, May 1, 2020 12:57 PM
To: Alexander Vainshtein ; 
shrad...@juniper.net; cfils...@cisco.com; ket...@cisco.com; 
arkadiy.gu...@thomsonreuters.com
Cc: lsr@ietf.org; spr...@ietf.org; rt...@ietf.org; Michael Gorokhovsky 
; Ron Sdayoor 
Subject: Re: SRLG usage in the IGP Flexible Algorithm draft



Alexander,



On 30/04/2020 17:21, Alexander Vainshtein wrote:

> Hi all,

>

> I have a question about the proposed usage of SRLG in the IGP Flexible

> Algorithm 
> 
>  draft.

>

> This usage is defined Section 12 of the draft with the reference to

> the SRLG exclude rule as following:

>

>

>

>2.  Check if any exclude SRLG rule is part of the

> Flex-Algorithm

>

>definition.  If such exclude rule exists, check if the link is

>

>part of any SRLG that is also part of the SRLG exclude rule.

> If

>

>the link is part of such SRLG, the link MUST be pruned from the

>

>computation.

>

> This looks effectively undistinguishable from the usage of the exclude

> Admin groups rule as described in the same Section 12 of the draft:

>

>1.  Check if any exclude rule is part of the Flex-Algorithm

>

>definition.  If such exclude rule exists, check if any color

> that

>

>is part of the exclude rule is also set on the link.  If such a

>

>color is set, the link MUST be pruned from the computation.

>

>  From my POV, with such a definition, there is no need in the

> dedicated “Exclude SRLG” rule as part of the specification of the

> Flexible Algorithm, since such the SRLG Exclude rule can be replaced

> with a matching Exclude All rule  using Admin groups.



there is one very important point. Maintaining the affinities is operationally 
complex. Some networks have already deployed SRLGs. If SRLG exclude with 
flex-algo gives people what they want, asking them to deploy affinities would 
be redundant. That's the main point.



Simple use case:



I have two SRLGs in the network. For some specific traffic I want to send the 
data via two independent streams. I want to avoid single SRLG failure to affect 
both streams. I define two flex-algos, each one excluding one SRLG. No need to 
define extra affinities. This is btw not an academical example, this has been 
requested by real users.





>

> I also think that such a usage of SRLG does not fit the needs of the

> TI-LFA

>  2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rtgwg-segment-routing-ti-lfa-0

> 3> draft that considers an SRLG as a resource that fails when any of

> the links/nodes comprising it fails. E.g., it says in Section 2:

>

> The Point of Local Repair (PLR), S, needs to find a node Q (a

> repair

>

> node) that is capable of safely forwarding the traffic to a

>

> destination D affected by the failure of the protected link L, a

> set

>

> of links including L (SRLG), or the node F itself.  The PLR also

>

> needs to find a way to reach Q without being affected by the

>

> convergence state of the nodes over the paths it wants to use to

>

> reach Q: the PLR needs a loop-free path to reach Q.



I see no conflict between the LFA draft and flex-algo one. If you do, please be 
precise where the conflict is.



>

> To me this suggests that SRLGs are only relevant when computing backup

> paths for specific failures, e.g., an LFA for failure of 

Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

[Peter Psenak]

Alexander,

On 30/04/2020 17:21, Alexander Vainshtein wrote:

Hi all,

I have a question about the proposed usage of SRLG in the IGP Flexible 
Algorithm  draft.


This usage is defined Section 12 of the draft with the reference to the 
SRLG exclude rule as following:




   2.  Check if any exclude SRLG rule is part of the Flex-Algorithm

   definition.  If such exclude rule exists, check if the link is

   part of any SRLG that is also part of the SRLG exclude rule.  If

   the link is part of such SRLG, the link MUST be pruned from the

   computation.

This looks effectively undistinguishable from the usage of the exclude 
Admin groups rule as described in the same Section 12 of the draft:


   1.  Check if any exclude rule is part of the Flex-Algorithm

   definition.  If such exclude rule exists, check if any color that

   is part of the exclude rule is also set on the link.  If such a

   color is set, the link MUST be pruned from the computation.

 From my POV, with such a definition, there is no need in the dedicated 
“Exclude SRLG” rule as part of the specification of the Flexible 
Algorithm, since such the SRLG Exclude rule can be replaced with a 
matching Exclude All rule  using Admin groups.


there is one very important point. Maintaining the affinities is 
operationally complex. Some networks have already deployed SRLGs. If 
SRLG exclude with flex-algo gives people what they want, asking them to 
deploy affinities would be redundant. That's the main point.


Simple use case:

I have two SRLGs in the network. For some specific traffic I want to 
send the data via two independent streams. I want to avoid single SRLG 
failure to affect both streams. I define two flex-algos, each one 
excluding one SRLG. No need to define extra affinities. This is btw not 
an academical example, this has been requested by real users.





I also think that such a usage of SRLG does not fit the needs of the 
TI-LFA 
 
draft that considers an SRLG as a resource that fails when any of the 
links/nodes comprising it fails. E.g., it says in Section 2:


    The Point of Local Repair (PLR), S, needs to find a node Q (a repair

    node) that is capable of safely forwarding the traffic to a

    destination D affected by the failure of the protected link L, a set

    of links including L (SRLG), or the node F itself.  The PLR also

    needs to find a way to reach Q without being affected by the

    convergence state of the nodes over the paths it wants to use to

    reach Q: the PLR needs a loop-free path to reach Q.


I see no conflict between the LFA draft and flex-algo one. If you do, 
please be precise where the conflict is.




To me this suggests that SRLGs are only relevant when computing backup 
paths for specific failures, e.g., an LFA for failure of a link hat 
belongs to a specific SRLG must be computed in the topology from which 
all the links belonging to the same SRLG are pruned. This understanding 
matches RFC 4090 that states in Section 6.2 “Procedures for Backup Path 
Computation”:


SRLG is a mechanism to express fate share. I see no reason why SRLG 
could not be used for other than LFA purposes.


thanks,
Peter




   - The backup LSP cannot traverse the downstream node and/or link

     whose failure is being protected against.  Note that if the PLR

     is the penultimate hop, node protection is not possible, and

     only the downstream link can be avoided. The backup path may be

     computed to be SRLG disjoint from the downstream node and/or

     link being avoided.

If SRLGs are only relevant for computation of backup paths, it is not 
clear to me if they should be part of the definition of a specific 
Flexible Algorithm.


What, if anything, did I miss?

Regards, and lots of thanks in advance,

Sasha

Office: +972-39266302

Cell:  +972-549266302

Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains 
information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this
transmission in error, please inform us by e-mail, phone or fax, and 
then delete the original

and all copies thereof.
___


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr