OK. Crystal clear. Thanks Peter.
--Bruno > -----Original Message----- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Thursday, June 17, 2021 4:59 PM > To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; Acee Lindem > (acee) <acee=40cisco....@dmarc.ietf.org>; lsr@ietf.org > Cc: lsr-...@ietf.org; Christian Hopps <cho...@chopps.org>; > draft-ietf-lsr-flex- > algo....@ietf.org > Subject: Re: Second Working Last Call for draft-ietf-lsr-flex-algo > > Hi Bruno, > > On 17/06/2021 16:12, bruno.decra...@orange.com wrote: > > Hi, > > > > I have a question/comment. > > > > I think that we all agree that FlexAlgo/Link State computation requires > > that all node use the same topology to compute their SPF. Otherwise, > > permanent forwarding loops are probable. > > > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12 > > says > > > > “ASLA Admin Group Advertisements to be used by the Flexible Algorithm > > > > Application MAY use either the Administrative Group or Extended > > > > Administrative Group encodings. » > > > > My reading of the above is that the sender of the attribute is free to > > advertise either Administrative Groups or Extended Administrative Group > > encoding (or both). > > correct. > > > > > In order to enforce topology consistency, I’m assuming that there is a > > non-expressed requirement for the node reading the attribute to be able > > to read both. (ie. MUST support the reading of both encodings). > > yes, the receiver MUST be able to accept both. > > > > > > Is this a correct assumption? > > > > - if so, could this requirement be written in the document. (If we have > > to choose one, I’d rather have the “MUST” requirement expressed rather > > than the “MAY”) > > will add to the text. > > thanks, > Peter > > > > > > - if not, how is the topology made consistent across all nodes? > > > > Thank you, > > > > Regards, > > > > --Bruno > > > > *From**:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem (acee) > > *Sent:* Wednesday, June 16, 2021 4:01 PM > > *To:* lsr@ietf.org > > *Cc:* lsr-...@ietf.org; Christian Hopps <cho...@chopps.org>; > > draft-ietf-lsr-flex-algo....@ietf.org > > *Subject:* [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo > > > > After the first successful WG last call, the authors discovered that > > some re-work was needed for OSPF AS External route calculation – > > specifically with respect to the Flex Algorithm ASBR metrics and > > calculation. This was fixed and there were clarifications in the IANA > > section (see versions -14 and -15). The draft has been stable since > > April and we are now ready to WG last call the updated version. > > > > Without further ado, this begins a 2 week WG Last Call, ending on July > > 1st, 2021, for draft-ietf-lsr-flex-algo > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ > > > > All authors, please indicate by sending an email to the list, whether > > you aware of any other IPR beyond what is already posted: > > > > [>From > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo] > > > > https://datatracker.ietf.org/ipr/3910/ > > > > https://datatracker.ietf.org/ipr/3248/ > > > > Thanks, > > > > Chris & Acee. > > > > > ______________________________________________________________________ > ___________________________________________________ > > > > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
