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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 16 Jun 2021 14:00:59 +0000

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.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 16 Jun 2021 16:30:18 +0200

Hi Acee,

I'm not aware of any other IPR beyond what is already posted.

thanks,
Peter

On 16/06/2021 16:00, Acee Lindem (acee) wrote:
> 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.
> 
> 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]
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 16 Jun 2021 14:40:00 +0000

Hi Acee/All,

I am not aware of any undisclosed IPR related to this draft.

Thanks,
Ketan

From: Acee Lindem (acee) <[email-masked]>
Sent: 16 June 2021 19:31
To: [email-masked]
Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked]
Subject: Second Working Last Call for draft-ietf-lsr-flex-algo

Thanks,
Chris & Acee.

---

From: "Clarence Filsfils (cfilsfil)" <[email-masked]>
Date: Wed, 16 Jun 2021 17:55:40 +0000

I am not aware of any undisclosed IPR related to this document.

Cheers,
Clarence

From: Acee Lindem (acee) <[email-masked]>
Sent: Wednesday, June 16, 2021 16:01
To: [email-masked]
Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked]
Subject: Second Working Last Call for draft-ietf-lsr-flex-algo

Thanks,
Chris & Acee.

---

From: <[email-masked]>
Date: Thu, 17 Jun 2021 14:12:34 +0000

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).

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).
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”)
- if not, how is the topology made consistent across all nodes?

Thank you,
Regards,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, June 16, 2021 4:01 PM
To: [email-masked]
Cc: [email-masked]; Christian Hopps <[email-masked]>; [email-masked]
Subject: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

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.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 17 Jun 2021 16:58:41 +0200

Hi Bruno,

On 17/06/2021 16:12, [email-masked] wrote:
> 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.
> 
> 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.

> - 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

> *From**:*Lsr [mailto:[email-masked]] *On Behalf Of *Acee Lindem (acee)
> *Sent:* Wednesday, June 16, 2021 4:01 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; Christian Hopps <[email-masked]>; 
> [email-masked]
> *Subject:* [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo
> 
>    [>From

---

From: <[email-masked]>
Date: Thu, 17 Jun 2021 15:44:51 +0000

OK. Crystal clear.

Thanks Peter.

--Bruno

> -----Original Message-----
> From: Peter Psenak [mailto:[email-masked]]
> Sent: Thursday, June 17, 2021 4:59 PM
> To: DECRAENE Bruno INNOV/NET <[email-masked]>; Acee Lindem
> (acee) <acee=[email-masked]>; [email-masked]
> Subject: Re: Second Working Last Call for draft-ietf-lsr-flex-algo
> 
> Hi Bruno,
> 
> ______________________________________________________________________
> ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Gulko,Arkadiy" <[email-masked]>
Date: Wed, 16 Jun 2021 15:03:39 +0000

Thanks, Arkadiy

If you are not the intended recipient of this message (including attachments) or if you have received this message in error, immediately notify us and delete it and any attachments.

If you do not wish to receive any email messages from Edward Jones, excluding administrative communications, please email this request to [email-masked]<mailto:[email-masked]> from the email address you wish to unsubscribe.

For important additional information related to this email, visit www.edwardjones.com/disclosures/email.html.<http://www.edwardjones.com/disclosures/email.html> Edward D. Jones & Co., L.P. d/b/a Edward Jones, 12555 Manchester Road, St. Louis, MO 63131 © Edward Jones. All rights reserved.
From: Acee Lindem (acee) <[email-masked]>
Sent: Wednesday, June 16, 2021 10:01 AM
To: [email-masked]
Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked]
Subject: Second Working Last Call for draft-ietf-lsr-flex-algo

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Thanks,
Chris & Acee.

---

From: Yingzhen Qu <[email-masked]>
Date: Tue, 22 Jun 2021 13:08:37 -0700

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-masked] wrote:
> 
> OK. Crystal clear.
> 
> Thanks Peter.
> 
> --Bruno
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 24 Jun 2021 05:25:35 +0000

I support progressing this document.
Flex-algo has already been demonstrated to be useful with a number of implementations/deployments.

   Les

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, June 16, 2021 7:01 AM
To: [email-masked]
Cc: [email-masked]; Christian Hopps <[email-masked]>; [email-masked]
Subject: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

Thanks,
Chris & Acee.