I agree with Dirk. However, we also have the more recent https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/
Thanks, Ketan On Fri, Nov 15, 2024 at 2:24 PM Dirk Goethals (Nokia) <dirk.goethals= 40nokia....@dmarc.ietf.org> wrote: > Hi Shasha, > See inline. > Regards, > Dirk > > > 1. I have a question about usage of protected and unprotected Adj-SIDs > in TI-LFA: > 1. In *Section 10 > > <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa#section-10>* > “*Usage of Adjacency segments in the repair list*”, the draft says > that “To avoid the possibility of this double FRR activation, an > implementation of TI-LFA MAY pick only nonprotected adjacency segments > when > building the repair list” > 2. At the same time, in Section 9 “*TI-LFA and SR algorithms*” in > the part that discusses using TI-LFA with FlexAlgo, the draft says “If > an > implementation uses the constrained SPF algorithm bound to the FlexAlgo, > then the implementation MUST only use Node-SIDs bound to the FlexAlgo > and/or Adj-SIDs that are unprotected”. > > Can you please explain why usage of unprotected Adj-SID in TI-LFA repair > paths in the case of the default SPF is OPTIONAL, while in the case of > constrained SPFs it is MANDATORY? > > > At least in SR over MPLS, the Adj-SID does not belong to a specific > FlexAlgo. > As such, protected Adj-SIDs may have a backup path that exits the > Flex Algo topology, in which case it violates the constrains of > the Flex Algo Definition (FAD) > > Regards, > Dirk > ------------------------------ > *Van:* Alexander Vainshtein <Alexander.Vainshtein= > 40rbbn....@dmarc.ietf.org> > *Verzonden:* donderdag 14 november 2024 12:45 > *Aan:* Ahmed Bashandy <abashandy.i...@gmail.com> > *CC:* John Scudder <j...@juniper.net>; Clarence Filsfils < > cfils...@cisco.com>; Stephane Litkowski <slitk...@cisco.com>; Pierre > Francois <pierre.franc...@insa-lyon.fr>; RTGWG <rtgwg@ietf.org>; > rtgwg-chairs <rtgwg-cha...@ietf.org> > *Onderwerp:* [rtgwg] Re: [EXTERNAL] Re: New Version Notification for > draft-ietf-rtgwg-segment-routing-ti-lfa-18.txt > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Ahmed, and all, > > 1. From my POV the changes made in the -18 revision of the draft > resolve inconsistency between the Abstract and the body of the draft. > 2. I have a question about usage of protected and unprotected Adj-SIDs > in TI-LFA: > 1. In *Section 10 > > <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa#section-10>* > “*Usage of Adjacency segments in the repair list*”, the draft says > that “To avoid the possibility of this double FRR activation, an > implementation of TI-LFA MAY pick only nonprotected adjacency segments > when > building the repair list” > 2. At the same time, in Section 9 “*TI-LFA and SR algorithms*” in > the part that discusses using TI-LFA with FlexAlgo, the draft says “If > an implementation uses the constrained SPF algorithm bound to the > FlexAlgo, > then the implementation MUST only use Node-SIDs bound to the FlexAlgo > and/or Adj-SIDs that are unprotected”. > > Can you please explain why usage of unprotected Adj-SID in TI-LFA repair > paths in the case of the default SPF is OPTIONAL, while in the case of > constrained SPFs it is MANDATORY? > > > > > Regards, and lots of thanks in advance, > > Sasha > > > > *From:* Ahmed Bashandy <abashandy.i...@gmail.com> > *Sent:* Wednesday, November 13, 2024 10:01 PM > *To:* Bruno Decraene <bruno.decra...@orange.com>; Clarence Filsfils < > cfils...@cisco.com>; Dan Voyer <daniel.vo...@bell.ca>; Pierre Francois < > pierre.franc...@insa-lyon.fr>; Stephane Litkowski <slitk...@cisco.com>; > RTGWG <rtgwg@ietf.org>; rtgwg-chairs <rtgwg-cha...@ietf.org>; James > Guichard <james.n.guich...@futurewei.com> > *Cc:* John Scudder <j...@juniper.net>; superu...@gmail.com > *Subject:* [EXTERNAL] [rtgwg] Re: New Version Notification for > draft-ietf-rtgwg-segment-routing-ti-lfa-18.txt > > > > Hi > > I uploaded version 18 of the ti-lfa draft to address the two DISCUSS > items in > *https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/ballot/ > <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/ballot>* > > - To address John Scudder's Discuss, I made the modifications to remove > the word "key" from the abstract as suggested by Sasha at > *https://mailarchive.ietf.org/arch/msg/rtgwg/nWR4uYaT3T30XRiyRdAoIqO22AM/ > <https://mailarchive.ietf.org/arch/msg/rtgwg/nWR4uYaT3T30XRiyRdAoIqO22AM>* > and Pierre at > *https://mailarchive.ietf.org/arch/msg/rtgwg/zHP2qvP2Ew1oWl5G7Gq8niu8vy8/ > <https://mailarchive.ietf.org/arch/msg/rtgwg/zHP2qvP2Ew1oWl5G7Gq8niu8vy8>* > > - To address Murray Discuss (as well as as comments from others) I > removed the word "SHOULD" from sections 6.2, 6.3, and 9 as I suggested > during my presentation during the rtgwg meeting last Tuesday Nov/5/24. > The entire recording of the RTGWG meeting can be found in > *https://meetecho-player.ietf.org/playout/?session=IETF121-RTGWG-20241105-0930 > <https://meetecho-player.ietf.org/playout/?session=IETF121-RTGWG-20241105-0930>* > > The slides that I presented in in PDF format can be found in > *https://datatracker.ietf.org/meeting/121/materials/slides-121-rtgwg-02-tilfa-bgppic-00.pdf > <https://datatracker.ietf.org/meeting/121/materials/slides-121-rtgwg-02-tilfa-bgppic-00.pdf>* > > > Please take a look and see if the modifications are good to address the > two DISCUSS Items > > > Thanks > > Ahmed > > > On 11/13/24 11:16 AM, *internet-dra...@ietf.org > <internet-dra...@ietf.org>* wrote: > > A new version of Internet-Draft > draft-ietf-rtgwg-segment-routing-ti-lfa-18.txt > > has been successfully submitted by Ahmed Bashandy and posted to the > > IETF repository. > > > > Name: draft-ietf-rtgwg-segment-routing-ti-lfa > > Revision: 18 > > Title: Topology Independent Fast Reroute using Segment Routing > > Date: 2024-11-13 > > Group: rtgwg > > Pages: 27 > > URL: > > *https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-18.txt > <https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-18.txt>* > > Status: > > *https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/ > <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa>* > > HTMLized: > > *https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa > <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa>* > > Diff: > > *https://author-tools.ietf.org/iddiff?url2=draft-ietf-rtgwg-segment-routing-ti-lfa-18 > <https://author-tools.ietf.org/iddiff?url2=draft-ietf-rtgwg-segment-routing-ti-lfa-18>* > > > > Abstract: > > > > This document presents Topology Independent Loop-free Alternate Fast > > Reroute (TI-LFA), aimed at providing protection of node and adjacency > > segments within the Segment Routing (SR) framework. This Fast > > Reroute (FRR) behavior builds on proven IP Fast Reroute concepts > > being LFAs, remote LFAs (RLFA), and remote LFAs with directed > > forwarding (DLFA). It extends these concepts to provide guaranteed > > coverage in any two-connected networks using a link-state IGP. > > Although not a TI-LFA requirement or constraint, TI-LFA also brings > > the benefit of the ability to provide a backup path that follows the > > expected post-convergence path, reducing the operational need to > > control the tie-breaks among various FRR options. > > > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > rtgwg mailing list -- *rtgwg@ietf.org <rtgwg@ietf.org>* > To unsubscribe send an email to *rtgwg-le...@ietf.org > <rtgwg-le...@ietf.org>* > > > *Disclaimer* > > This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all copies, > including any attachments. > _______________________________________________ > rtgwg mailing list -- rtgwg@ietf.org > To unsubscribe send an email to rtgwg-le...@ietf.org >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
