Re: SRLG usage in the IGP Flexible Algorithm draft

[Peter Psenak <[e-mail]>]

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: [phone]
> 
> Cell:      [phone]
> 
> Email:   [e-mail]
> 
> -----Original Message-----
> From: Peter Psenak <[e-mail]>
> Sent: Friday, May 1, 2020 12:57 PM
> To: Alexander Vainshtein <[e-mail]>; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; Michael Gorokhovsky 
> <[e-mail]>; Ron Sdayoor <[e-mail]>
> 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 
> <https://clicktime.symantec.com/3Wn8dBNRoEXXTU1kJz6RrsR6H2?u=https%3A%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
> 
>  > <https://clicktime.symantec.com/3GhKPQ2JAgebW7vLidLjXRx6H2?u=https%3A%
> 
>  > 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 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: [phone]
> 
>  >
> 
>  > Cell:      [phone]
> 
>  >
> 
>  > Email: [e-mail] 
> <mailto:[e-mail]>
> 
>  >
> 
>  >
> 
>  > ______________________________________________________________________
> 
>  > _____
> 
>  >
> 
>  > 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.
> 
>  > ______________________________________________________________________
> 
>  > _____
> 
> 
> ___________________________________________________________________________
> 
> 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.
> ___________________________________________________________________________