Hi Authors, I support the publication of this draft.
I noticed a couple of minor issues that you may consider in your next version: [Line numbers from idnits] 153 OSPFv3 that enable a router to advertise TLVs that identify (a) 154 calculation-type, (b) specify a metric-type, and (c) describe a set Should be “that (a) identify” 313 for a given Flexible-Algorithm from the same originator SHOULD select 314 the first advertisement in the lowest numbered LSP. “SHOULD” should be changed to “MUST”. Thanks, Yingzhen > On Jun 17, 2021, at 8:44 AM, [email protected] wrote: > > OK. Crystal clear. > > Thanks Peter. > > --Bruno > >> -----Original Message----- >> From: Peter Psenak [mailto:[email protected]] >> Sent: Thursday, June 17, 2021 4:59 PM >> To: DECRAENE Bruno INNOV/NET <[email protected]>; Acee Lindem >> (acee) <[email protected]>; [email protected] >> Cc: [email protected]; Christian Hopps <[email protected]>; >> draft-ietf-lsr-flex- >> [email protected] >> Subject: Re: Second Working Last Call for draft-ietf-lsr-flex-algo >> >> Hi Bruno, >> >> On 17/06/2021 16:12, [email protected] 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:[email protected]] *On Behalf Of *Acee Lindem (acee) >>> *Sent:* Wednesday, June 16, 2021 4:01 PM >>> *To:* [email protected] >>> *Cc:* [email protected]; Christian Hopps <[email protected]>; >>> [email protected] >>> *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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
