Re: [Lsr] WG AdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Yingzhen Qu <[e-mail]>]

Les, thanks for the reminder.

Liyan, you can post the WG version with a file name as Les suggested. Like
Chris mentioned, X can replace Y. If you run into issues, please let us
know.

Thanks,
Yingzhen

On Tue, Mar 12, 2024 at 9:38 PM Christian Hopps <[e-mail]> wrote:

> I am not aware of any "inherited" requirement. We link documents (X
> replaces Y) in the datatracker by choosing whatever document we want as
> "replaces". You can post the document with whatever name changes you want
> and the chairs can either accept it and it gets posted or not.
>
> Thanks,
> Chris.
>
> > On Mar 12, 2024, at 23:26, Liyan Gong <[e-mail]> wrote:
> >
> > Hi Yingzhen,Les and WG,
> >
> > Thank you. The first version will be updated soon with the name
> draft-ietf-lsr-ospf-unreachable-link since the first version name needs to
> be inherited.
> > The proposed name will be reflected in later versions. Thank you Les for
> your good suggestion. It is more apt.
> > Any comments are always welcome.
> >
> > Best Regards,
> > Liyan
> >
> > ----邮件原文----
> > 发件人："Les Ginsberg (ginsberg)" <[e-mail]>
> > 收件人：Yingzhen Qu  <[e-mail]>,Liyan Gong <
> [e-mail]>
> > 抄 送: "[e-mail]" <[e-mail]>,Acee Lindem <
> [e-mail]>,Gyan Mishra  <[e-mail]>,lsr <
> [e-mail]>,lsr-chairs  <[e-mail]>,ketan Talaulikar <
> [e-mail]>
> > 发送时间：2024-03-13 04:27:46
> > 主题：RE: [Lsr] WG
> AdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
> >
> >    Or – if the authors want to consider my comments – replace
> “unreachable” in the name with something more apt – perhaps:
> >
> > “lsr-ospf-max-link-metric”
> >
> > 😊
> >
> >    Les
> >
> >
> > From: Lsr <[e-mail]> On Behalf Of Yingzhen Qu
> > Sent: Tuesday, March 12, 2024 1:11 PM
> > To: Liyan Gong <[e-mail]>
> > Cc: [e-mail]; Acee Lindem <[e-mail]>; Gyan Mishra
> <[e-mail]>; lsr <[e-mail]>; lsr-chairs <
> [e-mail]>; ketan Talaulikar <[e-mail]>
> > Subject: Re: [Lsr] WG Adoption
> Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
> >
> > Hi all,
> >
> > The adoption call has ended.
> >
> > There is strong consensus, and all the authors and contributors have
> replied to the IPR call thread, so this draft is now adopted.
> >
> > Authors, please upload a WG version with name
> draft-ietf-lsr-ospf-unreachable-link when the datatracker is open.
> >
> > Please continue the discussion to further refine the draft.
> >
> > Thanks,
> > Yingzhen
> >
> > On Mon, Mar 11, 2024 at 7:34PM Liyan Gong <[e-mail]>
> wrote:
> > Hi Jie,
> >
> > Thank you for your replies. Please see inline with [Liyan].
> >
> > Best Regards,
> > Liyan
> >
> >
> > ----邮件原文----
> > 发件人："Dongjie \\(Jimmy\\)" <jie.dong=[e-mail]>
> > 收件人：Acee Lindem  <[e-mail]>,Liyan Gong  <
> [e-mail]>
> > 抄 送: Gyan Mishra  <[e-mail]>,Yingzhen Qu <
> [e-mail]>,lsr  <[e-mail]>,lsr-chairs <
> [e-mail]>,ketan Talaulikar  <[e-mail]>
> > 发送时间：2024-03-11 23:11:49
> > 主题：Re: [Lsr] WG Adoption
> Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
> >
> >    Hi Acee and Liyan,
> >
> > Please see some replies inline with [Jie] :
> >
> > From: Acee Lindem [mailto:[e-mail]]
> > Sent: Sunday, March 10, 2024 5:37 AM
> > To: Liyan Gong <[e-mail]>
> > Cc: Gyan Mishra <[e-mail]>;  Dongjie (Jimmy) <
> [e-mail]>;   Yingzhen Qu <[e-mail]>;  lsr <
> [e-mail]>; lsr-chairs <[e-mail]>;   ketan Talaulikar <
> [e-mail]>
> > Subject: Re: [Lsr] WG Adoption Call
> -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
> >
> > All,
> >
> > With respect to the naming of the OSPF constants, I think we should go
> with:
> >
> >      LSLinkInfinity                    - 0xffff
> >      MaxReachableLinkMetric - 0xfffe
> >
> > LSLinkInfinity is analogous to LSInfinity.
> >
> > [Jie]  This is OK to me.
> >
> >
> >
> > See inline.
> >
> >
> >
> > On Mar 2, 2024, at 06:16, Liyan Gong <[e-mail]> wrote:
> >
> > Hi Gyan and Jie,
> > I am not entirely sure if the suggestions from Ketan in previous email
> can address these two concerns. If not fully addressed, please feel free to
> let us know.
> > Overall, this feature is applicable to all FAs, including FA0. The next
> version will further elaborate on the relationships between new features
> and FAs, as well as optimize the use-case descriptions and corresponding
> name to  reflect "Unreachable"  in a way that is easier to understand.
> > Appreciate everyone's discussion. It is very helpful.
> >
> >
> > [Jie] Thanks, this aligns with my understanding: it applies to all SPF
> computations (including Flexible Algorithms) which make use of IGP metric.
> And  it would be good to replace unreachable with some more accurate
> description.
> > [Liyan]Thanks.I am also considering this matter and hope to get your
> advice. Would it be better to use "Infinity Link" instead of " Unreachable
> Link" for both the content and the title of the draft?
> >
> > Best Regards,
> > Liyan
> >
> >
> > ----邮件原文----
> > 发件人：Gyan Mishra  <[e-mail]>
> > 收件人："Dongjie (Jimmy)" <jie.dong=[e-mail]>
> > 抄 送: Yingzhen Qu  <[e-mail]>,lsr  <[e-mail]>,lsr-chairs
> <[e-mail]>
> > 发送时间：2024-03-01 11:27:32
> > 主题：Re: [Lsr] WG Adoption Call -
> draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
> > Hi Jie
> >
> > Some answers in-line
> >
> > On Thu, Feb 29, 2024 at 2:31 AM Dongjie (Jimmy) <jie.dong=
> [e-mail]> wrote:
> > Hi Yingzhen,
> >
> > I’ve read the latest version of this document and support its adoption.
> It is a useful  feature in general to exclude some of the links  from SPF
> computation.
> >
> > I also have some comments for the authors to consider, they can be
> solved after the adoption.
> >
> > 1.       I’m not sure the purpose is to advertise an unreachable link in
> OSPF, from the use cases in the draft, the link is still reachable and  can
> be used for some services,  just it needs be excluded from normal  SPF
> calculation. If this is correct, it is better the title of the draft and
> the name of the new capability Flag need to be updated to reflect this.
> >
> > LSLinkInfinity would always indicate the link is unreachable. However,
> there is no real need to advertise it for other services since in these
> cases the advertisement is optional.
> >
> > [Jie] IMO once LSLinkInfinity is advertised for a link, it would impact
> all services which  rely on SPF computation based on IGP metric.  Regarding
> “for  other services the advertisement is optional”, do you mean other
> services would rely on metric-types other than IGP metric? This is true for
> services which use TE paths, while there maybe issue with  Flex Algorithm
> (as discussed below).
> >
> >  Gyan> I agree with you and that is as well stated in the draft that
> MaxLinkMetric (0xFFFF) does not exclude the link from SPF and thus
> requires RI LSA with capability bit set for MaxLinkMetric  (0xFFFF) for
> link to be excluded from SPF. Maybe “OSPF RI Capability LSA”.
> >
> > I think the capability should be LSLinkInfinity support.
> >
> > [Jie] This is OK.
> >
> >
> > 2.       In the Flex-Algo use case, if the metric of a link is set to
> MaxLinkMetric (0xFFFF) to exclude it from normal SPF computation, while a
> Flex-Algo is defined to  use the same metric type for path calculation,
> will it cause the link also be excluded from the Flex-Algo path
> computation? If not, will metric value 0xFFFF be used in the Flex-Algo
> computation? In other word, the interaction between  this new feature and
> Flex-Algo needs to be further elaborated.
> >     Gyan>  I agree that the RI LSA capability flag for MaxLinkMetric
> (0xFFFF) is applicable  to base Algo 0 and any Algo.  However AFAIK  you
> would have to explicitly set the RI flag the particular Algo.  The use case
> described in this draft is when you are using flex algo for network slicing
> meaning you have both algo 0 and 128 on the same links and  not a separate
> sub topology and in that  case in order to avoid best effort traffic from
> going over the same link used for algo 128  you would need to use this RI
> capability flag.  This concept we have talked about comes into play of
> degree of network slicing  and isolation to meet SLO SLE  requirements.
> >
> > LSLinkInfinity would exclude the link from a flex algorithm as well.
> However, the correct way to exclude it by omitting the advertisement.
> >
> > [Jie] Agree that if a Flex Algorithm uses IGP metric as its metric type,
> LSLinkInfinity  would impact the Flex-Algo computation as well. While a
> Flex-Algo  which uses other metric-types would not be impacted. Is that
> what you mean by “omitting the advertisement”?
> >
> > [Liyan]Yes, I think both of you have the same ideas which alligns with
> the draft. If misunderstanding, please Acee correct me.
> >
> > Best regards,
> > Jie
> >
> >
> > Thanks,
> > Acee
> >
> >
> >
> > Best regards,
> > Jie
> >
> > From:  Lsr [mailto:[e-mail]] On Behalf Of Yingzhen Qu
> > Sent: Friday, February 23, 2024 1:28 PM
> > To: lsr <[e-mail]>;  lsr-chairs <[e-mail]>
> > Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link
> (02/23/24 - 03/08/24)
> >
> > Hi,
> >
> > This email begins a 2 week WG adoption poll for the following draft:
> > https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/
> >
> > Please review the document and indicate your support or objections by
> March 8th, 2024.
> > Authors and contributors, please respond to the list indicating whether
> you are aware of any IPR that applies to the draft.
> > Thanks,
> > Yingzhen
> > _______________________________________________
> > Lsr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr
> > --<image001.jpg>
> > Gyan Mishra
> > Network Solutions Architect
> > Email [e-mail]
> > M 301 502-1347
> >
> >
> >
> >
> >
>
>