> From: Peter Psenak [mailto:[email protected]] > > Hi Bruno, > > On 09/09/2021 15:27, [email protected] wrote: > > Hi Peter, > > > > Thanks for your answer. > > Please see inline > > > >> -----Original Message----- > >> From: Peter Psenak [mailto:[email protected]] > >> Sent: Thursday, September 9, 2021 2:52 PM > >> To: DECRAENE Bruno INNOV/NET <[email protected]>; > [email protected] > >> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo > >> > >> Hi Bruno, > >> > >> On 09/09/2021 14:43, [email protected] wrote: > >>> Hi authors, all, > >>> > >>> I have a question related to the two-way connectivity check performed on > >>> each > >> link during the FlexAlgo SPF. > >> > >> flex-algo is defined as set of: > >> > >> (a) calculation-type > >> (b) metric-type, > >> (c) a set of constraints > >> > >> Two way connectivity check for any link in the MT topology is orthogonal > >> to flex-algo and is done once only and used for all algorithms. > > > > OK. Excellent. > > Could the above be added in the specification, so that we have consistent > behaviour across implementations? > > sure, I will push it with the next revision - after the AD review.
OK. Thank you Peter. --Bruno > > thanks, > Peter > > > > > > Thanks, > > Regards, > > Bruno > >> > >> Flex-algo calculation using (a), (b), and (c) is done on top of MT > >> topology using only links for which the 2WCC has already been performed. > >> > >> > >>> > >>> Is this point documented in the document? I could not find it so far. > >>> If not, what is the (reverse connectivity) check that need to be > >>> performed on > the > >> reverse link? > >> > >> > >> none. > >> > >> thanks, > >> Peter > >> > >> > >>> > >>> A priori I could see multiple options: > >>> a) link exist > >>> b) link exist with a standard IGP metric (seem the option defined in the > >>> ISO > spec > >> §7.2.8.2) > >>> c) link exist with the FlexAlgo metric used by FlexAlgo > >>> d) link exist with the FlexAlgo metric used by FlexAlgo and link complies > >>> to > >> FlexAlgo constraints. > >>> > >>> I think we'll agree that this point requires uniformity across nodes hence > >> standardization. > >>> > >>> Personally, I don't have significant preference, but the algo defined in > >>> §13 > >> "Calculation of Flexible Algorithm Paths" could be read as defining option > >> "d" (as > >> links not following the constraints are "pruned from the computation") but > >> I'm not > >> sure that this is intended for the two-way connectivity check. > >>> > >>> Thanks, > >>> Regards, > >>> --Bruno > >>> > >>> > >>> > >>> > >> > ____________________________________________________________________ > >> _____________________________________________________ > >>> > >>> 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. > >>> > >>> _______________________________________________ > >>> Lsr mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/lsr > >>> > >>> > > > > > > > ____________________________________________________________________ > _____________________________________________________ > > > > 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. > > > > > > _________________________________________________________________________________________________________________________ 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. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
