Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Yingzhen Qu <[e-mail]>]

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, [e-mail] wrote:
> 
> OK. Crystal clear.
> 
> Thanks Peter.
> 
> --Bruno
> 
>> -----Original Message-----
>> From: Peter Psenak [mailto:[e-mail]]
>> Sent: Thursday, June 17, 2021 4:59 PM
>> To: DECRAENE Bruno INNOV/NET <[e-mail]>; Acee Lindem
>> (acee) <acee=[e-mail]>; [e-mail]
>> Cc: [e-mail]; Christian Hopps <[e-mail]>; draft-ietf-lsr-flex-
>> [e-mail]
>> Subject: Re: Second Working Last Call for draft-ietf-lsr-flex-algo
>> 
>> Hi Bruno,
>> 
>> On 17/06/2021 16:12, [e-mail] 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:[e-mail]] *On Behalf Of *Acee Lindem (acee)
>>> *Sent:* Wednesday, June 16, 2021 4:01 PM
>>> *To:* [e-mail]
>>> *Cc:* [e-mail]; Christian Hopps <[e-mail]>;
>>> [e-mail]
>>> *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.
>