Hi Gunter Understood. Thanks for the explanation.
I agree it is difficult to design for every overflow condition, however it is difficult to predict future requests that may arise. I agree we should find a common ground would work for all implementations. Kind Regards Gyan On Fri, Mar 11, 2022 at 4:48 AM Van De Velde, Gunter (Nokia - BE/Antwerp) < [email protected]> wrote: > Hi Gyan, > > > > I was talking about the use-case where we create two flex-algo’s and the > desire is that they for example avoid congruent optical paths to avoid that > a single fiber cut, would impact both streams. For some high value > live-live streams or financials this may be an important service property. > This type of flex-algo capability was a use-case about 1.5 a 2 years ago > and caused the flex-algo to add exclude-srlg into the FAD to support such > use-case. > > > > The use-case was not about FRR, or RSVP-TE or anything similar. > Advertising link properties is taken care of by the legacy and ASLA TE IGP > attributes. The requested ‘avoid congruent optical paths’ use-case added > the exclude-srlg subTLV within the flex-algo FAD, but unlike the EAG, the > SRLG can theoretically cause overflow of 255 octet subTLV under certain > (mostly theoretical) circumstance. > > > > I am in full agreement with Peter, that excluding 100s of SRLG is a > something we will unlikely encounter, but then again, I see sometimes > mythical oddness in use-case requests and I can not predict what requests > future will bring. I am not asking for bigger or multiple SRLG subTLVs, but > hope to find guidance to have implementation X behave identical/similar as > implementation Y when such condition occurs. > > > > G/ > > > > *From:* Gyan Mishra <[email protected]> > *Sent:* Thursday, March 10, 2022 5:05 AM > *To:* Tony Li <[email protected]> > *Cc:* Peter Psenak <[email protected]>; Van De Velde, Gunter (Nokia - > BE/Antwerp) <[email protected]>; lsr <[email protected]> > *Subject:* Re: [Lsr] New Version Notification for > draft-pkaneria-lsr-multi-tlv-00.txt > > > > > > Gunter > > > > The use case for SRLG is only related to RSVP-TE FRR protection is my > understanding. > > > > However, Flex Algo is only applicable to SR forwarding plane SR-MPLS and > SRv6? > > > > Correct? > > > > RSVP-TE FRR SRLG protection application can be used in parallel to SR-MPLS > or SRv6 but in that case they would be 3 different ASLA apps if used on the > same link. > > > > For SR-MPLS, SR forwarding plane you could use RSVP-TE SRLG protection or > SR-TE protection schemes. > > > > I don’t think the RSVP-TE FRR SRLG protection would apply to SR-TE > protection to use the concept of SRLG with SR-MPLS with Flex Algo or would > it apply. > > > > > > Kind Regards > > > > Gyan > > > > > > > > On Fri, Mar 4, 2022 at 1:03 PM Tony Li <[email protected]> wrote: > > > > Peter, > > > > the combination is the (a) problem and that will be fixed. We are talking > problem (b) only now. > > > > > > Ah, my apologies, I was unclear on the applicability of your statements. > > > > > > I'm not trying under-specify how to deal with overflow - we need to > specify it, no disagreement there. > > > > > > I look forward to seeing a proposal. I propose allowing multiple FAD and > concatenation of the contents. > > > > > > What I'm trying to see of we need to support the "merge" at FAD sub-TLV > level. > > > > > > I’ll agree that that’s lower priority. I think we should, as a matter of > completeness. > > > > Tony > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
