[Lsr] IETF 119 LSR Minutes Posted

[Yingzhen Qu]

Hi,

The minutes from IETF 119 LSR session has been posted:
minutes-119-lsr-202403210300-00.md (ietf.org)


Please review and send comments/corrections to the list.

Thanks,
Acee, Chris and Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Need volunteers to help with minutes

[Yingzhen Qu]

Hi,

We need a couple of volunteers to help with minutes:
HedgeDoc - Collaborative markdown notes (ietf.org)


Please let us know if you'd like to help.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Yingzhen Qu]

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  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  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)" 
> > 收件人：Yingzhen Qu  ,Liyan Gong <
> gongli...@chinamobile.com>
> > 抄 送: "jie.d...@huawei.com" ,Acee Lindem <
> acee.i...@gmail.com>,Gyan Mishra  ,lsr <
> lsr@ietf.org>,lsr-chairs  ,ketan Talaulikar <
> ketant.i...@gmail.com>
> > 发送时间：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  On Behalf Of Yingzhen Qu
> > Sent: Tuesday, March 12, 2024 1:11 PM
> > To: Liyan Gong 
> > Cc: jie.d...@huawei.com; Acee Lindem ; Gyan Mishra
> ; lsr ; lsr-chairs <
> lsr-cha...@ietf.org>; ketan Talaulikar 
> > 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 
> wrote:
> > Hi Jie,
> >
> > Thank you for your replies. Please see inline with [Liyan].
> >
> > Best Regards,
> > Liyan
> >
> >
> > 邮件原文
> > 发件人："Dongjie \\(Jimmy\\)" 
> > 收件人：Acee Lindem  ,Liyan Gong  <
> gongli...@chinamobile.com>
> > 抄 送: Gyan Mishra  ,Yingzhen Qu <
> yingzhen.i...@gmail.com>,lsr  ,lsr-chairs <
> lsr-cha...@ietf.org>,ketan Talaulikar  
> > 发送时间：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:acee.i...@gmail.com]
> > Sent: Sunday, March 10, 2024 5:37 AM
> > To: Liyan Gong 
> > Cc: Gyan Mishra ;  Dongjie (Jimmy) <
> jie.d...@huawei.com>;   Yingzhen Qu ;  lsr <
> lsr@ietf.org>; lsr-chairs ;   ketan Talaulikar <
> ketant.i...@gmail.com>
> > 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- 0x
> >  MaxReachableLinkMetric - 0xfffe
> >
> > LSLinkInfinity is analogous to LSInfinity.
> >
> > [Jie]  This is OK to me.
> >
> >
> >
> > See inline.
> >
> >
> >
> > On Mar 2, 2024, at 06:16, Liyan Gong  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 easi

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

[Yingzhen Qu]

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:34 PM Liyan Gong 
wrote:

> Hi Jie,
>
>
> Thank you for your replies. Please see inline with [Liyan].
>
>
> Best Regards,
>
> Liyan
>
>
>
> 邮件原文
> *发件人：*"Dongjie \\(Jimmy\\)" 
> *收件人：*Acee Lindem  ,Liyan Gong  <
> gongli...@chinamobile.com>
> *抄 送: *Gyan Mishra  ,Yingzhen Qu <
> yingzhen.i...@gmail.com>,lsr  ,lsr-chairs <
> lsr-cha...@ietf.org>,ketan Talaulikar  
> *发送时间：*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:acee.i...@gmail.com ]
> *Sent:* Sunday, March 10, 2024 5:37 AM
> *To:* Liyan Gong 
> *Cc:* Gyan Mishra ;  Dongjie (Jimmy) <
> jie.d...@huawei.com>;  Yingzhen Qu ;  lsr <
> lsr@ietf.org>; lsr-chairs ;  ketan Talaulikar <
> ketant.i...@gmail.com>
> *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- 0x
>
>  MaxReachableLinkMetric - 0xfffe
>
>
>
> LSLinkInfinity is analogous to LSInfinity.
>
>
>
> [Jie]  This is OK to me.
>
>
>
>
>
>
>
> See inline.
>
>
>
>
>
>
>
> On Mar 2, 2024, at 06:16, Liyan Gong  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  
> *收件人：*"Dongjie (Jimmy)" 
> *抄 送: *Yingzhen Qu  ,lsr   >,lsr-chairs  
> *发送时间：*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)  40huawei@dmarc.ietf.org> 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 

[Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link

[Yingzhen Qu]

Hi all,

There is an IPR disclosure filed for this draft on 3/8/2024:
IPR disclosures (ietf.org)


Also not all authors have responded to the IPR poll in the adoption call
thread, so I'd like to ask all the authors and contributors to answer in
this thread. The draft won't progress without answers from all authors and
contributors.

Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.


Thanks,

Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 119 LSR draft agenda posted

[Yingzhen Qu]

Hi,

The draft LSR agenda has been posted: Agenda IETF119: lsr


Please let us know if we missed your request or you see any issues.

Presenters, please upload your slides (IETF-119 : lsr
) or email
lsr-cha...@ietf.org.

Thanks,
Acee, Chris and Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Yingzhen Qu]

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 119 LSR Presentation Slot Requests

[Yingzhen Qu]

Hi,

The draft agenda for IETF 119 has been posted:
IETF 119 Meeting Agenda 

The LSR session is scheduled on Thursday Session II 13:00 - 15:00, March
21, 2024.

Please send slot requests to lsr-cha...@ietf.org before the end of the day
Wednesday March 6th.  Please include draft name and link, presenter,
desired slot length including Q

Please note that having a discussion on the LSR mailing list is a
prerequisite for a draft presentation in the WG session. If you need any
help please reach out to the chairs.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

[Yingzhen Qu]

Hi,

The configuration to enable/disable OSPFv3 Extended LSA is for migration,
please refer to RFC 8362 section 6 (RFC 8362 - OSPFv3 Link State
Advertisement (LSA) Extensibility (ietf.org)
). If it's
disabled, the router under attack won't be able to exchange extended LSAs
with other routers, and new features using only extended LSAs won't work.

How about the following changes?
old:

  /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
  The ability to disable OSPFv3 Extended LSA support can result in a
  denial of service.

new:

  /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
  The ability to disable OSPFv3 Extended LSA support can result in a
  denial of service. Any OSPFv3 extensions using only Extended
LSAs won't work.


Thanks,

Yingzhen


On Thu, Feb 1, 2024 at 9:54 AM Acee Lindem  wrote:

> Hi John,
>
> > On Feb 1, 2024, at 11:55 AM, John Scudder  wrote:
> >
> > Hi Acee, Roman, all,
> >
> > [top posting, hope that’s OK]
> >
> > After talking with Roman about this today, what I understand his
> position to be is (at least in part), since the document identifies one
> specific case of a type of attack ("The ability to disable OSPFv3 Extended
> LSA support can result in a denial of service”), shouldn’t it also list
> other cases? What’s special about "denial of service” vs. other things such
> as the ones Roman mentioned? I don’t think he was seeking an in-depth
> exploration of these, just a more complete summary list. I also wonder if
> the concern could equally be satisfied by removing the one special case.
>
> By enabling or disabling this parameter, you can only limit exchange of
> OSPFv3 LSAs between OSPFv3 routers. You cannot inject compromised LSAs into
> the OSPFv3 routing domain through modification of this parameter alone?
> How could this exploit be used to:
>
>  modify network topologies to enable select traffic to avoid
> inspection or
>  treatment by security controls; route traffic in a way that it would
> be subject
>  to inspect/modification by an adversary node; or gain access to
> otherwise
>  segregated parts of the network.
>
>
>
> Thanks,
> Acee
>
>
>
> >
> > I’m sure Roman will chime in if I’ve gotten this wrong.
> >
> > Thanks,
> >
> > —John
> >
> >> On Jan 31, 2024, at 8:50 PM, Acee Lindem  wrote:
> >>
> >>
> >>
> >>> On Jan 31, 2024, at 20:14, Acee Lindem  wrote:
> >>>
> >>>
> >>>
>  On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker <
> nore...@ietf.org> wrote:
> 
>  Roman Danyliw has entered the following ballot position for
>  draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss
> 
>  When responding, please keep the subject line intact and reply to all
>  email addresses included in the To and CC lines. (Feel free to cut
> this
>  introductory paragraph, however.)
> 
> 
>  Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>  for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
>  The document, along with other ballot positions, can be found here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
> 
> 
>  --
>  DISCUSS:
>  --
> 
>  ** Section 5.
> 
>  Write
>  operations (e.g., edit-config) to these data nodes without proper
>  protection can have a negative effect on network operations.  There
>  are the subtrees and data nodes and their sensitivity/vulnerability:
> 
> /ospf:ospf/extended-lsa-support
> /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
> The ability to disable OSPFv3 Extended LSA support can result in a
> denial of service.
> 
>  Isn’t it more than just denial of service?  In certain environments
> wouldn’t
>  the ability to modify OSPF Extended LSA configurations enable an
> attacker to:
>  modify network topologies to enable select traffic to avoid
> inspection or
>  treatment by security controls; route traffic in a way that it would
> be subject
>  to inspect/modification by an adversary node; or gain access to
> otherwise
>  segregated parts of the network.
> >>>
> >>> Only if they were able to craft extended LSAs on behalf of the
> original as well as
> >>> modify the YANG configuration added by this document. I didn’t think
> we’d have to
> >>> reiterate all the possible protocol attacks for every incremental
> enhancement.
> >>
> >> Furthermore, no one is going to use the support of extended LSAs to
> isolate OSPFv3 domains
> >> from one another. The configuration is to control migration to the
> extended LSA encodings.
> >> Please see RFC 8362 for more information on OSPFv3 Extended LSAs.
> >>
> >> Acee
> >>
> >>
> >>
> 

Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19

[Yingzhen Qu]

HI Reshad,

I've uploaded version -21, which includes the changes we discussed.

Thanks,
Yingzhen

On Mon, Jan 22, 2024 at 11:52 AM Reshad Rahman  wrote:

> Thanks Yingzhen. Yes I am good with that.
>
> Regards,
> Reshad.
>
> On Monday, January 22, 2024, 02:39:17 PM EST, Yingzhen Qu <
> yingzhen.i...@gmail.com> wrote:
>
>
> Hi Reshad,
>
> Thanks for the review.
>
> The "sid-binding-tlv" and "mt-sid-binding-tlv" are relatively big with
> more content, so I thought it might be easier to read with a container. But
> you're right, it's not following the YANG traditions, how about the
> following?
>
> container sid-binding-tlvs {
>   list sid-binding-tlv {
> key "prefix";
> uses sid-binding-tlv;
> description
>   "Sid/label binding TLV, type 149.";
>   }
>   description
> "List of sid/label binding TLVs.";
> }
> container mt-sid-binding-tlvs {
>   list mt-sid-binding-tlv {
> key "prefix mt-id";
> uses sid-binding-tlv;
> leaf mt-id {
>   type uint16;
>   description
> "A 12-bit field containing the non-zero ID
>  of the topology.";
> }
> description
>   "Multi-Topology SID/Label binding TLV, type 150.";
> reference
>   "RFC 8667 - IS-IS Extensions for Segment Routing,
>Section 2.5";
>   }
>   description
> "List of multi-topology sid/label binding TLVs.";
> }
>
> Thanks,
> Yingzhen
>
> On Mon, Jan 22, 2024 at 6:07 AM Reshad Rahman  wrote:
>
> Hi,
>
> Typically we have a container (plural) including a list (singular). In -20
> it was done the other way round. Since this is read-only, IIRC we don't
> need the container including a list as we do for read-write. Is the
> container there for convenience?
>
> Regards,
> Reshad.
>
>
>   augment /rt:routing/rt:control-plane-protocols
>   /rt:control-plane-protocol/isis:isis/isis:database
>   /isis:levels/isis:lsp:
> +--ro sid-binding-tlvs* []
> |  +--ro sid-binding-tlv
> | +--ro prefix?inet:ip-prefix
> | +--ro range? uint16
> | +--ro sid-binding-flags
> | |  +--ro flags*   identityref
> | +--ro prefix-sid-sub-tlvs* []
> | |  +--ro prefix-sid-sub-tlvs
> | | +--ro prefix-sid-sub-tlv* [sid]
> | |+--ro prefix-sid-flags
> | ||  +--ro flags*   identityref
> | |+--ro algorithm?  identityref
> | |+--ro sid uint32
> | +--ro sid-sub-tlvs* []
> | |  +--ro sid-sub-tlv
> | | +--ro length?   uint8
> | | +--ro sid?  uint32
> | +--ro unknown-tlvs
> |+--ro unknown-tlv* []
> |   +--ro type? uint16
> |   +--ro length?   uint16
> |   +--ro value?yang:hex-string
> +--ro mt-sid-binding-tlvs* []
>+--ro mt-sid-binding-tlvs
>   +--ro prefix?inet:ip-prefix
>   +--ro range? uint16
>   +--ro sid-binding-flags
>   |  +--ro flags*   identityref
>   +--ro prefix-sid-sub-tlvs* []
>   |  +--ro prefix-sid-sub-tlvs
>   | +--ro prefix-sid-sub-tlv* [sid]
>   |+--ro prefix-sid-flags
>   ||  +--ro flags*   identityref
>   |+--ro algorithm?  identityref
>   |+--ro sid uint32
>   +--ro sid-sub-tlvs* []
>   |  +--ro sid-sub-tlv
>   | +--ro length?   uint8
>   | +--ro sid?  uint32
>   +--ro unknown-tlvs
>   |  +--ro unknown-tlv* []
>   | +--ro type? uint16
>   | +--ro length?   uint16
>   | +--ro value?yang:hex-string
>   +--ro mt-id? uint16
>
> On Saturday, January 20, 2024, 06:53:52 PM EST, Reshad Rahman <
> res...@yahoo.com> wrote:
>
>
> [Yingzhen]: Thanks for catching this. I've updated the description.
>  I looked at the changes in -20. That grouping is now gone and the
> (mt-)sid-binding-tlvs lists have no key, is that the intent?
> Also container mt-sid-binding-tlvs should be renamed to mt-
> sid-binding-tlv.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Yingzhen Qu]

Hi all,

The adoption call is closed, and the document is not adopted.

The author has requested an extension of the adoption call for one week,
however since we fail to see new technical points being discussed, the
chairs decided to close the call as planned.

During the second adoption call,  the discussion has been focusing on
simplifying inter-as link discovery and topology management although there
are existing solutions. Additionally the added use cases were discussed,
but are also covered by existing solutions. No rough consensus has been
reached about the use cases, nor the solution. Please note: many of the
same points were discussed in the first adoption call.

In the future, if the authors are to request another adoption call, the
condition will be to have a discussion on the list first and achieve rough
consensus of the use case and solution.

Thanks,
Acee, Chris and Yingzhen (LSR Co-chairs)

On Thu, Jan 18, 2024 at 5:52 PM Aijun Wang 
wrote:

> Hi, Les:
>
>
>
> Let’s top post my responses to your specific questions:
>
>
>
> *1)  **LAN partitioning can occur. So R1 and R2 may be able to talk
> to each and R3 and R4 may be able to talk to each – but the two partitions
> have no connectivity. Yet all nodes will advertise the LAN subnet – which
> in your world means that you think you have full connectivity when you do
> not. *
>
> [WAJ] If the partition is occurred by design, then R1-R4 should not
> declare the same subnet; if the partition is occurred by the switch faulty,
> it needs other OAM tools to detect. This is also true for the P2P based
> existing solutions(RFC9346/RFC5392).
>
>
>
> *2)  **Your draft says: “It will be help for the router R0, to know
> the attributes of the stub links and select the optimal Anycast server to
> serve the customer's application.”.*
>
> *Given that you don’t actually know which of the anycast servers each of
> the border routers can reach (you just “assume” it is all of them) the
> ability of R0 to make a correct decision is compromised.*
>
> [WAJ] Here, “the optimal Anycast server” refer to the “the optimal
> path(exits) to Anycast server”.  The reason that we use Anycast is that all
> these servers can provide the same services. The difference is that the
> path attributes(internal links and stub link) to them.
>
>
>
> Wish the above explanations can address your concerns.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] *代表
> *Les Ginsberg (ginsberg)
> *发送时间:* 2024年1月19日 0:51
> *收件人:* Aijun Wang 
> *抄送:* 'Christian Hopps' ; 'Huzhibo' ;
> 'Acee Lindem' ; 'Yingzhen Qu' <
> yingzhen.i...@gmail.com>; lsr@ietf.org
> *主题:* Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
> (01/05/2024 - 01/19/2024)
>
>
>
> Aijun –
>
>
>
> Frankly, I have a limited tolerance for these exchanges because your
> responses to specific points are evasive.
>
> You are like a boxer whose main goal is to avoid any punch thrown by your
> opponent from landing directly. This is a pretty useful skill in a boxing
> ring, but pretty tiresome when trying to have a frank exchange of views on
> the technical points of a draft.
>
> I am unlikely to respond further after this – but please find some
> responses inline. See [LES2:].
>
>
>
> *From:* Aijun Wang 
> *Sent:* Thursday, January 18, 2024 1:29 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* 'Christian Hopps' ; 'Huzhibo' ;
> 'Acee Lindem' ; 'Yingzhen Qu' <
> yingzhen.i...@gmail.com>; lsr@ietf.org
> *Subject:* 答复: [Lsr] WG Adoption Call -
> draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
>
>
>
> Hi, Les:
>
>
>
> *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org
> ] *代表 *Les Ginsberg (ginsberg)
> *发送时间:* 2024年1月18日 0:16
> *收件人:* Aijun Wang 
> *抄送:* Christian Hopps ; Huzhibo ;
> Acee Lindem ; Yingzhen Qu ;
> lsr@ietf.org
> *主题:* Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
> (01/05/2024 - 01/19/2024)
>
>
>
> Aijun -
>
>
>
> *From:* Aijun Wang 
> *Sent:* Tuesday, January 16, 2024 10:56 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Christian Hopps ; Huzhibo ;
> Acee Lindem ; Yingzhen Qu ;
> lsr@ietf.org
> *Subject:* Re: [Lsr] WG Adoption Call -
> draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
>
>
>
> Hi, Les:
>
>
>
> Let’s keep the discussions simple.
>
>
>
> Please answer the following two questions that you haven’t responsed
> directly in previous mail:
>
> 1)How the existing point-to-point based solution(RFC9346/RFC5392)
> solve the 

Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19

[Yingzhen Qu]

Hi Reshad,

Thanks for the review.

The "sid-binding-tlv" and "mt-sid-binding-tlv" are relatively big with more
content, so I thought it might be easier to read with a container. But
you're right, it's not following the YANG traditions, how about the
following?

container sid-binding-tlvs {
  list sid-binding-tlv {
key "prefix";
uses sid-binding-tlv;
description
  "Sid/label binding TLV, type 149.";
  }
  description
"List of sid/label binding TLVs.";
}
container mt-sid-binding-tlvs {
  list mt-sid-binding-tlv {
key "prefix mt-id";
uses sid-binding-tlv;
leaf mt-id {
  type uint16;
  description
"A 12-bit field containing the non-zero ID
 of the topology.";
}
description
  "Multi-Topology SID/Label binding TLV, type 150.";
reference
  "RFC 8667 - IS-IS Extensions for Segment Routing,
   Section 2.5";
  }
  description
"List of multi-topology sid/label binding TLVs.";
}

Thanks,
Yingzhen

On Mon, Jan 22, 2024 at 6:07 AM Reshad Rahman  wrote:

> Hi,
>
> Typically we have a container (plural) including a list (singular). In -20
> it was done the other way round. Since this is read-only, IIRC we don't
> need the container including a list as we do for read-write. Is the
> container there for convenience?
>
> Regards,
> Reshad.
>
>
>   augment /rt:routing/rt:control-plane-protocols
>   /rt:control-plane-protocol/isis:isis/isis:database
>   /isis:levels/isis:lsp:
> +--ro sid-binding-tlvs* []
> |  +--ro sid-binding-tlv
> | +--ro prefix?inet:ip-prefix
> | +--ro range? uint16
> | +--ro sid-binding-flags
> | |  +--ro flags*   identityref
> | +--ro prefix-sid-sub-tlvs* []
> | |  +--ro prefix-sid-sub-tlvs
> | | +--ro prefix-sid-sub-tlv* [sid]
> | |+--ro prefix-sid-flags
> | ||  +--ro flags*   identityref
> | |+--ro algorithm?  identityref
> | |+--ro sid uint32
> | +--ro sid-sub-tlvs* []
> | |  +--ro sid-sub-tlv
> | | +--ro length?   uint8
> | | +--ro sid?  uint32
> | +--ro unknown-tlvs
> |+--ro unknown-tlv* []
> |   +--ro type? uint16
> |   +--ro length?   uint16
> |   +--ro value?yang:hex-string
> +--ro mt-sid-binding-tlvs* []
>+--ro mt-sid-binding-tlvs
>   +--ro prefix?inet:ip-prefix
>   +--ro range? uint16
>   +--ro sid-binding-flags
>   |  +--ro flags*   identityref
>   +--ro prefix-sid-sub-tlvs* []
>   |  +--ro prefix-sid-sub-tlvs
>   | +--ro prefix-sid-sub-tlv* [sid]
>   |+--ro prefix-sid-flags
>   ||  +--ro flags*   identityref
>   |+--ro algorithm?  identityref
>   |+--ro sid uint32
>   +--ro sid-sub-tlvs* []
>   |  +--ro sid-sub-tlv
>   | +--ro length?   uint8
>   | +--ro sid?  uint32
>   +--ro unknown-tlvs
>   |  +--ro unknown-tlv* []
>   | +--ro type? uint16
>   | +--ro length?   uint16
>   | +--ro value?yang:hex-string
>   +--ro mt-id? uint16
>
> On Saturday, January 20, 2024, 06:53:52 PM EST, Reshad Rahman <
> res...@yahoo.com> wrote:
>
>
> [Yingzhen]: Thanks for catching this. I've updated the description.
>  I looked at the changes in -20. That grouping is now gone and the
> (mt-)sid-binding-tlvs lists have no key, is that the intent?
> Also container mt-sid-binding-tlvs should be renamed to mt-
> sid-binding-tlv.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-isis-sr-yang-19.txt

[Yingzhen Qu]

Hi Tom,

Thanks for the review. Version -20 includes the fixes. Please see my
answers below inline.

Thanks,
Yingzhen

On Thu, Jan 18, 2024 at 4:13 AM tom petch  wrote:

> This I-D changes the names of some bits in the identity cf RFC8667.  I
> think that the description clause should then give the mapping to the
> RFC8667 name.  I see this for
> lo-bit
> pe-bit
> af-bit
> These may be excellent names but they are not what RFC8667 specifies!
>

[Yingzhen]: Unfortunately YANG doesn't allow the same identity name with
different bases. For example, l-flag is defined with base
"prefix-sid-flag", so we can't define 'l-flag" again with base
"adj-sid-flag", so I changed it to "lo-flag".

>
> As the YANG doctor review says, the description should reference RFC and
> section thereof for all identity such as r-bit.
>

[Yingzhen]: fixed.

>
> The I-D refences
> RFC8102
> draft-ietf-rtgwg-segment-routing-ti-lfa
>
> which need adding to the I-D References
>
> [Yingzhen]: Added.


> Perhaps in the YANG augment
> OLD
>  "This augments ISIS protocol configuration
>   with segment routing.";
> NEW
>  "This augments ISIS protocol configuration
>   with segment routing for the MPLS data plane.";
>
> [Yingzhen]: fixed. same for OSPF.

> Tom Petch
>
>
> 
> From: Lsr  on behalf of internet-dra...@ietf.org <
> internet-dra...@ietf.org>
> Sent: 31 December 2023 06:30
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-isis-sr-yang-19.txt
>
> Internet-Draft draft-ietf-isis-sr-yang-19.txt is now available. It is a
> work
> item of the Link State Routing (LSR) WG of the IETF.
>
>Title:   A YANG Data Model for IS-IS Segment Routing for the MPLS Data
> Plane
>Authors: Stephane Litkowski
> Yingzhen Qu
> Pushpasis Sarkar
> Ing-Wher Chen
> Jeff Tantsura
>Name:draft-ietf-isis-sr-yang-19.txt
>Pages:   31
>Dates:   2023-12-30
>
> Abstract:
>
>This document defines a YANG data module that can be used to
>configure and manage IS-IS Segment Routing for MPLS data plane.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-isis-sr-yang-19.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-isis-sr-yang-19
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19

[Yingzhen Qu]

HI Reshad,

Thanks for the review. I've uploaded version -20 to address your comments.
Details below inline.

Thanks,
Yingzhen

On Sat, Jan 13, 2024 at 4:24 PM Reshad Rahman via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Reshad Rahman
> Review result: Ready with Issues
>
> Hi all,
>
> This is my YANG Doctor review of -19. Thanks to the authors for making the
> effort to align with draft-ietf-ospf-yang (as previously requested).
>
> Comments
> 
>
> Section 3 (YANG Tree)
>
> - There are a few instances of perfix-sid-flags, should bd prefix-sid-flags
>

[Yingzhen]: fixed.

>
> - For the list below, can there be overlaps between different entries? If
> not,
> this should be documented (ideally should have been documented in RFC9020)
>
>+--rw protocol-srgb {sr-mpls:protocol-srgb}?
>   +--rw srgb* [lower-bound upper-bound]
>  +--rw lower-bounduint32
>  +--rw upper-bounduint32
>
> [Yingzhen]: There should not be overlaps. Agreed with you, this should
have been documented in RFC 9020.


> YANG Model
>
> - The identities such as r-bit, n-bit etc should all have a reference (not
> just
> the document but also the section)
>

[Yingzhen]: I added reference to each base identity.

>
> - All those identities are called x-bit but the description says flag.
> Which
> terminology is typically used in IS-IS?
>
> [Yingzhen]: changed to -flag.


> - Leaf Sid, how do we know whether it’s a 32-bit SID or a 20-bit label (not
> sure if we need to know)?
>

[Yingzhen]: Same as ospf-sr-mpls.yang, added length, and updated sid
description.


> - For global-blocks and local-blocks, a reference would help.
>
> [Yingzhen]: Done.


> - In grouping sid-sub-tlv, is the container sid-sub-tlv needed?
>
> [Yingzhen]: A container would help to identify the boundary of a TLV. In
an ISIS LSP, there are multiple TLVs and sub-tlvs.


> - In grouping srlb , can there be an overlap of the advertised local
> blocks?
> Need some enhanced description here iMO.  Same question for sr-capability
> and
> global blocks.
>
> [Yingzhen]: please see the above answers.

- In list global-block, why not add a key? I’m assuming the sid would be
> unique? Same comment for local-block.
>

[Yingzhen]:  SRGB is defined in RFC 9020, which is common for both OSPF and
ISIS. Here, we're defining protocol specific SRGB, and the key is defined
in the grouping in the ietf-segment-routing-common.yang. SRLB is defined in
RFC 9020, which applies to all protocols.

>
> - In grouping srms-preference, leaf preference, no need for the range
> 0..255
> since it is a uint8.
>
> [Yingzhen]: fixed.


> - Nit: a few instances of “This group …”, it should be “This grouping …”
>
> [Yingzhen]: fixed.


> - Leaf ‘af’, nit/suggestion: I would rename to address-family.
>
> [Yingzhen] : Done.


> - In grouping segment-routing-binding-tlv, leaf range, is that description
> accurate?
>
> [Yingzhen]: Thanks for catching this. I've updated the description.


> - Augment with neighbor-system-id, should the leaf node be mandatory?
>
> [Yingzhen]: added "mandatory true". Also did the same for ospf.

- Container selection-tie-breakers, can both protection types be enabled
> simultaneously?
>
> [Yingzhen]: yes, it's possible to enable both of them, one or none.


> There should be an appendix with a fairly complete config example and also
> an
> operational state example.
>
> [Yingzhen]: Operational state is not easy to do with the IGP database
since we don't have an implementation yet.


> Regards,
> Reshad.
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Yingzhen Qu]

[As WG Co-chair]

I concur Chris's statement as WG co-chair.

The second adoption call should focus on the changes made since the first
one, and whether these changes addressed/fixed the issues raised during the
first adoption call.

Thanks,
Yingzhen

On Mon, Jan 15, 2024 at 8:15 AM Les Ginsberg (ginsberg) 
wrote:

> I respect that individuals may have different opinions - but it is
> important to distinguish what is factual from what is not.
> Opinions based upon false information are clearly compromised.
>
> Please do heed Chris's (as WG chair) admonition to review the first WG
> adoption thread. That will reveal to you what the substantive objections
> were.
>
> https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
> https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0
>
>
> Please also do examine the delta between the previous version which was
> put up for WG adoption (V3) and the current version (V8) so you can see
> what has changed.
>
> https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03=draft-wang-lsr-stub-link-attributes-08=--html
>
> Some facts:
>
> The substantive objections raised during the first adoption call had
> nothing to do with use cases - they had to do with:
>
> a)The use of a prefix to identify a link between two nodes is a flawed
> concept. It is not robust enough to be used in cases of unnumbered or
> Pt-2-MP.
>
> b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the
> potential use cases and do so more robustly than the Stub-link proposal.
>
> The latest version of the draft makes no substantive changes to the stub
> link concept or its advertisement.
> The only substantive change in the latest version is a reorganization of
> the presentation of use cases.
> But lack of clarity in the use cases was not the basis on which first WG
> adoption call was rejected.
>
> In this thread (the second WG adoption call),  the authors have asserted
> that they have addressed the concerns raised in the previous adoption call.
> They have not. The concept and mechanism to identify a stub link has not
> changed.
>
> In this thread the authors continue to assert that RFC 9346/RFC 5392
> cannot address the use cases.
> This is FALSE.
> As has been pointed out repeatedly, the existing mechanisms provide a
> robust means to uniquely identify inter-AS links using endpoint identifiers
> - be they IPv4/IPv6 addresses or Link IDs.
> This addresses all cases - numbered and unnumbered.
> There is therefore no need for a new mechanism.
>
> No fact-based argument has been made to justify reconsideration of WG
> adoption.
>
> I hope when people post their opinions, that they consider the facts.
>
>   Les
>
> > -Original Message-
> > From: Lsr  On Behalf Of Christian Hopps
> > Sent: Wednesday, January 10, 2024 2:17 AM
> > To: Huzhibo 
> > Cc: Acee Lindem ; Yingzhen Qu
> > ; lsr@ietf.org
> > Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
> > (01/05/2024 - 01/19/2024)
> >
> > [As WG Co-Chair]
> >
> >   Hi Folks,
> >
> >   Before posting support reasons please read and considerl
> >   *all* the email in the archive covering the first failed
> >   adoption call.
> >
> > https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
> > https://www.mail-
> > archive.com/search?l=lsr%40ietf.org=stub+link=0=0
> >
> >   This adoption call should be considering if the changes
> >   made to the document since it failed to be adopted the
> >   first time, are sufficient to reverse the WGs previous
> >   decision.
> >
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-ospfv3-extended-lsa-yang

[Yingzhen Qu]

Hi John,

Thanks for the review. I've published version -25 to address your comments.
Details below inline.

Thanks,
Yingzhen

On Wed, Jan 10, 2024 at 11:07 AM John Scudder  wrote:

> Hi All,
>
> Thanks for the easy review, basically LGTM. I have just a few nits, below.
> I'll hold off on sending the doc for IETF LC for a short time, in case you
> want to fix these first. (It would be OK to send the current version, but
> IMO you might as well do another revision since GENART or other reviewers
> are likely to ask for some of these changes anyway.)
>
> --John
>
> ## NITS
>
> ### Section 3
>
> "The augmentations defined in the ietf-ospfv3-extended-lsa YANG model will
> provide"
>
> They *do* provide these things, so delete "will"?
>

[Yingzhen]: removed "will". Also changed "model" to "module" here.

>
> ### Section 4
>
>   /*
>* OSPFv3 Extend LSA Type Identities
>*/
>
> Shouldn't that be "Extended" not "Extend"?
>

[Yingzhen]: fixed.

>
> ### Section 5
>
> "For OSPFv3 Extended LSAs, the ability to disable OSPFv3 Extended LSA
> support result in a denial of service"
>
> Shouldn't that be "can result" or "results"? (Even with that patch the
> sentence is still a little off, it doesn't so much result in, as create an
> exposure to. But do as you will.)
>
> This one is grammatically and shade-of-meaning-wise not quite right too:
> "The exposure of the Link State Database (LSDB) will expose the detailed
> topology of the network and information beyond the scope of OSPF router."
> ("OSPF router" needs a definite article or to be pluralized, at minimum,
> but maybe a bit more of a rewrite, if you choose.)
>
> [Yingzhen]: I tried to rewrite both of them. Hopefully they read a bit
better now.

"This may be undesirable since both due to the fact that exposure may
> facilitate other attacks." Probably, delete "since both".
>
[Yingzhen]: done.

> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Yingzhen Qu]

Hi,

This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 19th, 2024.

Authors, please respond to the list indicating whether you are aware
of any IPR that applies to the draft.

*** Please note that this is the second WG adoption poll of the draft. The
first one was tried two years ago and you can see the discussions in the
archive:
[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org)


Thanks,

Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AF: RFC8666 updates RFC8665?

[Yingzhen Qu]

Hi Tom,

Sorry, but I don't understand your question. RFC8665 is for OSPFv2, and
RFC8666 is for OSPFv3. While in both cases, the TLV name is "Extended
Prefix Range TLV", one is for OSPFv2 extended prefix LSA, the other may be
advertised in:
E-Intra-Area-Prefix-LSA
E-Inter-Area-Prefix-LSA
E-AS-External-LSA
E-Type-7-LSA

I'm not sure whether this answers your question. More comments are welcome.

Thanks,
Yingzhen

On Sat, Dec 30, 2023 at 3:56 AM tom petch  wrote:

> Going through ospf-sr-yang-25 (and no, I do not want a new version for
> Christmas!) it seems to me that RFC8666 updates, RFC8665 even if the
> metadata does not mention it.
>
> RFC8665 says
> "  AF:  Address family for the prefix.  Currently, the only supported
>  value is 0 for IPv4 unicast.  The inclusion of address family
>  in this TLV allows for future extension.
> "
>
> while RFC8666 says
> "  AF:  Address family for the prefix.
>  AF:  0 - IPv4 unicast
>  AF:  1 - IPv6 unicast
> "
> Since 8665 says 'only supported value' then this is  no longer valid and
> has a knock-on efffect when it comes to ospf-sr-yang.
>
> If 8665 set up a registry (which I appreciate that the LSR WG has been
> resistant to doing in other cases) then adding a value to the registry
> would not be an update as per previous AD decisions but the phrase 'the
> only supported value is 0' can mislead until the reader understands 8666
> (and may still do so).
>
> Note that ospf-sr-yang has both RFC8665 and RFC8666 as Normative
> References so it is the implementor of the yang module that is at risk of
> misunderstanding.
>
> I have a number of comments on ospf-sr-yang relating to this which I will
> post separately.
>
> Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Rtgdir last call review of draft-ietf-isis-sr-yang-17

[Yingzhen Qu]

Hi Shuping,

Thanks for the review. Please see my response below inline.

Thanks,
Yingzhen

On Fri, Nov 24, 2023 at 12:37 AM Shuping Peng via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Shuping Peng
> Review result: Has Issues
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The
> Routing Directorate seeks to review all routing or routing-related drafts
> as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs.
> For more information about the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion
> or by
> updating the draft.
>
> Document: draft-ietf-isis-sr-yang
> Reviewer: Shuping Peng
> Review Date: 2023-11-24
> IETF LC End Date: 2023-11-30
> Intended Status: Standards
>
> Summary:
> I have some minor concerns about this document that I think should be
> resolved
> before publication.
>
> Major Issues:
>  "No major issues found."
>
> Minor Issues:
> 1. Page 3, when configure adjacency-sid, do we need to indicate the
> neighbor's
> systemid or IP in order to differentiate the different neighbors in the
> case of
> having multiple neighbors?
>
> augment /rt:routing/rt:control-plane-protocols
>   /rt:control-plane-protocol/isis:isis/isis:interfaces
>   /isis:interface:
> +--rw segment-routing
>+--rw adjacency-sid
>   +--rw adj-sids* [value]
>   |  +--rw value-type?   enumeration
>   |  +--rw value uint32
>   |  +--rw protected?boolean
>

[Yingzhen]:  thanks for catching this. We didn't consider LAN interfaces,
will fix this in the next version.

>
> 2. Page 4, since LFA, RLFA and TI-LFA are the three algorithm for computing
> backup paths, why they are not in sibling relationship?
>
>   augment /rt:routing/rt:control-plane-protocols
>   /rt:control-plane-protocol/isis:isis/isis:interfaces
>   /isis:interface/isis:fast-reroute:
> +--rw ti-lfa {ti-lfa}?
>+--rw enable?   boolean
>   augment /rt:routing/rt:control-plane-protocols
>   /rt:control-plane-protocol/isis:isis/isis:interfaces
>   /isis:interface/isis:fast-reroute/isis:lfa/isis:remote-lfa:
> +--rw use-segment-routing-path?   boolean {remote-lfa-sr}?
>
> [Yingzhen]: the assumption here is that LFA is preferred when
available.  Although in the ti-lfa draft, it says that LFA may not be
preferred over ti-lfa, however if there is LFA route available, the chance
of it also being post-convergence path is very high. I'll check with the
ti-lfa authors and some implementations.

3. Page 4, the keys of the global-block and local-block are not clear.
>
>   augment /rt:routing/rt:control-plane-protocols
>   /rt:control-plane-protocol/isis:isis/isis:database
>   /isis:levels/isis:lsp/isis:router-capabilities:
> +--ro sr-capability
> |  +--ro sr-capability
> |  |  +--ro sr-capability-bits*   identityref
> |  +--ro global-blocks
> | +--ro global-block* []
> |+--ro range-size?uint32
> |+--ro sid-sub-tlv
> |   +--ro sid?   uint32
> +--ro sr-algorithms
> |  +--ro sr-algorithm*   uint8
> +--ro local-blocks
> |  +--ro local-block* []
> | +--ro range-size?uint32
> | +--ro sid-sub-tlv
> |+--ro sid?   uint32
> +--ro srms-preference
>+--ro preference?   uint8
>

[Yingzhen]: these are read-only data, so key is not a must.

>
> 4. Currently there is no configuration node for the micro loop avoidance
> (
> https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-uloop/
> ),
> any thoughts or plan on it?
>
> [Yingzhen]: we can do an augmentation when the mentioned draft is ready to
progress.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IETF 118 LSR Minutes

[Yingzhen Qu]

Hi,

The meeting minutes have been updated to include the chat history:
minutes-118-lsr-202311060830-01.md
(ietf.org)
<https://datatracker.ietf.org/meeting/118/materials/minutes-118-lsr-202311060830-01>

Please review and let us know if any changes need to be made.

Thanks,
Yingzhen

On Sun, Nov 26, 2023 at 3:29 PM Les Ginsberg (ginsberg) 
wrote:

> FWIW –
>
>
>
> The new format for the chatlog is much less readable than previous.
>
>
>
> Here is the format from IETF 116:
>
>
>
> 
>
> Ketan Talaulikar
> 00:39:39
> There is a WG draft for per-algo adj-sid :
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/
>
> If we have large number of links, we are advertising many other
> attributes per link - so I am also missing the point of
> "compressing" only the adj-sid advertisement.
> * Weiqiang Cheng
> 00:41:58
> The similar solution for SRv6 is on the link:
> https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/
>
> …
>
> 
>
>
>
> Here is the format from IETF 118:
>
>
>
> 
>
> ", "time": "2023-11-06T09:06:17Z"}, {"author": "Christian Hopps", "text": "
>
> isn't this useful for OSPF too?
>
> ", "time": "2023-11-06T09:06:37Z"}, {"author": "Les Ginsberg", "text": "
>
> Could be - in which case you would have \"OSPF-Support\" module.
>
> ", "time": "2023-11-06T09:07:03Z"}, {"author": "Les Ginsberg", "text": "
>
> Different modules.
>
> …
>
> 
>
>
>
> (BTW, there seems to be no chat history in the minutes for IETF 117)
>
>
>
> If this is because of some meetecho change, please let them know the old
> format was better.
>
> If this is just a format change introduced by the way cut and paste was
> done  to the minutes, it would be nice to update it.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
> *From:* Lsr  *On Behalf Of * Yingzhen Qu
> *Sent:* Monday, November 20, 2023 6:18 AM
> *To:* lsr ; lsr-chairs 
> *Subject:* [Lsr] IETF 118 LSR Minutes
>
>
>
> Hi,
>
>
>
> The meeting minutes of IETF 118 LSR session is available: IETF-118 : lsr
> <https://datatracker.ietf.org/meeting/118/session/lsr>
>
>
>
> Please review and let us know if any corrections are needed.
>
>
>
> Thanks,
>
> Yingzhen
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

[Yingzhen Qu]

Speaking as WG member, I support the adoption of the draft.

Thanks,
Yingzhen

On Fri, Nov 17, 2023 at 8:02 AM Acee Lindem  wrote:

> LSR WG,
>
> This starts the Working Group adoption call for
> draft-chen-lsr-prefix-extended-flags-03. Please send your
> support or objection to this list before December 9th, 2023. The extra
> week is to allow for the US Thanksgiving holiday.
>
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 118 LSR Minutes

[Yingzhen Qu]

Hi,

The meeting minutes of IETF 118 LSR session is available: IETF-118 : lsr


Please review and let us know if any corrections are needed.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [yang-doctors] draft-ietf-isis-sr-yang and draft-ietf-ospf-sr-yang

[Yingzhen Qu]

Hi Reshad,

I've submitted an updated version of both the drafts, and tried to
align the two models. Please review and let me know what you think.

Thanks,
Yingzhen

On Tue, Nov 14, 2023 at 1:42 PM Acee Lindem  wrote:

>
>
> > On Nov 14, 2023, at 10:32 AM, Mahesh Jethanandani <
> mjethanand...@gmail.com> wrote:
> >
> > Hi Acee,
> >
> > Can the commonality extend to having a common grouping that is used by
> both the models?
>
> No - see my response to Reshad.
>
> Acee
>
>
> >
> > Cheers.
> >
> >> On Nov 14, 2023, at 8:10 AM, Acee Lindem  wrote:
> >>
> >> Thanks Reshad - are there any other notable discrepancies?
> >>
> >> Thanks,
> >> Acee
> >>
> >>> On Nov 14, 2023, at 9:55 AM, Reshad Rahman  40yahoo@dmarc.ietf.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> My suggestion is that authors of these 2 documents spend some time
> together to try to align the 2 documents. After that we can do YD review.
> >>>
> >>> Regards,
> >>> Reshad.
> >>>
> >>> On Wednesday, November 1, 2023, 10:58:56 AM EDT, Reshad Rahman <
> res...@yahoo.com> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> Background: those 2 documents have just been assigned YD review, I am
> reviewing OSPF and Jan is reviewing ISIS.
> >>>
> >>> Was an effort made to keep those 2 documents aligned/in-sync where
> possible/desirable? My expectation is that the SR specifics would be
> near-identical in the 2 documents. e.g. shouldn't the capabilities for the
> 2 protocols be very similar.
> >>> Here are some differences which don't seem justified:
> >>> - sr-algorithm in ISIS is a uint8 and in OSPF is an identityref
> >>> - range-size is a uint32 in ISIS and is a uint24 in OSPF
> >>>
> >>>
> >>> augment /rt:routing/rt:control-plane-protocols
> >>> /rt:control-plane-protocol/isis:isis/isis:database
> >>> /isis:levels/isis:lsp/isis:router-capabilities:
> >>> +--ro sr-capability
> >>> | +--ro sr-capability
> >>> | | +--ro sr-capability-bits* identityref
> >>> | +--ro global-blocks
> >>> | +--ro global-block* []
> >>> | +--ro range-size? uint32
> >>> | +--ro sid-sub-tlv
> >>> | +--ro sid? uint32
> >>> +--ro sr-algorithms
> >>> | +--ro sr-algorithm* uint8
> >>> +--ro local-blocks
> >>> | +--ro local-block* []
> >>> | +--ro range-size? uint32
> >>> | +--ro sid-sub-tlv
> >>> | +--ro sid? uint32
> >>> +--ro srms-preference
> >>> +--ro preference? uint8
> >>>
> >>> augment /rt:routing/rt:control-plane-protocols
> >>> /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
> >>> /ospf:interfaces/ospf:interface/ospf:database
> >>> /ospf:link-scope-lsa-type/ospf:link-scope-lsas
> >>> /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
> >>> /ospf:body/ospf:opaque/ospf:ri-opaque:
> >>> +--ro sr-algorithm-tlv
> >>> | +--ro sr-algorithm* identityref
> >>> +--ro sid-range-tlvs
> >>> | +--ro sid-range-tlv* []
> >>> | +--ro range-size? rt-types:uint24
> >>> | +--ro sid-sub-tlv
> >>> | +--ro sid? uint32
> >>> +--ro local-block-tlvs
> >>> | +--ro local-block-tlv* []
> >>> | +--ro range-size? rt-types:uint24
> >>> | +--ro sid-sub-tlv
> >>> | +--ro sid? uint32
> >>> +--ro srms-preference-tlv
> >>> +--ro preference? uint8
> >>>
> >>>
> >>>
> >>> Disclaimer: I don't follow LSR...
> >>>
> >>> Regards,
> >>> Reshad.
> >>> ___
> >>> yang-doctors mailing list
> >>> yang-doct...@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/yang-doctors
> >>
> >> ___
> >> yang-doctors mailing list
> >> yang-doct...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/yang-doctors
> >
> >
> > Mahesh Jethanandani
> > mjethanand...@gmail.com
> >
> >
> >
> >
> >
> >
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[Yingzhen Qu]

Hi,

About the name, here are some suggestions about the module name and prefix:

   - ietf-isis-feature-support.yang, isis-fs (YANG Module for IS-IS Feature
   Support)
   - ietf-isis-conformance-state.yang, isis-cs (YANG Module for IS-IS
   Protocol Conformance Statement)
   - ietf-isis-protocol-compliance.yang, isis-pc (YANG Module for IS-IS
   Protocol Compliance Report)
   - ietf-isis-functionality-conformance.yang, isis-fc (YANG Module for
   IS-IS Functionality Conformance)
   - ietf-isis-function-support.yang isis-fs (YANG Module for IS-IS
   Functional Support)

The authors are open to suggestions.

Thanks,
Yingzhen


On Fri, Nov 17, 2023 at 1:37 PM Acee Lindem  wrote:

> Speaking as WG member:
>
> Ok - I can see that I’m in the minority here in thinking this should be at
> a less granular level than specific TLVs. We can see where the more
> granular definition takes us and I’ll help with the OSPFv2/OSPFv3 models.
>
> Hopefully, the enthusiasm for implementation will match our IGP protocol
> support modeling efforts.
>
> Thanks,
> Acee
>
> > On Nov 17, 2023, at 4:14 AM, bruno.decra...@orange.com wrote:
> >
> >Orange Restricted
> > From: Lsr  On Behalf Of Acee Lindem
> > Sent: Thursday, November 16, 2023 11:33 PM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Loa Andersson ; lsr@ietf.org
> > Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
> >  Speaking as a WG contributor:
> >  Hi Les,
> >  I think a simpler name is better - perhaps
> ietf-isis-feature-support.yang with YANG prefix isis-fs would be better.
> Which brings me to my next and more important point…
> >  Like carbon neutrality, everyone at the LSR WG meeting who had an
> opinion thought such a YANG model would be operationally useful. However, I
> think the level of granularity is key.
> > [Bruno] +1
> > I agree that the level of granularity is key.
> > I’d rather call for a significant granularity (but I’d welcome any
> pushback).
> > Personally, I don’t see why per TLV granularity would not be ok: it’s ok
> to implement which is more work, so just listing the supported TLV and
> sub-TLV should be doable. In any case, operators, pre-sales and support
> engineers will likely need this information some day. So let’s just fill it
> once for all and have it available for all persons.
> > I’d would even call for more granularity. E.g. for RFC 5130, for “32-bit
> Administrative Tag Sub-TLV 1”, “On receipt, an implementation MAY consider
> only one encoded tag, in which case, the first encoded tag MUST be
> considered and any additional tags ignored. »
> > To me, if the WG bothered making such granularity at the
> feature/TLV/implementation level, we need such granularity at the reporting
> level. And that’s not theoretical, I had to check that for a project a
> month ago. At best, it’s indicated in the vendors documentation, so the
> data is there, so let’s make it friendly to digest. At worst, we need to
> involve expensive people .
> > If we want less granularity, let’s do less granularity in spec
> (everything is MUST)
> >  https://datatracker.ietf.org/doc/html/rfc5130#section-3.1
> >  Thanks,
> > --Bruno
> >   I believe that having a separate data node for each TLV/sub-TLV as was
> done in the example ietf-isis-pics-sr-mpls.yang module is way too granular
> to be useful. Rather, the YANG reporting should be done at the feature
> level. Also, does a distinction need to be made as to whether the IS-IS
> node supports the feature or both supports it and has it enabled (as would
> be the case for non-backward compatible features)?
> >  Thanks,
> > Acee
> >  On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
> >  Loa -
> >
> > I agree with you that simply "IS-IS Support" may not be the best choice.
> > Although, the meeting minutes have not yet been posted, as I recall my
> response to Tony Li's suggestion of "IS-IS Support" was "Yes - something
> like that."
> >
> > The draft authors have not yet discussed this - but we will and share
> the proposed new name.
> > Other suggestions welcomed.
> >
> >   Les
> >
> > -Original Message-
> > From: Lsr  On Behalf Of Loa Andersson
> > Sent: Thursday, November 16, 2023 2:06 AM
> > To: lsr@ietf.org
> > Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
> >
> > Working Group,
> >
> > During the presentation of draft-qgp-lsr-isis-pics-yang there was a
> > rather strong opposition in the chat against using the ISO-term "PICS"
> > in an IETF document.
> >
> > I think the term "Support" was suggested (excuse me if I missed
> > something), but I'm not that impressed, and would rather like to see
> > something like - "Supported Protocol Aspects".
> >
> > /Loa
> > --
> > Loa Anderssonemail: l...@pi.nu
> > Senior MPLS Expert  loa.pi...@gmail.com
> > Bronze Dragon Consulting phone: +46 739 81 21 64
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> 

[Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Yingzhen Qu]

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv:
draft-pkaneria-lsr-multi-tlv-04
- Multi-part TLVs in IS-IS (ietf.org)


Please send your support or objection to the list before December 9th,
2023. An extra week is allowed for the US Thanksgiving holiday.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IPR Poll for draft-pkaneria-lsr-multi-tlv

[Yingzhen Qu]

Hi,

This is an IPR call for draft-pkaneria-lsr-multi-tlv
(draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)
)

The authors and contributors please respond to this IPR call.

Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.


If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. The response needs to be sent to the LSR WG mailing
list. The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[Yingzhen Qu]

Speaking as a co-author of the draft, I'm open to name suggestions.

As for granularity, I'd say this really varies per RFC/feature. We want to
make it useful for operators but not too tedious to implement.
Realistically, we won't be able to have modules for all existing RFCs, so
it's more about new RFCs. The WG should decide the level of feature
granularity as part of the document when it is to be published.

Thanks,
Yingzhen

On Thu, Nov 16, 2023 at 2:44 PM Tony Li  wrote:

> Hi Acee,
>
> I concur that a simpler name is better and am fine with what you propose.
> Or pretty much anything other than ‘PICS’.  :-)
>
> I disagree that feature level granularity is sufficient. Example: suppose
> an implementation supports traffic engineering. Is that sufficient for an
> operator? Is that enough to ensure interoperability? I’m not convinced.
> Does the node support administrative groups? What about extended
> administrative groups? Maybe we don’t need to be at the individual TLV
> level for every feature, but it sure would be nice to call out each and
> every option that an implementation may support.
>
> Yes, I realize that it’s a giant hassle, but if we ever want to get to the
> world when network management is fully automated, we will need to make
> everything transparent.
>
> Regards,
> Tony
>
>
> On Nov 16, 2023, at 2:32 PM, Acee Lindem  wrote:
>
> Speaking as a WG contributor:
>
> Hi Les,
>
> I think a simpler name is better - perhaps ietf-isis-feature-support.yang
> with YANG prefix isis-fs would be better.  Which brings me to my next and
> more important point…
>
> Like carbon neutrality, everyone at the LSR WG meeting who had an opinion
> thought such a YANG model would be operationally useful. However, I think
> the level of granularity is key. I believe that having a separate data node
> for each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang
> module is way too granular to be useful. Rather, the YANG reporting
> should be done at the feature level. Also, does a distinction need to be
> made as to whether the IS-IS node supports the feature or both supports
> it and has it enabled (as would be the case for non-backward compatible
> features)?
>
> Thanks,
> Acee
>
> On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Loa -
>
> I agree with you that simply "IS-IS Support" may not be the best choice.
> Although, the meeting minutes have not yet been posted, as I recall my
> response to Tony Li's suggestion of "IS-IS Support" was "Yes - something
> like that."
>
> The draft authors have not yet discussed this - but we will and share the
> proposed new name.
> Other suggestions welcomed.
>
>   Les
>
> -Original Message-
> From: Lsr  On Behalf Of Loa Andersson
> Sent: Thursday, November 16, 2023 2:06 AM
> To: lsr@ietf.org
> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
>
> Working Group,
>
> During the presentation of draft-qgp-lsr-isis-pics-yang there was a
> rather strong opposition in the chat against using the ISO-term "PICS"
> in an IETF document.
>
> I think the term "Support" was suggested (excuse me if I missed
> something), but I'm not that impressed, and would rather like to see
> something like - "Supported Protocol Aspects".
>
> /Loa
> --
> Loa Anderssonemail: l...@pi.nu
> Senior MPLS Expert  loa.pi...@gmail.com
> Bronze Dragon Consulting phone: +46 739 81 21 64
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-isis-sr-yang and draft-ietf-ospf-sr-yang

[Yingzhen Qu]

Hi Reshad,

Thanks for the review.

I'll look into this issue and get back to you soon. We should
definitely try to keep these two models consistent.

Thanks,
Yingzhen



On Tue, Nov 14, 2023 at 6:55 AM Reshad Rahman  wrote:

> Hi,
>
> My suggestion is that authors of these 2 documents spend some time
> together to try to align the 2 documents. After that we can do YD review.
>
> Regards,
> Reshad.
>
> On Wednesday, November 1, 2023, 10:58:56 AM EDT, Reshad Rahman <
> res...@yahoo.com> wrote:
>
>
> Hi,
>
> Background: those 2 documents have just been assigned YD review, I am
> reviewing OSPF and Jan is reviewing ISIS.
>
> Was an effort made to keep those 2 documents aligned/in-sync where
> possible/desirable? My expectation is that the SR specifics would be
> near-identical in the 2 documents. e.g. shouldn't the capabilities for the
> 2 protocols be very similar.
> Here are some differences which don't seem justified:
> - sr-algorithm in ISIS is a uint8 and in OSPF is an identityref
> - range-size is a uint32 in ISIS and is a uint24 in OSPF
>
>
>   augment /rt:routing/rt:control-plane-protocols
>   /rt:control-plane-protocol/isis:isis/isis:database
>   /isis:levels/isis:lsp/isis:router-capabilities:
> +--ro sr-capability
> |  +--ro sr-capability
> |  |  +--ro sr-capability-bits*   identityref
> |  +--ro global-blocks
> | +--ro global-block* []
> |+--ro range-size?uint32
> |+--ro sid-sub-tlv
> |   +--ro sid?   uint32
> +--ro sr-algorithms
> |  +--ro sr-algorithm*   uint8
> +--ro local-blocks
> |  +--ro local-block* []
> | +--ro range-size?uint32
> | +--ro sid-sub-tlv
> |+--ro sid?   uint32
> +--ro srms-preference
>+--ro preference?   uint8
>
>
> augment /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
> /ospf:interfaces/ospf:interface/ospf:database
> /ospf:link-scope-lsa-type/ospf:link-scope-lsas
> /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
> /ospf:body/ospf:opaque/ospf:ri-opaque:
>   +--ro sr-algorithm-tlv
>   |  +--ro sr-algorithm*   identityref
>   +--ro sid-range-tlvs
>   |  +--ro sid-range-tlv* []
>   | +--ro range-size?rt-types:uint24
>   | +--ro sid-sub-tlv
>   |+--ro sid?   uint32
>   +--ro local-block-tlvs
>   |  +--ro local-block-tlv* []
>   | +--ro range-size?rt-types:uint24
>   | +--ro sid-sub-tlv
>   |+--ro sid?   uint32
>   +--ro srms-preference-tlv
>  +--ro preference?   uint8
>
>
>
> Disclaimer: I don't follow LSR...
>
> Regards,
> Reshad.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Slides Please Re: LSR agenda for IETF 118

[Yingzhen Qu]

Reminder!

Presenters:
Please upload your slides or email lsr-cha...@ietf.org no later than
Sunday, November 5th.

Thanks,
Yingzhen

On Thu, Oct 26, 2023 at 11:08 AM Yingzhen Qu 
wrote:

> Hi,
>
> The draft agenda for the upcoming LSR meeting has been uploaded:
> IETF-118 : lsr <https://datatracker.ietf.org/meeting/118/session/lsr>
>
> Please review the agenda and let us know if any changes are desired, or if
> any requests were missed.
>
> Presenters:
> Please upload your slides or email lsr-cha...@ietf.org no later than
> Sunday, November 5th.
>
> Thanks,
> Yingzhen
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Agenda Re: IETF 118 AIDC Side Meeting

[Yingzhen Qu]

Hi all,

The agenda for the AIDC side meeting is now available at: AIDC-IETF118/AIDC
Side Meeting Agenda.md at main · Yingzhen-ietf/AIDC-IETF118 (github.com)
<https://github.com/Yingzhen-ietf/AIDC-IETF118/blob/main/AIDC%20Side%20Meeting%20Agenda.md>

We have presentations from both industry and academia, covering topics from
fundamental requirements to congestion control in Data Center networks for
AI.

For remote attendees, please use the webex link:
https://ietf.webex.com/meet/ietfsidemeeting2

Meeting Time: Tuesday, 7 Nov, 17:00 - 19:00 *(Central European Time -
Prague)*
Location: Palmovka 1/2
Meeting Materials: Yingzhen-ietf/AIDC-IETF118: Meeting materials for the
AIDC side meeting at IETF 118. (github.com)
<https://github.com/Yingzhen-ietf/AIDC-IETF118>

If you have any questions, please let us know.

Thanks,
Jeff and Yingzhen

On Sun, Oct 22, 2023 at 10:37 PM Yingzhen Qu 
wrote:

> Hi,
>
> (RTGWG Chair hats off)
>
> Following our productive discussions at IETF 117's AIDC side meeting, we
> are excited to announce another meeting during IETF 118 in Prague. This
> gathering will serve as a continuation of the ongoing dialogue.
>
> The primary focus of this meeting is to delve into the introduction of new
> technologies within large-scale data centers, especially in the context of
> AI model training and related applications. While we'll give special
> attention to this theme, we welcome discussions on a broader spectrum of
> topics.
> Our objectives for this meeting include:
> • Gaining insights into real-world use cases
> • Identifying emerging networking challenges and requirements
> • Exploring innovative research and standardization opportunities
>
> We look forward to engaging in these discussions and collectively
> advancing our understanding of the evolving landscape of data center
> networking for AI. Your active participation will be highly valuable as we
> work towards addressing these challenges and fostering innovation in this
> domain.
>
> The detailed agenda, slides and link for remote attendees will be uploaded
> to the GitHub repository soon.
>
> Meeting Time: Tuesday, 7 Nov, 17:00 - 19:00
> Location: Palmovka 1/2
> Meeting Materials: Yingzhen-ietf/AIDC-IETF118: Meeting materials for the
> AIDC side meeting at IETF 118. (github.com)
> <https://github.com/Yingzhen-ietf/AIDC-IETF118>
>
> If you have any questions or comments, please contact us.
>
> Thanks,
> Jeff and Yingzhen
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR agenda for IETF 118

[Yingzhen Qu]

Hi,

The draft agenda for the upcoming LSR meeting has been uploaded:
IETF-118 : lsr 

Please review the agenda and let us know if any changes are desired, or if
any requests were missed.

Presenters:
Please upload your slides or email lsr-cha...@ietf.org no later than
Sunday, November 5th.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 118 LSR Slot Requests

[Yingzhen Qu]

Hi,

The draft agenda for IETF 118 has been posted:
IETF 118 Meeting Agenda 

The LSR session is scheduled on Monday Session I 09:30-11:30, Nov 6th, 2023.

Please send slot requests to lsr-cha...@ietf.org before the end of the day
Wednesday Oct 25.  Please include draft name and link, presenter, desired
slot length including Q

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang

[Yingzhen Qu]

As a co-author, I support the publication of this draft. I'm not aware of
any IPR.

Thanks,
Yingzhen

On Fri, Aug 18, 2023 at 5:27 PM Christian Hopps  wrote:

>
> This begins a 2 week WG Last Call, ending Sep 1, 2023, for:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>
> Authors,
>
> Please indicate to the list, your knowledge of any IPR related to this
> work.
>
> Thanks,
> Chris.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang

[Yingzhen Qu]

As a co-author, I'm not aware of any IPR related to this work, and I
support the publication of this draft.

Thanks,
Yingzhen

On Fri, Aug 18, 2023 at 5:27 PM Christian Hopps  wrote:

>
> This begins a 2 week WG Last Call, ending Sep 1, 2023, for:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>
> Authors,
>
> Please indicate to the list, your knowledge of any IPR related to this
> work.
>
> Thanks,
> Chris.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR meeting minutes

[Yingzhen Qu]

Hi,

The LSR meeting minutes have been uploaded: IETF-117 : lsr


Thanks to David Lamparter for helping with the minutes.

If you made a comment at the mic, please review the minutes and let me know
if there is any correction needed.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Slides Please Re: Draft LSR agenda uploaded

[Yingzhen Qu]

Hi presenters,

LSR will be the first session on Monday morning, please send your slides to
lsr-cha...@ietf.org 24 hours before the meeting starts.

Thanks,
Yingzhen

On Wed, Jul 12, 2023 at 11:21 AM Yingzhen Qu 
wrote:

> Hi all,
>
> The draft LSR agenda has been posted:
> https://datatracker.ietf.org/meeting/117/materials/agenda-117-lsr-03
>
> Please let us know if you have any questions.
>
> Thanks,
> Yingzhen
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-20.txt

[Yingzhen Qu]

Hi Renato,

Thank you for the review and comments. We really need this.

About the "length", I agree with you and Acee that it's not necessary for
some fixed length TLV. However, from coding and modeling perspective, I
would think it's better to stay consistent. If we only need length for
unknown-tlvs and not the rest, that's fine. But that's not the case, and we
have to figure out where it's needed. Also it is a read-only leaf. Thoughts?

Thanks,
Yingzhen

On Fri, Jul 14, 2023 at 8:16 AM Acee Lindem  wrote:

> Hi Renato,
>
> > On Jul 14, 2023, at 10:58, Renato Westphal 
> wrote:
> >
> > Hi Acee,
> >
> > Thanks for accepting my suggestions.
> >
> > Em qui., 13 de jul. de 2023 às 18:23, Acee Lindem
> >  escreveu:
> >>> Lastly, this might just be a small nitpick of mine, but I don't think
> >>> having a "length" leaf for all TLVs and Sub-TLVs adds much value. In
> >>> my opinion, it's only relevant for unknown TLVs that couldn't be
> >>> decoded; otherwise, it just adds unnecessary noise. If we take a look
> >>> at the IS-IS model, for instance, we can see that it doesn't have a
> >>> "length" leaf for the LSP TLVs and Sub-TLVs.
> >>
> >> I’ve removed the three "length" leaves that were fixed length. I left
> the ones that were variable due to contained sub-TLVS.
> >> Are you saying that these TLVs would be malformed if the length weren’t
> correct?
> >
> > No. I just can't see how the TLV/Sub-TLV length is a useful piece of
> > information.
> >
> > For the "unknown-tlv" and "unknown-sub-tlv" lists, I think the
> > "length" serves a purpose, as the management application might want to
> > parse the TLV raw data. For known TLVs and Sub-TLVs, I don't see much
> > point. I understand this might be nitpicking from my side, so feel
> > free to ignore this suggestion if you prefer.
>
> Let me talk to others. These higher level containers COULD include unknown
> Sub-TLVs so I was thinking it would be better to include the containing TLV
> length as well. I agree the length serves no useful purpose for the fixed
> length Sub-TLVs.
>
> Note that it seems NETMOD is going the way for “config=false” information
> as draft is being proposed for unknown bits -
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/
> However, I’m not a fan of this draft.
>
>
>
> >
> >>> By the way, I've generated some sample data using the updated module.
> >>> Feel free to check it out here:
> >>> http://westphal.com.br/holo/ospfv3-topo/
> >>
> >> What testing infra-structure are you using?
> >
> > It's a tool called netgen I wrote several years ago, mostly for
> > personal use. It uses Linux namespaces and veth interfaces to create a
> > virtual topology. Today there are similar tools that are better
> > documented and maintained, but I'm too lazy to migrate to those tools
> > so I keep using netgen :)
>
> Okay, it looked “similar” functionally to the FRR munet stuff but with a
> different schema, etc. I was just curious.
>
> Thanks,
> Acee
>
>
> >
> > Best Regards,
> > --
> > Renato Westphal
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Draft LSR agenda uploaded

[Yingzhen Qu]

Hi all,

The draft LSR agenda has been posted:
https://datatracker.ietf.org/meeting/117/materials/agenda-117-lsr-03

Please let us know if you have any questions.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 117 LSR Slot Requests

[Yingzhen Qu]

Hi,

The draft agenda for IETF 117 has been posted:
https://datatracker.ietf.org/meeting/117/agenda

The LSR session is scheduled on Wednesday Session II 13:00-15:00, July
26th, 2023.

Please send slot requests to lsr-cha...@ietf.org before the end of the day
Monday July 10.  Please include draft names(s), presenter, desired slot
length including Q

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Yangdoctors last call review of draft-ietf-lsr-ospfv3-extended-lsa-yang-14

[Yingzhen Qu]

Hi Mahesh,

We just uploaded version -17 and added a configuration example. Please let
us know if you have any other comments.

Thanks,
Yingzhen

On Mon, Jun 26, 2023 at 1:44 PM Acee Lindem  wrote:

> Hi Mahesh,
>
> Thanks for the review - a lot of good comments. See inline and -16
> version.
>
> > On Jun 15, 2023, at 5:18 PM, Mahesh Jethanandani via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Reviewer: Mahesh Jethanandani
> > Review result: On the Right Track
> >
> > Document reviewed: draft-ietf-lsr-ospfv3-extended-lsa-yang
> >
> > Status: On the right track
> >
> > I have marked it as On the Right Track, because of some of the points
> discussed
> > below.
> >
> > Summary:
> >
> > This document defines a YANG data model augmenting the IETF OSPF YANG
> model to
> > provide support for OSPFv3 Link State Advertisement (LSA) Extensibility
> as
> > defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based
> LSAs for
> > the base LSA types defined in RFC 5340.
> >
> > Nits
> >
> > Please add a section on Instructions to RFC editors stating what they
> should do
> > with references such as RFC .
> >
> > It would be nice to have some consistency between having description and
> > reference statements start on a new line or on the same line as the
> statement.
> > Right now, they are all over the place.
> >
> > Some of the descriptions are very cryptic. E.g.
> >
> >  leaf forwarding-address {
> >type inet:ipv4-address;
> >description
> >  "Forwarding address";
>
> I updated the ones that were brief and cryptic. Note that you almost have
> to have knowledge of RFC 5340 and RFC 8362 to understand the encodings.
>
>
> >
> > s/Description/description in the YANG model. Actually, I was surprised
> that
> > pyang did not complain, but yanglint did.
> >
> > libyang err : Invalid character sequence "Description", expected a
> keyword.
> > (Line number 318.) libyang err : Parsing module
> "ietf-ospfv3-extended-lsa"
> > failed. YANGLINT[E]: Parsing schema module
> > "ietf-ospfv3-extended-...@2023-06-08.yang" failed.
>
>
> Fixed - I’m surprised pyang didn’t complain as well.
>
>
> >
> > s/Addrss/Address/
>
> Fixed.
>
>
> >
> > s/E-/Extended / in all descriptions.
>
> When referring to the actual LSAs, it is should be “E-“. For example,
> E-Router-LSA. In other cases, it is spelled out. See RFC 8362.
>
>
> >
> > Comments:
> >
> > The grouping such as ospfv3-e-lsa-as, ospfv3-e-lsa-area,
> ipv6-fwd-addr-sub-tlv
> > etc. are used in one place only. Is there a reason why this has not been
> pulled
> > inline where it is used? Did not check for all groupings, but if there
> is only
> > one use of them, ideally they should be inlined.
>
> I consolidated these for the link, area, and AS scoped LSDBs. I left the
> fowarding-address Sub-TLV in its own grouping consistent with the other
> Sub-TLVs.
>
>
>
> >
> > No need to repeat parent name in the child. Just length will do in the
> > following. See Section 4.3.1 of RFC 8407. E.g.
> >
> >container route-tag-sub-tlv {
> >  description
> >"Route Tag Sub-TLV";
> >  leaf route-tag-sub-tlv-length {
>
> Fixed.
>
>
> >
> > Why a double -- in  container unknown--tlv {?
>
> Fixed.
>
> >
> > A pyang compilation of the model with —ietf and —lint option was clean.
> >
> > There are no examples of configuration instance data in the draft. It
> would be
> > helpful not only to validate the model, but also help folks who want to
> use the
> > model.
>
> There are only two booleans that are config=true. We can look at this
> though.
>
> >
> > A idnits run of the draft reveals a few issues. Please address them.
> >
> >   Checking boilerplate required by RFC 5378 and the IETF Trust (see
> >  https://trustee.ietf.org/license-info):
> >  -
> >
> > No issues found here.
> >
> >  Checking nits according to
> >  https://www.ietf.org/id-info/1id-guidelines.txt:
> >  -
> >
> > No issues found here.
> >
> >  Checking nits according to https://www.ietf.org/id-info/checklist :
> >  -
> >
> > No issues found here.
> >
> >  Miscellaneous warnings:
> >  -
> >
> >  == The copyright year in the IETF Trust and authors Copyright Line
> > does not match the current year
> >
> >  == Line 1266 has weird spacing: '... allows  a rou...'
> >
> >  -- The document date (October 17, 2019) is 1337 days in the past.
> > Is this intentional?
> >
> >  Checking references for intended status: Proposed Standard
> >  -
> >
> > (See RFCs 3967 and 4897 for information about using normative
> > references to lower-maturity documents in RFCs)
> >
> >  == Outdated reference: draft-ietf-bfd-yang has been 

[Lsr] LSR Minutes Uploaded

[Yingzhen Qu]

Hi,

The meeting minutes of the LSR session at IETF 116 have been uploaded:
https://datatracker.ietf.org/meeting/116/materials/minutes-116-lsr-202303270030-00

If you said something at the mic during the meeting please check and let me
know if any corrections are needed.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "IGP Flexible Algorithms Reverse Affinity Constraint" - draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01

[Yingzhen Qu]

I've read the draft and support this adoption.

Thanks,
Yingzhen

On Fri, Mar 10, 2023 at 5:09 AM Acee Lindem  wrote:

>
> The begins the LSR WG adoption call for "IGP Flexible Algorithms Reverse
> Affinity Constraint" - draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01.
> Please express your support or objection on this list prior to Saturday,
> March 25th, 2023.
>
> We now have RFC 9350 (IGP Flex Also) and have deployed implementations as
> well as several other LSR WG documents with IGP Flex Algorithm extensions.
> It makes sense to adoption this simple extension as well that has been at a
> previous IETF.
>
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] draft LSR agenda posted

[Yingzhen Qu]

Hi,

The draft LSR agenda for IETF 116 has been posted: Agenda IETF116: lsr


Please let us know if there are any changes required.

Presenters, please send your slides to lsr-cha...@ietf.org at least 24
hours before the meeting.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Yingzhen Qu]

Noted. will add it to the agenda.

Thanks,
Yingzhen

On Mon, Mar 13, 2023 at 1:06 PM Acee Lindem  wrote:

> Hi Yinzhen,
>
> I would like 5 minutes to present an alternative solution. The
> presentation should immediately follow this presentation as the
> hypothetical problem will have already have been presented.
>
> There isn’t a draft yet as I’m not sure this problem really needs to be
> solved.
>
> Thanks,
> Acee
>
> > On Mar 7, 2023, at 1:34 PM, Acee Lindem  wrote:
> >
> > Hi Liyan,
> >
> > This is very unlikely to happen as flooding between the routers
> commences as soon as they reach Exchange state. I’m wondering if you’ve
> actually seen this situation or it is hypothetical.
> >
> > In any case, I have a better solution which wouldn’t add the delay for
> the next hello packet without the SA flag to be received before advertising
> the link. I’m busy with some other things right now and want to think about
> it more.
> >
> > For now, we will add your presentation to the list for IETF 116.
> >
> > Thanks,
> > Acee
> >
> >
> >
> >> On Mar 7, 2023, at 3:54 AM, Liyan Gong 
> wrote:
> >>
> >>
> >> Hi Les and Acee,
> >>
> >> Let me explain it further through the following diagram.
> >>
> >> 1) The neighbor relationship between Router A and Router B is stable.
> The route 10.1.1.1/32 is reachable.
> >> 2）Router A unplanned restarts and the loopback address has been
> deleted.The process of the neighbor establish is as follows.
> >> 3）The temporary blackhole occurs during the time range stated in the
> right brace.
> >>
> >> There are two key points:
> >> 1)Neighbor router reached the full state earlier.
> >> 2)Neighbor router received the reoriginated lsas late.
> >>
> >> So,this purpose of the draft is to delay the point 1).
> >>
> >> Hope this helps,thank you.
> >>
> >> <1.png>
> >> 
> >> Best Regards,
> >> Liyan
> >>
> >>
> >> 邮件原文
> >> 发件人："Mengxiao.Chen" 
> >> 收件人："Les Ginsberg (ginsberg)" 
> >> ,AceeLindem
> ,Liyan Gong  
> >> 抄 送: lsr  ,Weiqiang Cheng  
> >> ,linchangwang
> 
> >> 发送时间：2023-03-07 15:19:59
> >> 主题：Re: [Lsr] New Version Notification
> fordraft-cheng-ospf-adjacency-suppress-00.txt
> >>
> >> Hi Les,
> >>
> >> Thank you for your comments.
> >> OSPF does include the LSDB sync requirement. But OSPF state machine
> does not guarantee the two routers attain FULL state at the same time.
> >>
> >> R1(restart)--R2--R3
> >>
> >> R1 LSDB: R1's new router-LSA, seq 8001
> >> R2 LSDB: R1's old router-LSA, seq 8500
> >>
> >> When R1 restarts from an unplanned outage, R1 will reinitialize its LSA
> sequence number. But R2 has the previous copies of R1's LSA, which has
> larger sequence number.
> >> R2 thinks its local LSAs are "newer". So, R2 will attain FULL state,
> without requesting R1 to update.
> >> This may cause temporary blackholes to occur until R1 regenerates and
> floods its own LSAs with higher sequence numbers.
> >>
> >> Thanks,
> >> Mengxiao
> >>
> >> -Original Message-
> >> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> >> Sent: Tuesday, March 7, 2023 1:29 AM
> >> To: Acee Lindem ; Liyan Gong <
> gongli...@chinamobile.com>
> >> Cc: lsr 
> >> Subject: Re: [Lsr] New Version Notification for
> draft-cheng-ospf-adjacency-suppress-00.txt
> >>
> >> +1 to what Acee has said.
> >>
> >> As historical context, the SA bit was defined in IS-IS precisely
> because IS-IS adjacency state machine does NOT include LSPDB sync as a
> requirement before the adjacency is usable (unlike OSPF).
> >> OSPF does not need SA bit.
> >>
> >>   Les
> >>
> >>> -Original Message-
> >>> From: Lsr  On Behalf Of Acee Lindem
> >>> Sent: Monday, March 6, 2023 8:01 AM
> >>> To: Liyan Gong 
> >>> Cc: lsr 
> >>> Subject: Re: [Lsr] New Version Notification for
> draft-cheng-ospf-adjacency-
> >>> suppress-00.txt
> >>>
> >>> Hi Liyan,
> >>>
> >>> I should replied to this Email rather than your request for an IETF
> 116 slot.
> >>> Please reply to this one.
> >>>
> >>> I’m sorry but I don’t get this draft from a quick read. An OSPF router
> would
> >>> not advertise an adjacency until the router is in FULL state. An OSPF
> router
> >>> will not attain FULL state until database synchronization is complete.
> >>> The following statement from you use case is incorrect:
> >>>
> >>>So, without requesting the starting router to update its LSAs, the
> >>>neighbors of the starting router may transition to "Full" state and
> >>>route the traffic through the starting router.
> >>>
> >>> Why do you think you need this extension?
> >>>
> >>>
> >>> Thanks,
> >>> Acee
> >>>
> >>>
>  On Mar 6, 2023, at 9:10 AM, Liyan Gong 
> >>> wrote:
> 
>  Dear All,
>  We have posted a new draft
> https://datatracker.ietf.org/doc/draft-cheng-
> >>> ospf-adjacency-suppress/.
>  This draft describes the extension of OSPF LLS to signal adjacency
> >>> suppression which is functionally similar to the SA bit of Restart TLV
> in IS-IS.
>  The purpose is to avoid the temporary blackhole 

Re: [Lsr] Slot request for LSR IETF 116

[Yingzhen Qu]

Hi Zhibo,

I've received your request. Please pay attention to the agenda when posted.

Thanks,
Yingzhen

On Wed, Mar 8, 2023 at 6:02 PM Huzhibo  wrote:

> Hi Acee & Yingzhen：
>
>   I would like to request a TimeSlot,We will update a new version:
> Draft：draft-hu-lsr-igp-path-mtu Presenter: Zhibo Hu
>
> Duration: 10 mins
>
> Thanks
>
>
>
> Zhibo
>
>
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Yingzhen Qu
> *Sent:* Wednesday, March 1, 2023 2:37 AM
> *To:* lsr-chairs ; lsr 
> *Subject:* [Lsr] Slot request for LSR IETF 116
>
>
>
> Dear LSR WG:
>
>
>
> The preliminary agenda for IETF 116 has been released, and the LSR session
> is scheduled on Monday Session I (9:30-11:30).
>
>
>
> Please send your presentation request to LSR WG chairs (
> lsr-cha...@ietf.org) before the end of Monday March 13 with the following
> info:
>
> · draft to be presented
>
> · presenter name
>
> · estimated time needed, including Q
>
> If there is any question, please let me know.
>
>
>
> Thanks,
>
> Yingzhen
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Slot request for LSR IETF 116

[Yingzhen Qu]

Dear LSR WG:

The preliminary agenda for IETF 116 has been released, and the LSR session
is scheduled on Monday Session I (9:30-11:30).

Please send your presentation request to LSR WG chairs (lsr-cha...@ietf.org)
before the end of Monday March 13 with the following info:

   - draft to be presented
   - presenter name
   - estimated time needed, including Q

If there is any question, please let me know.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 115 LSR meeting minutes uploaded

[Yingzhen Qu]

Hi,

The meeting minutes of IETF 115 LSR session have been uploaded:
IETF-115 : lsr 

Please review and let us know if you have any comments.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Draft LSR agenda uploaded

[Yingzhen Qu]

Hi presenters,

Reminder, please make sure to email your slides to lsr-cha...@ietf.org 24 hours 
before your presentation. 

Thanks,
Yingzhen

> On Oct 28, 2022, at 1:03 AM, Yingzhen Qu  wrote:
> 
> Hi,
> 
> The draft agenda has been uploaded: 
> https://datatracker.ietf.org/meeting/115/session/lsr 
> <https://datatracker.ietf.org/meeting/115/session/lsr>
> 
> If you have any questions or we missed your request, please email 
> lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>.
> 
> If you’re on the agenda, please email your slides to lsr-cha...@ietf.org 
> <mailto:lsr-cha...@ietf.org> at least 24 hours before the meeting session.
> 
> Thanks,
> Yingzhen

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Draft LSR agenda uploaded

[Yingzhen Qu]

Hi,

The draft agenda has been uploaded:
https://datatracker.ietf.org/meeting/115/session/lsr

If you have any questions or we missed your request, please email
lsr-cha...@ietf.org.

If you’re on the agenda, please email your slides to lsr-cha...@ietf.org at
least 24 hours before the meeting session.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Slot request for LSR meeting at IETF 115

[Yingzhen Qu]

Dear LSR WG:

The preliminary agenda of IETF 115 has been released, and the LSR session
is scheduled on Wednesday Session I (9:30-11:30).

Please send your presentation request to LSR WG chairs (lsr-cha...@ietf.org)
with the following info:

   - draft to be presented
   - presented
   - estimated time needed, including Q

If there is any question, please let me know.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR Interim Agenda

[Yingzhen Qu]

Hi,

I've uploaded the agenda for the upcoming Interim on Wednesday, 9/21. For
those presentations that were on the IETF 114 LSR agenda I've uploaded the
slides, please let me know if you want to do an update.

All meeting materials can be found here:
https://datatracker.ietf.org/meeting/interim-2022-lsr-01/session/lsr

If there are any questions or concerns please let us know.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR Interim (9/21) Presentation Request

[Yingzhen Qu]

Hi all,

As you know we’re going to have an Interim on September 21st UTC 14:00-16:00.

We have the following presentations that didn’t get time during IETF 114 
session:

IGP Flexible Algorithms Reverse Affinity Constraint
Peter Psenak (5 mins)
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-flex-algo-reverse-affinity/
 


IGP extensions for Advertising Offset for Flex-Algorithm
Louis Chan (10 mins)
https://datatracker.ietf.org/doc/draft-chan-lsr-igp-adv-offset/ 


IS Extension to Advertise SRv6 SIDs using SID Block
Liyan Gong / Weiqiang Cheng (10 mins)
https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/ 


Advertising Exclusive Links for Flex-Algorithm in IGP
Liyan Gong / Weiqiang Cheng (10 mins)
https://datatracker.ietf.org/doc/draft-gong-lsr-exclusive-link-for-flex-algo/ 


We assume these will be presented. If you’re one of the presenters and you 
can’t present for this Interim, please let us know.

Others, please send your presentation request to lsr-cha...@ietf.org 
 with your presentation title, draft pointer and 
expected length including Q before September 16th.


Thanks,
Yingzhen___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-13

[Yingzhen Qu]

Hi Jan,

Thank you for the review, really appreciate. Please see my answers below inline.

Version -14 has been submitted including all the suggested changes.

Thanks,
Yingzhen

> On Aug 17, 2022, at 8:49 AM, Jan Lindblad via Datatracker  
> wrote:
> 
> Reviewer: Jan Lindblad
> Review result: Ready with Issues
> 
> This is the YANG Doctor last call review of draft-ietf-isis-sr-yang-13. I 
> think
> this module is written in a nice, straight forward way. There are a few things
> that have to be fixed before this can be published, however, so I will call it
> ready with issues.
> 
> #1: Dependency on unpublished module
> 
> The ietf-isis-sr module under discussion here imports module ietf-isis. That
> module is still not published as an RFC. For the review here I used the
> ietf-isis.yang as defined in draft-ietf-isis-yang-isis-cfg-42. If the
> ietf-isis.yang module changes before it is published, that could potentially
> affect ietf-isis-sr.
> 
> A closely related observation is that the import statement lacks an import
> reference. Maybe you could add a placeholder reference until you know what RFC
> number to reference?
> 
>  import ietf-isis {
>prefix "isis";
>  }
[Yingzhen]: You’re right about the dependency here. We’ve been waiting for the 
publication
of the base ISIS model, which has a dependency of 
https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc9127-bis/ 
.
Now they’re close to be published, so we requested the review of this document 
to get it ready.
I added a place holder for the reference as you suggested.

> 
> #2: Inappropriate when expressions
> 
> The following when expression appears 13 times in the module. There are two
> problems with it.
> 
>when "/rt:routing/rt:control-plane-protocols/"+
> "rt:control-plane-protocol/rt:type = 'isis:isis'" {
> 
> Direct equality comparison with identities is generally not recommended, as
> that removes the possibility to "subclass" isis:isis into variants in the
> future. The recommended approach is to use the XPath function
> derived-from-or-self() instead. See below.
> 
> The other problem with this when expression is worse. Since an unqualified
> absolute path is used, the expression becomes true for all
> routing-plane-protocol instances as soon as there is at least one of isis 
> type.
> This enables the isis-sr extensions inside all routing-plane-protocol 
> instances
> as soon as there is at least one isis instance in the system. I don't believe
> this was what the authors intended.
> 
> There are several possible ways to remedy the situation. The one I would
> recommend is to use relative paths in the when expression so that the path
> never leaves the current control-plane instance. Since the relative path is a
> little different depending on where it is used, I'll provide two examples. 
> Just
> let me know once you've updated all 13 of them, and I'll review.
> 
> // Line 503
>  augment "/rt:routing/" +
>  "rt:control-plane-protocols/rt:control-plane-protocol"+
>  "/isis:isis" {
> //OLDwhen "/rt:routing/rt:control-plane-protocols/"+
> //OLD "rt:control-plane-protocol/rt:type = 'isis:isis'" {
>when "derived-from-or-self(../rt:type, 'isis:isis')" {
> 
> // Line 587
>  augment "/rt:routing/" +
>  "rt:control-plane-protocols/rt:control-plane-protocol"+
>  "/isis:isis/isis:interfaces/isis:interface" +
>  "/isis:adjacencies/isis:adjacency" {
> //OLDwhen "/rt:routing/rt:control-plane-protocols/"+
> //OLD "rt:control-plane-protocol/rt:type = 'isis:isis'" {
>when "derived-from-or-self(../../../../../rt:type, 'isis:isis')" {
> 
> Basically, you add one ../ for each name in the augment path, starting at the
> tail end working towards the beginning, until you hit the name
> rt:control-plane-protocol (because it is the parent node of rt:type).
> 
> If you prefer, there are solutions using absolute paths too. In that case you
> need to add filters ("predicates") for the control-plane-protocol keys to the
> when expression path. But IMO the method I explained above is probably easier
> to follow.
[Yingzhen]: Thanks for pointing this out. I’ve changed the model to use 
relative path.
Please kindly let me know if you see any issues.
> 
> #3: No mandatory, no default, no description
> 
> Some leafs in the module are not mandatory, have no default and no text in the
> description that would explain how to interpret this ambiguous situation.
> 
>container ti-lfa {
>  if-feature ti-lfa;
>  leaf enable {
>type boolean;
>description
>  "Enables TI-LFA computation.";
>  }
> ...
>leaf use-segment-routing-path {
>  if-feature remote-lfa-sr;
>  type boolean;
>  description
>"force remote LFA to use segment routing
> path instead of LDP path.";
>}
> 
> The client may configure leaf enable to 'true' or 'false', in which case the
> meaning of the 

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Yingzhen Qu]

I support progressing this draft. 

I have the following minor comments for the authors to consider:

The title of Section 4 of this draft is “Advertisement of SRH Operation 
Limits”, and really it only covers the advertisements of MSDs, so may consider 
to change the title to be consistent with the ISIS SRv6 extensions draft, 
"Advertising Maximum SRv6 SID Depths”.
The subsections in section 4 are almost identical to the subsections in 
draft-ietf-lsr-isis-srv6-extesions. It’s up to the authors and the WG to decide 
whether to keep this duplicate.
In draft-ietf-lsr-isis-srv6-extensions, “topology/algorithm” is used, and it’s 
not consistently used in this draft. For example, in section 5 the second 
paragraph, only “algorithm” is used, while “topology/algorithm” is used later.

Nits (line numbers are from idnits):
208the SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]
SR Algorithm/SR-Algorithm  Please add a “-“ to be consistent with RFC 8665.

355The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
“TBD” should be replaced with “42” as in IANA considerations. 

Thanks,
Yingzhen


> On Jul 29, 2022, at 10:16 AM, Acee Lindem (acee) 
>  wrote:
> 
> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
> extra week is to account for PIST (Post-IETF Stress Syndrome). The 
> corresponding IS-IS draft is already on the RFC Queue and there are 
> implementations.
>  
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ 
> 
>  
>  
> Thanks,
> Acee & Chris
>  
>  
> ___
> Lsr mailing list
> Lsr@ietf.org 
> https://www.ietf.org/mailman/listinfo/lsr 
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Yingzhen Qu]

I support the adoption of this draft. These clarifications are needed.

Thanks,
Yingzhen

> On Aug 8, 2022, at 3:17 AM, Christian Hopps  wrote:
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Please send slides Re: Draft LSR agenda uploaded

[Yingzhen Qu]

Hi Presenters,

Please upload or email your slides to lsr-cha...@ietf.org 
<mailto:lsr-cha...@ietf.org>.

Thanks,
Yingzhen

> On Jul 13, 2022, at 11:56 PM, Yingzhen Qu  wrote:
> 
> Hi,
> 
> The draft agenda has been uploaded: 
> https://datatracker.ietf.org/meeting/114/session/lsr 
> <https://datatracker.ietf.org/meeting/114/session/lsr>
> 
> We have received more requests than we can fit into a 2-hour session. The 
> chairs are considering an LSR interim meeting for draft that didn’t make the 
> agenda. Meanwhile please socialize your draft one the list.
> 
> If you’re on the agenda, please email your slides to lsr-cha...@ietf.org 
> <mailto:lsr-cha...@ietf.org>.
> 
> Thanks,
> Yingzhen

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Draft LSR agenda uploaded

[Yingzhen Qu]

Hi,

Considering there are quite a few requests that didn't make the agenda, the
chairs are planning to have an interim after IETF 114, targeting early
September.

The agenda has been updated. Please let us know if you have any questions
or concerns.

Thanks,
Yingzhen

On Wed, Jul 13, 2022 at 8:56 PM Yingzhen Qu  wrote:

> Hi,
>
> The draft agenda has been uploaded:
> https://datatracker.ietf.org/meeting/114/session/lsr
>
> We have received more requests than we can fit into a 2-hour session. The
> chairs are considering an LSR interim meeting for draft that didn’t make
> the agenda. Meanwhile please socialize your draft one the list.
>
> If you’re on the agenda, please email your slides to lsr-cha...@ietf.org.
>
> Thanks,
> Yingzhen
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Draft LSR agenda uploaded

[Yingzhen Qu]

Hi,

The draft agenda has been uploaded: 
https://datatracker.ietf.org/meeting/114/session/lsr 


We have received more requests than we can fit into a 2-hour session. The 
chairs are considering an LSR interim meeting for draft that didn’t make the 
agenda. Meanwhile please socialize your draft one the list.

If you’re on the agenda, please email your slides to lsr-cha...@ietf.org 
.

Thanks,
Yingzhen___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Yingzhen Qu]

Hi Robert,

Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
carry non-routing information which will have impacts on protocol convergence, 
and OSPF-GT is meant to be the vehicle for such information.

BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
entire LSDB or part of it from a router, or subscribe to some data instances. 

Thanks,
Yingzhen

> On Jul 10, 2022, at 3:44 PM, Robert Raszuk  wrote:
> 
> Hi Acee,
> 
> My questions were based on section 3.4 of the latest version of the draft. 
> 
> So I do not think I misinterpreted it. 
> 
> Thank you,
> R.
> 
> 
> 
> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee)  <mailto:a...@cisco.com>> wrote:
> Hi Robert,
> 
>  
> 
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Robert Raszuk mailto:rob...@raszuk.net>>
> Date: Sunday, July 10, 2022 at 1:32 PM
> To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>, Susan 
> Hares mailto:sha...@ndzh.com>>, IDR List  <mailto:i...@ietf.org>>, "g...@ietf.org <mailto:g...@ietf.org> g...@ietf.org 
> <mailto:g...@ietf.org>" mailto:g...@ietf.org>>, lsr 
> mailto:lsr@ietf.org>>
> Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
> 
>  
> 
> Hi Yingzhen & OSPF-GT authors,
> 
>  
> 
> UP front I must state that anything is better to export IGP information from 
> routers to interested nodes than using BGP for it.
> 
>  
> 
> But to propose using OSPF to transport ISIS seems pretty brave :) I must 
> admit it ! 
> 
>  
> 
> With that I have few questions to the proposal - assuming the use case is to 
> distribute links state info in a point to point fashion: 
> 
>  
> 
> What is the advantage - if any - to use a new OSPF instance/process to send 
> link state data over a unicast session to a controller ? 
>  
> 
> It doesn’t have to be unicast, the remote neighbor construct just extends the 
> possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the 
> protocol machinery is in place.  Note that LSDB streaming is just but one use 
> case and of OSPF-GT. The detals of this application would be specified in a 
> separate draft.
> 
>  
> 
>  
> 
> The draft is pretty silent on the nature of such a p2p session. Please be 
> explicit if this is TCP, QUIC or what ? 
>  
> 
> It is OSPF, OSPF has its own protocol identifier (89). This draft just 
> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other 
> questions aren’t really applicable or would be answered in a draft of the 
> OSPF/IS-IS LSDB usage of OSPF-GT.
> 
>  
> 
> Thanks,
> Acee
> 
>  
> 
>  
> 
>  
> 
> C) The draft is pretty silent on types of authentication for such sessions. 
> Security considerations are pretty weak in that respect as well. 
> 
>  
> 
>The security considerations for OSPF-GT will be similar to those for
>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>used to update OSPF routing, the consequences of attacks will be
>dependent on advertised non-routing information.
> 
>  
> 
> I would actually argue that security considerations of p2p remote neighbors 
> are actually quite different from security considerations of flooding data. 
> 
>  
> 
> Along the same lines security is not about protecting your routing ... it is 
> much more about protecting the entire network by exposing critical 
> information externally to non authorized parties. 
> 
>  
> 
> D) Are there any PUB-SUB options possible for OSPF-GT ? 
> 
>  
> 
> E) Is there any filtering possible for OSPF-GT ? 
> 
>  
> 
> F) Are you envisioning use of OSPF-GT proxies and if so are you planning to 
> add this to the document ? 
> 
>  
> 
> G) How are you going to address Receivers which do not support OSPF-GT parser 
> ? 
> 
>  
> 
> H) As you know many operators are attracted to BGP-LS based on the fact that 
> it offers the same view of information irrespective of what is the protocol 
> producing the data. Is there some thought on such normalization in the 
> OSPF-GT proposal ?  
> 
>  
> 
> I) What's the take of OSPF-GT draft authors on the YANG model in respect of 
> using it for normalization of exported data ? 
> 
>  
> 
> To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS or 
> BGP to be messengers of link state data running and to artificially force 
> them to run in a point-to-point model between rout

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Yingzhen Qu]

Hi,

Since we’re discussing possible solutions, I’d like to bring up the draft: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ 


We just submitted a new version. The name of the document is changed to 
“OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a 
possible replacement of BGP-LS.

Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. 
It uses the reachability info calculated by routing protocols, OSPF, ISIS or 
static routing etc.. It provides mechanisms to advertise non-routing 
information, and remote neighbor is supported.

Reviews and comments are welcome.


Thanks,
Yingzhen

> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
> 
> 
> During the interim meeting we should keep it open to discuss all possible 
> alternatives to BGP-LS.
> 
> Thanks 
> 
> Gyan
> 
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  > wrote:
> Jeff:
> 
>  
> 
> An interim sounds like a good plan. 
> 
>  
> 
> [IDR-chair hat]
> 
> Alvaro has indicated that since all of the proposal received on the IDR list 
> are new protocol proposals,
> 
> Capturing IDR’s input on BGP-LS problems and potential solutions is 
> appropriate for IDR as BGP-LS home.
> Refining any potential non-BGP solutions is outside of the scope of IDR.
>  
> 
> [IDR-chair hat off]
> 
> [rtgwg WG member]
> 
> I’d love to attend an interim on this topic.
> 
>  
> 
> Sue Hares
> 
>  
> 
>  
> 
> From: Jeff Tantsura  > 
> Sent: Saturday, July 9, 2022 3:40 PM
> To: Robert Raszuk mailto:rob...@raszuk.net>>
> Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr 
> mailto:lsr@ietf.org>>; i...@ietf.org ; 
> Susan Hares mailto:sha...@ndzh.com>>; g...@ietf.org 
>  g...@ietf.org   >
> Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol
> 
>  
> 
> 
>  
> 
> Speaking as RTGWG chair:
> 
>  
> 
> Robert - I don’t think we’d have enough time to accommodate a good discussion 
> during IETF114 (we got only 1 slot), however would be happy to provide a 
> platform for an interim.
> 
> The topic is important and personally (being a very large BGP-LS user) I’d 
> like to see it progressing.
> 
> Cheers,
> 
> Jeff
> 
> 
> 
> 
> On Jul 8, 2022, at 14:44, Robert Raszuk  > wrote:
> 
> 
> 
> Hi Acee, 
> 
>  
> 
> Yes, by all means input from the operator's community is needed. It can be 
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
> have already seen input from some operators and their opinion on adding and 
> distributing more and more link state protocol and topology data in BGP. More 
> such input is very welcome. 
> 
>  
> 
> And to your point about RFC9086 - I see nothing wrong in keeping BGP 
> information in BGP. So IGP Monitoring Protocol does not target to shut down 
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it. 
> 
>  
> 
> Controllers which today listen to BGP-LS need a number of information sources 
> and that spread will only keep increasing as more inputs are becoming 
> necessary for its computations. 
> 
>  
> 
> Regards,
> 
> Robert.
> 
>  
> 
>  
> 
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  > wrote:
> 
> Hi Robert,
> 
>  
> 
> From: Robert Raszuk mailto:rob...@raszuk.net>>
> Date: Friday, July 8, 2022 at 4:36 PM
> To: Acee Lindem mailto:a...@cisco.com>>
> Cc: lsr mailto:lsr@ietf.org>>, IDR List  >, Susan Hares  >
> Subject: Re: [Lsr] IGP Monitoring Protocol
> 
>  
> 
> Hi Acee,
> 
>  
> 
> Thank you. I was not planning to present it in the upcoming IETF. 
> 
>  
> 
> > Let’s see how many stakeholders actually want to this protocol - then we 
> > can talk about a WG home.  
> 
>  
> 
> An alternative approach could be to see how many stakeholders do not want to 
> further (for no good reason) to trash BGP. That to me would be in this 
> specific case a much better gauge.  
> 
>  
> 
> In that case, it seems to me that this discussion should be relegated to IDR. 
> Note that there is already non-IGP information transported in BGP-LS, e.g., 
> Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/ 
> ). I implemented this on our data 
> center routers (NXOS) years and it is solely BGP specific.
> 
>  
> 
> Thanks,
> 
> Acee
> 
>  
> 
> Kind regards,
> 
> Robert
> 
>  
> 
>  
> 
> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  > wrote:
> 
> Speaking as WG chair:
> 
>  
> 
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Robert Raszuk mailto:rob...@raszuk.net>>
> Date: Friday, July 8, 2022 at 3:21 PM
> To: lsr mailto:lsr@ietf.org>>
> Cc: IDR List mailto:i...@ietf.org>>, Susan Hares 
> mailto:sha...@ndzh.com>>
> Subject: 

[Lsr] IETF 114 LSR Slot Request

[Yingzhen Qu]

Hi,

The preliminary agenda for IETF 114 has been posted: 
https://datatracker.ietf.org/meeting/114/agenda/ 
 

LSR will have one session:

Friday, July 29, 2022
12:30 - 14:30 Session II
Liberty B

Please send slot request to lsr-cha...@ietf.org . 
Please include draft name, presenter, slot length including Q 

Thanks,
Yingzhen___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Yingzhen Qu]

I support option #2, publishing as an experimental RFC. Later it can be
moved to either standard or historic.

Thanks,
Yingzhen

On Tue, Jun 14, 2022 at 1:00 PM Les Ginsberg (ginsberg)  wrote:

> John -
>
> I would be inclined to agree with you - but...to my knowledge (happy to be
> corrected...) -
>
> There has been no interoperability testing.
> It is really only possible to do interoperability testing on centralized
> mode at present, since distributed mode requires
> standardization/multi-vendor implementation of at least one algorithm -
> which hasn’t happened yet.
> So, a significant portion of the protocol extensions remain untested. And
> since enthusiasm for this work has waned - perhaps only temporarily - it
> seems unlikely that these gaps will be closed in the immediate future.
> Moving to standards track RFC with these gaps seems unwise and to some
> degree "irresponsible".
>
> I think there are then three viable paths:
>
> 1)Continue to refresh the draft until such time as the gaps are closed or
> it becomes clear the work is more permanently not of interest
> 2)Capture the current contents as an Experimental RFC - noting the
> remaining work.
> 3)Capture the current contents as a Historic RFC - noting the remaining
> work.
>
> I am not in favor of #3.
> I would be OK with #1 or #2.
>
>Les
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of John E Drake
> > Sent: Tuesday, June 14, 2022 11:23 AM
> > To: Les Ginsberg (ginsberg) ; John
> > Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> draft-ietf-lsr-dynamic-
> > flooding
> >
> > Hi,
> >
> > I don't understand why we don't just go through the normal Standards
> track
> > process.  I am sure there are any number of Standards track RFCs which
> are
> > published and which are neither widely implemented nor widely deployed,
> > but which may become so in the future.
> >
> > As Peter noted in the context of another draft, we are starting to see
> > extreme growth in the size of IGPs  which to me indicates that the
> subject
> > draft will be perceived as timely in the not too distant future.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> > > Sent: Tuesday, June 14, 2022 12:19 PM
> > > To: John Scudder 
> > > Cc: Tony Li ; tom petch ; Acee
> > Lindem
> > > (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-
> > dynamic-
> > > flooding
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > John -
> > >
> > > Thanx for the information.
> > >
> > > I think what is relevant as regards the dynamic-flooding draft is that
> we
> > may be
> > > prematurely burying it.
> > > It is true, as Tony has stated, that the marketplace has not shown an
> active
> > > interest in deploying this technology - but I am not yet convinced
> that this is
> > the
> > > final disposition. As the scale of IGP networks increases and the use
> of fast-
> > > flooding is deployed, it may be that interest in dynamic-flooding is
> revived.
> > >
> > > Publishing the draft as Experimental leaves open the possibilities.
> > > It could still be moved to Historic somewhere down the road if there
> > continues
> > > to be no deployment interest.
> > >
> > > I suppose it is also possible (as your post indicates) that we move it
> to
> > historic
> > > now and find a way to move it from historic if/when the need arises -
> but I
> > > frankly find such an approach very odd.
> > >
> > > I do not know why we are in a rush to "bury this". I think Acee has
> raised a
> > valid
> > > point - given that there was broad consensus on the protocol extensions
> > > themselves - that it would be good to formally preserve the draft
> content. I
> > think
> > > Experimental is the best way to do that.
> > >
> > > Les
> > >
> > > > -Original Message-
> > > > From: John Scudder 
> > > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > > To: Les Ginsberg (ginsberg) 
> > > > Cc: Tony Li ; tom petch ; Acee
> > > > Lindem (acee) ; lsr@ietf.org
> > > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > > draft-ietf-lsr-dynamic- flooding
> > > >
> > > > Hi Les and all,
> > > >
> > > > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
> > > >  wrote:
> > > > >
> > > > > So you are suggesting that we publish something that was never
> > > > > actually
> > > > published as an RFC as a "historic RFC"?
> > > > >
> > > > > The logic of that escapes me.
> > > >
> > > > It so happens I recently became aware that this publication track is
> > > > explicitly considered to be OK.
> > > >
> > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
> > > > tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
> > > l3RWY9vSXdEA8b
> > > >
> > >
> > 

Re: [Lsr] WG last call for draft-ietf-lsr-ospf-terminology-00

[Yingzhen Qu]

Agreed with the points Les made, and I support progressing this document.

Thanks,
Yingzhen

> On Jun 10, 2022, at 1:29 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> I support progressing this document.
> Changes are straightforward/non-controversial and have no impact on the 
> operation of the protocol - no reason we should not expedite this.
> 
>   Les
> 
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Christian Hopps
>> Sent: Sunday, June 5, 2022 2:48 AM
>> To: lsr@ietf.org
>> Cc: cho...@chopps.org; draft-ietf-lsr-ospf-terminol...@ietf.org; lsr-
>> a...@ietf.org; lsr-cha...@ietf.org
>> Subject: [Lsr] WG last call for draft-ietf-lsr-ospf-terminology-00
>> 
>> Given the simplicity of this document and having received no objections or
>> edits prior to or during the adoption call we'll be moving it immediately to
>> WGLC...
>> 
>> This begins a 2 week WG Last Call, ending Jun 19th, 2022, for:
>> 
>>  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/
>> 
>> Authors,
>> 
>>  Please indicate to the list, your knowledge of any IPR related to this work.
>> 
>> Thanks,
>> Chris.
>> 
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-fox-lsr-ospf-terminology-01

[Yingzhen Qu]

Sorry for the late response.

Thanks to the authors for working on this document. I think the language change 
is important and needed.

I support adoption of this draft.

Thanks,
Yingzhen

> On Apr 25, 2022, at 6:46 AM, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/
> 
> Please indicate your support or objections by May 9th, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Yingzhen Qu]

Hi Rob,

Thanks for the thoughtful proposal, and I support it.

One thing to confirm, for models that may become RFCs in the next two years and 
where the IP address doesn’t support zones, "ip-address” should still be used. 
Correct?

Thanks,
Yingzhen


> On Apr 11, 2022, at 10:06 AM, Rob Wilton (rwilton) 
>  wrote:
> 
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if we are 
> able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and the v4/v6 
> versions) are badly named as the prominent default type name has been given 
> to the unusual variant of including zone information.
> 
> Based on the comments on this thread, it also seems likely to me that most of 
> the usages of ip-address in YANG RFCs is likely to be wrong, and the 
> intention was that IP addresses without zones was intended.  At a rough 
> count, of the published RFC YANG models at github 
> YangModels/standard/ietf/RFC/ to be:
>   86 uses of ip-address
>   68 uses of ipv4-address
>   66 uses of ipv6-address
> 
>   1 use of ip-address-no-zone
>   4 uses of ipv4-address-no-zone
>   4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
> quick guess/check it looks like these 49 YANG modules may appear in 40-50 
> RFCs.
> 
> As mentioned previously, it is also worth comparing this to the OpenConfig 
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone 
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP 
> addresses in the latest OpenConfig github repository.  However, approximately 
> a third of the IP address types are still to the ietf-inet-types.yang rather 
> than openconfig-inet-types.yang, so in theory some of those 58 entries could 
> still intentionally be supporting zoned IP addresses, but I would expect that 
> the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way 
> in both IETF and OC YANG, and I believe that the OC folks have got the 
> definition right.
> 
> I see that some are arguing that the zone in the ip-address definition is 
> effectively optional, and implementations are not really obliged to implement 
> it.  I don't find that argument compelling, at least not with the current 
> definition of ip-address in RFC 6991.  I see a clear difference between a 
> type defined with an incomplete regex that may allow some invalid values and 
> a type that is explicitly defined to included additional values in the 
> allowable value space.  Further, I believe that a client just looking at the 
> YANG module could reasonably expect a server that implements a data node 
> using ip-address would be expected to support IP zones, where they are 
> meaningful, or otherwise they should deviate that data node to indicate that 
> they don't conform to the model.
> 
> We also need to be realistic as to what implementations will do.  They are 
> not going to start writing code to support zones just because they are in the 
> model.  They will mostly reject IP addresses with zone information.  Perhaps 
> some will deviate the type to ip-address-no-zone, but probably most won't.
> 
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
> appealing.  This would take a significant amount of time/effort and I think 
> that we will struggle to find folks who are willing to do this.  Although 
> errata could be used to point out the bug, then can't be used to fix it, all 
> the errata would be "hold for document update" at best.  Further, during the 
> time that it would take us to fix it, it is plausible that more incorrect 
> usages of ip-address will likely occur (but perhaps could be policed via 
> scripted checks/warnings).
> 
> 
> I still feel the right long-term solution here is to get to a state where the 
> "ip-address" type means what 99% of people expect it to mean, i.e., excluding 
> zone information.
> 
> Given the pushback on making a single non-backwards compatible change to the 
> new definition, I want to ask whether the following might be a possible path 
> that gains wider consensus:
> 
> (1) In RFC 6991 bis, I propose that we:
> (i) define new ip-address-with-zone types (and v4 and v6 versions) and keep 
> the -no-zone versions.
> (ii) we change the description of "ip-address" to indicate:
> - Although the type allows for zone information, many implementations are 
> unlikely to accept zone information in most scenarios (i.e., so the 
> description of the type more accurately reflects reality).
> - A new ip-address-with-zone type has been introduced to use where zoned IP 
> addresses are required/useful, and models that use ip-address with the 
> intention of supporting zoned IP addresses MUST migrate to 
> ip-address-with-zone.
> - In the 

Re: [Lsr] LSR IETF 113 Agenda Published

[Yingzhen Qu]

Hi LSR Presenters,

Please email your slides to lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org> 
ASAP.

Thanks,
Yingzhen

> On Mar 7, 2022, at 8:14 PM, Yingzhen Qu  wrote:
> 
> Hi,
> 
> The LSR agenda for IETF 113 has been published:
> https://datatracker.ietf.org/meeting/113/session/lsr 
> <https://datatracker.ietf.org/meeting/113/session/lsr> 
> 
> Please let us know if you have any comments. 
> 
> Thanks,
> Yingzhen

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR IETF 113 Agenda Published

[Yingzhen Qu]

Hi,

The LSR agenda for IETF 113 has been published:
https://datatracker.ietf.org/meeting/113/session/lsr 
 

Please let us know if you have any comments. 

Thanks,
Yingzhen___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR IETF 113 Slot Requests

[Yingzhen Qu]

Hi,

The draft agenda for IETF 113 has been posted: 
https://datatracker.ietf.org/meeting/113/agenda/ 


LSR is scheduled to meet on Thursday afternoon session II, 14:30-16:30 UTC, 
March 24.

Please send slot requests to lsr-cha...@ietf.org , 
including draft name, presenter, desired slot length (including 
Q/discussions). 

Thanks,
Yingzhen___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Yingzhen Qu]

Hi Chris,

Put the content together, my understanding is that “As a WG member, I agree 
with Tony P’s comments about using transport instance.” Please correct me if I 
misunderstood you, and I’ll update the minute.

Thanks,
Yingzhen

> On Nov 17, 2021, at 6:59 AM, Christian Hopps  wrote:
> 
> 
> 
>> On Nov 16, 2021, at 10:36 PM, Aijun Wang  wrote:
>> 
>> Hi, 
>> 
>> The followings are the responses for the comments on PUAM 
>> draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)
>> 
>> Les:  The comment I want to make, I think the discussion on the
>>  list highlighted the fact that there's an open question,
>>  independent of whether we use the prefix unreachable
>>  draft or the Event Notification draft, as to whether this
>>  problem should be solved by the IGP or whether it should be
>>  solved by BGP, or in some other way. And I think the logical
>>  way to proceed on this is to get the consensus of the working
>>  group as to whether an IGP solution is desired first, then
>>  after we reach consensus on that, then we can start talking
>>  about which approach is the better approach. Which one
>>  should be adopted?
>> 【WAJ】The problem is occurred due to the summary action by the ABR router in 
>> IGP, it should be solved by IGP itself.
>> As discussed earlier on the list, the possible use case is not limited to 
>> BGP fast convergence.
>> Based on the above considerations, it is not appropriated solved via BGP. 
>> 
>> Chris H:  Chair hat on. You've been asking for adoption for a while.
>>  The event notification draft is new. I agree with Les that
>>  in a perfect world that would be the case, but asking for
>>  adoption is one way to answer the question. It may be not
>>  the perfect way to answer that question, but it is one way.
>>  I agree without my chair hat on, I'm not sure we need this,
>>  but it's not for me to say by fiat. Acee did put something
>>  out on the list to try to engage people again. And I don't
>>  think a lot got said.
>> 【WAJ】we have several round discussions for this topic but there is always no 
>> conclusion at the end. 
>>   Can the expert that reluctant to accept the new idea to give some 
>> specific questions/problems for the current solution?
>>  Or else it is not helpful for the solve of the existing problem.
>>   Initiate the adoption call maybe the best way to let the experts 
>> express their opinions? 
>>   We would like to hear the specific and detail comments for the current 
>> solutions, not just general comments.
>> 
>> Acee: I didn't see much support other than from the authors. I
>>  saw one non-author support on the event notification. 
>> 【WAJ】Does anyone not agree what we analyze/summarize at the presentation 
>> material for the two solutions? 
>> (https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf,
>>  the 5th slide)
>> 
>> Chris:Everyone has a right to ask for an adoption. Everyone has a
>>  right to say we shouldn't adopt this and there are the
>>  reasons. We've let people to express opinions, without
>>  seeing a lot of negative opinions it's hard not to just grant
>>  the adoption call.
>> 【WAJ】I agree.
>> 
>> Tony P:   I think this is all making a trash can out of the IGP. One
>>  possible solution is to ban or encouraged maybe everyone with
>>  these kind of suggestions to go towards the service instance
>>  stuff or whatever we call it, which I think is a good idea.
>>  Just run a power line up and much lower priority. Don't trash
>>  the main protocol that holds the whole thing together.
>> 【WAJ】Do you consider the deployment complexity for independent service 
>> instance to transfer such thing? And also the interaction on the device 
>> among the main IGP instance and the service instances? It’s the fault of the 
>> main protocol, and should be solved by the main protocol.
>> 
>> Chris:Great comment for the adoption call. As a WG member, I agree.
> 
> This makes it seem like I'm saying that I agree with your response. I'd 
> strike that "As a WG member, I agree".
> 
> Thanks,
> Chris.
> 
> 
>> 
>> 
>> 
>> From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
>> (acee)
>> Sent: Wednesday, November 17, 2021 2:56 AM
>

[Lsr] Slides Please Re: LSR Draft Agenda Available

[Yingzhen Qu]

Hi presenters,

If you haven't sent your slides please send them to lsr-cha...@ietf.org
ASAP.

One suggestion is to add page numbers in your slides, and it would be
helpful when people ask questions.

Thanks,
Yingzhen

On Wed, Oct 27, 2021 at 8:03 PM Yingzhen Qu  wrote:

> Hi all,
>
> I’ve uploaded the draft agenda:
> https://datatracker.ietf.org/meeting/112/session/lsr
>
> Please take a look and let us know if any changes are needed.
>
> Presenters,
> Please provide your slides as early as possible.
>
> Thanks,
> Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR Draft Agenda Available

[Yingzhen Qu]

Hi all,

I’ve uploaded the draft agenda: 
https://datatracker.ietf.org/meeting/112/session/lsr

Please take a look and let us know if any changes are needed.

Presenters,
Please provide your slides as early as possible.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR Presentation Slot Requests - IETF 112

[Yingzhen Qu]

Hi all,

The IETF 112 Final Agenda is now available: 
https://datatracker.ietf.org/meeting/112/agenda.html 


We will have one LSR session:
Thursday, November 11, 2021
12:00-14:00 UTC
Thursday Session I

Please send slot requests to lsr-cha...@ietf.org 
. Please include name of the presenter, pointer 
to the draft and time estimation including Q 

Thanks,
Yingzhen

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Yingzhen Qu]

I have been following the discussions on the list, and here comes my $0.02:

ASLA provides a generic mechanism of associating different applications and 
link attributes. The WG reached consensus of this architecture after long 
debate, so my understanding is new proposals should follow this path unless 
it’s impossible to use ASLA to define the new attributes. So far I’m not 
convinced by the discussions on the list that draft-ietf-lsr-flex-algo-bw-con 
can not use ASLA and has to specify an alternative, and the alternative is 
better.

Thanks,
Yingzhen

> On Aug 18, 2021, at 1:20 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Ron -
>  
> Indeed – it is long past the time when we should be focusing on the “big 
> picture”.
> I think Acee has stated it as succinctly as anyone – let me repeat for 
> emphasis:
>  
> “The LSR WG developed ASLAs to cover usage of the link attributes (including 
> metrics) for different applications and mitigate all the vagaries of the 
> original TE link attribute specifications. ASLAs are implemented and 
> deployed. I believe it would be a mistake to bifurcate the IGP standards with 
> yet another way of encoding link attributes for different applications.”
>  
> ASLA is an architecture – one designed to assure that we can explicitly 
> identify the set of applications using any link attribute . It is designed to 
> be extensible both to new applications and to new attributes. It was long 
> debated in the WG and underwent extensive review and is now standardized in 
> RFCs 8919, 8920. It has been implemented and deployed and forms the basis of 
> interoperable implementations.
>  
> Now you (and others) decide to invent a new attribute. The attribute 
> certainly can be advertised using ASLA, but instead of acknowledging the 
> existence of the ASLA architecture and defining the new attribute to use 
> ASLA, you decide that maybe if we advertise this attribute in some new way 
> there might be some modest advantages. This ignores the consequences of 
> having to implement attribute specific encoding rules in order to map 
> attributes to applications. These consequences include greater code 
> complexity and higher probability of interoperability issues.
>  
> And, based on your list of attributes below, what have we to look forward to? 
> More attribute specific encoding rules leading to even greater code 
> complexity and greater chance of interoperability problems it would seem.
>  
> Look, you haven’t convinced me that your alternative proposals are “better”. 
> But even if they were, it would require a much greater benefit than you are 
> claiming to justify discarding the architecture that is designed to fully 
> address the association of link attributes and the applications which use 
> them.
>  
> I don’t expect to convince you – and you have not convinced me – and we 
> probably never will agree. But since it is clear that ASLA does work for all 
> the cases that have been mentioned in this and related threads, I think this 
> discussion is a waste of WG time.
>  
> It is time to close this discussion.
>  
>Les
>  
>  
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Ron Bonica
> Sent: Tuesday, August 17, 2021 11:21 AM
> To: Acee Lindem (acee)  >; lsr@ietf.org 
> Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
>  
> Acee,
>  
> So, let us discuss whether there is a good reason for 
> draft-ietf-lsr-flex-algo-con to specify ASLA !
>  
> Link attributes are different from application configuration information. 
> Link attributes are properties of a link.  They are independent of the 
> applications that use them. The following are examples:
>  
> Total physical bandwidth
> Number of LAG elements
> Bandwidth of smallest lag member
> Latency
>  
> Link attributes do not benefit from ASLA encoding because they are not 
> application specific.
>  
> Application configuration information constrains the behavior of an 
> application. It can apply to:
>  
> The application and a link
> The application only
>  
> Bandwidth reservation applies to an application and a link. For example, a 
> link may advertise that it has:
>  
> X Gbps available for RSVP-TE reservations
> Y Gbps available for SR Policy reservations
> Z Gbps available for TI-LFA reservations
>  
> This class of configuration information clearly benefits from ASLA encoding, 
> because it is applicable to both the application and the link.
>  
> Some applications (e.g., Flexalgo) can be configured to use a variety of link 
> attributes in SPF calculation. No matter how they acquire this configuration 
> information, it MUST be the same at each node. Otherwise, routing loops may 
> result. Configuration options are:
>  
> Configure this information on each link and advertise link attributes with 
> ASLA
> Configure this information on each node that runs the application
> Configure this information in a few 

[Lsr] Pointer to LSR Meeting Materials

[Yingzhen Qu]

Hi all,

You can find all LSR meeting materials including agenda, slides etc. at:  
https://datatracker.ietf.org/meeting/111/session/lsr

Note: both the presentation slides for the upcoming flooding speed discussion 
have been uploaded. If you’re interested you can look at them before the 
meeting.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Slides Please Re: LSR draft agenda

[Yingzhen Qu]

Hi LSR presenters,

Please send your slides to lsr-cha...@ietf.org.

Thanks,
Yingzhen

> On Jul 14, 2021, at 9:22 PM, Yingzhen Qu  wrote:
> 
> Hi all,
> 
> The draft agenda has been published: 
> https://datatracker.ietf.org/meeting/111/materials/agenda-111-lsr-00 
> 
> We have a very tight schedule. Please take a look and let us know if any 
> change is needed.
> 
> We allocated 65 mins for Flooding Speed, including both Les and Bruno’s 
> presentations and discussion. Hopefully we can reach some consensus. 
> 
> 
> Les and Bruno,
> 
> Would you please send your slides as earlier as possible? So people can have 
> some time to prepare. 
> 
> Other presenters,
> 
> Please email your slides to lsr-cha...@ietf.org.
> 
> Thanks,
> Yingzhen
> 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[Yingzhen Qu]

I support the adoption of both drafts as a co-author.

I’m not aware of any IPR that applies to these drafts.

Thanks,
Yingzhen

> On Jul 22, 2021, at 3:48 AM, Christian Hopps  wrote:
> 
> 
> Hi Folks,
> 
> This begins a 3 week WG Adoption Call for the following related YANG drafts:
> 
> https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
> https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/
> 
> Please indicate your support or objections by August 12th, 2021
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR draft agenda

[Yingzhen Qu]

Hi all,
 
The draft agenda has been published: 
https://datatracker.ietf.org/meeting/111/materials/agenda-111-lsr-00 

We have a very tight schedule. Please take a look and let us know if any change 
is needed.

We allocated 65 mins for Flooding Speed, including both Les and Bruno’s 
presentations and discussion. Hopefully we can reach some consensus. 


Les and Bruno,

Would you please send your slides as earlier as possible? So people can have 
some time to prepare. 

Other presenters,

Please email your slides to lsr-cha...@ietf.org.

Thanks,
Yingzhen



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR Presentation Slot Requests - IETF111

[Yingzhen Qu]

Hi all,

The draft agenda for IETF111 has been posted: 
https://datatracker.ietf.org/meeting/111/agenda 
. 

LSR will have one meeting session: Friday, July 30, 2021 16:00-18:00  Session 
III PDT

Please send slot requests to lsr-cha...@ietf.org. Please include name of the 
presenter, pointer to the draft and time estimation including Q 

Thanks,
Yingzhen

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Yingzhen Qu]

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]
153OSPFv3 that enable a router to advertise TLVs that identify (a)
154calculation-type, (b) specify a metric-type, and (c) describe a set
Should be “that (a) identify”

313for a given Flexible-Algorithm from the same originator SHOULD select
314the first advertisement in the lowest numbered LSP.
“SHOULD” should be changed to “MUST”.

Thanks,
Yingzhen


> On Jun 17, 2021, at 8:44 AM, bruno.decra...@orange.com wrote:
> 
> 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 ; Acee Lindem
>> (acee) ; lsr@ietf.org
>> Cc: lsr-...@ietf.org; Christian Hopps ; 
>> 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 ;
>>> 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=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.
>>> 
> 
> 
> 

[Lsr] Q for OSPF Transport Instance

[Yingzhen Qu]

Hi,

On behalf of co-authors, thanks for the support of WG adoption of this draft.

There were some questions asked, and we’ve compiled them together into this 
Q Comments and questions are welcome.

Thanks,
Yingzhen


Q: In section 4.3 of this draft, it says: 
   "The OSPF transport instance is not dependent on any other OSPF
   instance.  It does, however, have much of the same as topology
   information must be advertised to satisfy the "condition of
   reachability".  
   Then, this transport instance should also advertise the topology
   information. Right?
   But in section 4.5, the advertisement of inter-area information is
   omitted(Summary-LSA for OSPFv2/inter-area-prefix-LSA for OSPFv3). 
   So, how to transfer the non-routing information across different areas?
   Using the remote OSPF neighbor?

A: OSPF transport instance is not dependent on any other OSPF instance. 
   It’s possible that you run OSPF transport instance without regular OSPF
   instance.
   The topology information advertised by OSPF transport instance is to 
   satisfy the "condition of reachability", not for routing table/RIB update.
   We'll clarify in OSPFv2 this will include the type-4 summaries related to the
   transport instance topology. 


Q: The reason that we use the IGP to transfer the non-routing information is
   that the IGP assures the reachability/dissemination of such information.
   Using independent transport instance, the operator need again the design and
   deployment of the distributed topology. And most important, the correlation
   between the routing information and non-routing information is not solved or
   covered within the current draft, which is the merit of other solutions.
   There should be solutions/considerations to the possible problem as that
   described in
   https://datatracker.ietf.org/doc/html/draft-bowers-lsr-isis-gen-info-clarifi
   cations-00 for IS-IS.

A: The topology of OSPF transport instance may or may not be the same as
   the regular OSPF instance, and it's up to the applications that uses OSPF
   transport instance. The support of sparse topology and remote neighbor
   makes it possible for only some routers in the network get the application
   info.
   It is expected the applications in the transport instance will advertise
   non-routing information and, hence, there will be no requirement for
   correlation between route routing and non-routing instance. 


Q: Section 4.7 described the "Non-Routing Sparse Topologies". It requires
   again the careful design and deployment. Is it more straightforward to let
   the IGP routers relay such information and only the necessary nodes to
   store/utilize it? 

A: As mentioned above, sparse topologies make it possible for only routers
   interested in certain applications get involved, and this doesn't impact 
   other routes and routing calculations in regular OSPF instance.
   I don't understand your suggestion of only necessary nodes to store/utilize
   it. This seems not consistent with the idea of link state protocol.


Q: Add a section on how to advertise information in a transport instance if 
   an application requires, per-link resource information to be advertised in 
   transport instance.

A: This is dependent on the application and while it may be better for some
   applications to advertise separate LSAs per link, for others, it may make
   sense to have a lists of interfaces in a single LSA. 


Q: Some applications may require to co-relate the information in transport 
instance
   to a specific routing-instance. This requirement to be addressed.

A: This should be addressed by the application draft when using OSPF transport 
   instance. Again, it is expected that routing information will be in the 
routing
   instance. 


Q: There may be cases when application information gets associated with 
   prefixes rather than nodes. We should allow advertisement of Extended  
   Prefix-LSA and E-Intra-area-Prefix-LSA/E-Inter-Area-Prefix-LSA 
Advertisements 
   inside transport instance.

A: While an application could define prefix-level information with semantics 
identical
   to these LSAs, it would not use these LSAs. There are for routing 
information. 


Q: It seems like we could reuse RI-LSA and originate RI-LSA in transport 
   instance with application-ID TLV. What is the Need to define yet another 
   opaque LSA?

A:  so we have a clear cut of application data, and hopefully this can
simplify implementations.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Yingzhen Qu]

Speaking as co-author, I support WG adoption, and I’m not aware of any IPR that 
applies to this draft.

Thanks,
Yingzhen

> On May 2, 2021, at 1:39 AM, Christian Hopps  wrote:
> 
> 
> This begins a 2 week WG adoption call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
> 
> Please indicate your support or objection by May 16th, 2021.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
> 
> Historical Note: The original OSPF transport instance document was adopted by 
> the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
> individual submission to LSR in Sep 2020. :)
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110

[Yingzhen Qu]

Hi,

I also support the split of ietf-bfd-mpls-te module from the base BFD module, 
so modules like ietf-ospf and ietf-isis can progress.

Thanks,
Yingzhen

> On Mar 22, 2021, at 2:33 AM, tom petch  wrote:
> 
> 
> 
> From: Rtg-bfd  on behalf of Reshad Rahman 
> 
> Sent: 19 March 2021 18:58
> To: rtg-bfd@ietf. org
> Subject: Draft minutes for BFD @ IETF110
> 
> BFD WG,
> 
> Draft minutes have been posted @ 
> https://datatracker.ietf.org/doc/minutes-110-bfd/
> 
> Please provide comments to the list by April 2nd.
> 
> 
> I support Acee's suggestion that the TE part should be split from the BFD 
> YANG draft so that the other three WG, who have been held up for years, can 
> progress.
> 
> Tom Petch
> 
> Copying the LSR WG.
> 
> 
> Meeting recording is @ https://www.youtube.com/watch?v=vSqfJJ3gOc0
> 
> Regards,
> Reshad.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] LSR Agenda Updated

[Yingzhen Qu]

Hi all,

We've updated the agenda and put all the flex-algo related presentations
together : https://datatracker.ietf.org/meeting/110/materials/agenda-110-lsr

Please let us know if you have any questions.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Slides Please Re: IETF 110 LSR session Agenda

[Yingzhen Qu]

Presenters,

Reminder, Please send your slides to lsr-cha...@ietf.org 
<mailto:lsr-cha...@ietf.org>. Since LSR session is scheduled on Monday, please 
send your slides no later than this Friday.

Thanks,
Yingzhen


> On Feb 25, 2021, at 8:02 PM, Yingzhen Qu  wrote:
> 
> Hi all,
> 
> A draft agenda of IETF 110 LSR session has been posted: 
> https://datatracker.ietf.org/meeting/110/materials/agenda-110-lsr 
> <https://datatracker.ietf.org/meeting/110/materials/agenda-110-lsr> 
> 
> Please take a look and let us know if you have any questions or if we have 
> missed anything.
> 
> Presenters:
> Please send your slides to lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>. 
> Since LSR session is scheduled on Monday, please send your slides no later 
> than the Friday before.
> 
> Thanks,
> Yingzhen

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Yingzhen Qu]

I’ve read the draft and support the publication.

Thanks,
Yingzhen

> On Feb 17, 2021, at 7:30 AM, Christian Hopps  wrote:
> 
> Hi LSR and TEAS,
> 
> This begins a joint WG last call for:
> 
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> 
> Please discuss any issues on the LSR mailing list. The WGLC will end March 3, 
> 2021.
> 
> Authors, please indicate wether you are aware of any IPR related to this 
> document to the list.
> 
> Thanks,
> Chris, Acee, (Lou and Pavan).
> ___
> Teas mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 110 LSR session Agenda

[Yingzhen Qu]

Hi all,

A draft agenda of IETF 110 LSR session has been posted:
https://datatracker.ietf.org/meeting/110/materials/agenda-110-lsr

Please take a look and let us know if you have any questions or if we
have missed anything.

Presenters:
Please send your slides to lsr-cha...@ietf.org. Since LSR session is
scheduled on Monday, please send your slides no later than the Friday
before.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-acee-lsr-ospf-transport-instance-02.txt

[Yingzhen Qu]

Hi Les,

Thank you for the review and comments. Please see my answers inline.

Thanks,
Yingzhen

> On Feb 23, 2021, at 11:15 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Yingzhen –
>  
> Thanx for incorporating my suggestion to use the Application Identifiers 
> Registry created in RFC 6823 ( 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#app-ids-251
>  
> <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#app-ids-251>
>  ) to allow sharing of application IDs between IS-IS and OSPF.
> I think, however, that we may well want to revise the format of this registry 
> – which is currently very IS-IS centric. Things we may want to consider 
> requesting from IANA:
>  
> Specifying whether the ID can be used by OSPF, IS-IS, or both.
> Moving the registry from the IS-IS TLV Codepoints registry to Interior 
> Gateway Protocol (IGP) Parameters 
> (https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml 
> <https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml> )
>  
> Happy to work with you folks on this.
>  
> Some editorial nits in Section 3.3

[Yingzhen]: Happy to work with you on the registry. 
>  
> “In some cases, it is desirable to limit the number of BGP-LS
>[RFC5572] sessions with a controller to the a one or two routers in
>  
> s/to the a/to
>  
>an OSPF domain.  However, many times those router(s) do not have full
>visibility to the complete topology of all the areas.  To solve this
>problem without extended the BGP-LS domain, the OSPF LSAs for non-
>  
> s/extended/extending
>  
>local area could be flooded over the OSPF transport instance topology
>using remote neighbors Section 4.7.1.”
>  
[Yingzhen]: Thank you for catching these, will fix these nits in the next 
version.

>  

>Les
>  
> From: Lsr  On Behalf Of Yingzhen Qu
> Sent: Monday, February 22, 2021 12:31 PM
> To: lsr@ietf.org
> Cc: Abhay Roy ; Acee Lindem (acee) ; Sina 
> Mirtorabi 
> Subject: [Lsr] Fwd: New Version Notification for 
> draft-acee-lsr-ospf-transport-instance-02.txt
>  
> Hi,
>  
> We submitted a new version of this draft with detailed OSPFv2 and OSPFv3 
> encodings. Please review and send your comments.
>  
> Thanks,
> Yingzhen
> 
> 
>  
> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>
> Sent: Sunday, February 21, 2021 11:21 AM
> To: Abhay Roy mailto:ab...@arrcus.com>>; Acee Lindem 
> mailto:a...@cisco.com>>; Sina Mirtorabi  <mailto:smirt...@cisco.com>>; Yingzhen Qu  <mailto:yingzhen...@futurewei.com>>
> Subject: New Version Notification for 
> draft-acee-lsr-ospf-transport-instance-02.txt
>  
> 
> A new version of I-D, draft-acee-lsr-ospf-transport-instance-02.txt
> has been successfully submitted by Yingzhen Qu and posted to the
> IETF repository.
> 
> Name:   draft-acee-lsr-ospf-transport-instance
> Revision:   02
> Title:  OSPF Transport Instance Extensions
> Document date:  2021-02-19
> Group:  Individual Submission
> Pages:  14
> URL:   
> https://www.ietf.org/archive/id/draft-acee-lsr-ospf-transport-instance-02.txt 
> <https://www.ietf.org/archive/id/draft-acee-lsr-ospf-transport-instance-02.txt>
>  
> Status: 
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/ 
> <https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/> 
> Htmlized:  
> https://datatracker.ietf.org/doc/html/draft-acee-lsr-ospf-transport-instance 
> <https://datatracker.ietf.org/doc/html/draft-acee-lsr-ospf-transport-instance>
>  
> Diff:  
> https://www.ietf.org/rfcdiff?url2=draft-acee-lsr-ospf-transport-instance-02 
> <https://www.ietf.org/rfcdiff?url2=draft-acee-lsr-ospf-transport-instance-02> 
> 
> Abstract:
>OSPFv2 and OSPFv3 include a reliable flooding mechanism to
>disseminate routing topology and Traffic Engineering (TE) information
>within a routing domain.  Given the effectiveness of these
>mechanisms, it is convenient to envision using the same mechanism for
>dissemination of other types of information within the domain.
>However, burdening OSPF with this additional information will impact
>intra-domain routing convergence and possibly jeopardize the
>stability of the OSPF routing domain.  This document presents
>mechanism to relegate this ancillary information to a separate OSPF
>instance and minimize the impact.
> 
>   
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org 
> <http://tools.ietf.org/>.
> 
> The IETF Secretariat

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request a 10 minute slot at IETF110 LSR session to brief the draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Yingzhen Qu]

Hi Linda,

I've noted down your request, and the agenda will be arranged based on all the 
requests received. Please pay attention to the agenda when posted.

Thanks,
Yingzhen

> On Feb 23, 2021, at 8:03 AM, Linda Dunbar  wrote:
> 
> Acee, Christian, and YingZhen, 
>  
> Can we have a 10-minutes slot at the IETF 110 LSR session to brief 
> thehttps://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/
>  
> <https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/> 
> ?
>  
>  
> Based on the mailing list discussion, we have revised the 
> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
> <https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/>.
>  
>  
> In particular, 
> For App Servers using IPv6, the OSPFv3 Extended LSA with the 
> Intra-Area-Prefix Address TLV specified by the Section 3.7 of RFC8362 can be 
> used to carry the App-Metrics for the attached App Servers.  
>   0   1   2   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |7 (IPv6 Local-Local Address)   |   Length  |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |IPv6 AppServer (ANYCAST) address   |
> ~   ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Load measurement sub-TLV    <>|
> ~   ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Capability sub-TLV |
> ~   ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Preference sub-TLV|
> ~   ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>Figure 3:  <>IPv6 App Server App-Metrics Encoding
>  
> For App Servers using IPv4 addresses, the OSPFv2 Extended Prefix Opaque LSA 
> with the extended Prefix TLV can be used to carry the App Metrics sub-TLVs, 
> as specified by the Section 2.1 [RFC7684].
>  
> Here is the proposed encoding:
>  
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type  | Length|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Route Type| Prefix Length | AF| Flags |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Address Prefix (variable) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> | Load Measurement Sub-TLV  |
> ~   ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> | capacity Index Sub-TLV|
> ~   ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> | Site Preference Sub-TLV   |
> ~   ~ 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>  
>  
> Your comments and suggestions are greatly appreciated. 
>  
> Linda Dunbar
>  
> From: Acee Lindem (acee) mailto:a...@cisco.com>> 
> Sent: Tuesday, November 3, 2020 1:38 PM
> To: Linda Dunbar  <mailto:linda.dun...@futurewei.com>>; Yingzhen Qu  <mailto:yingzhen.i...@gmail.com>>;lsr@ietf.org <mailto:lsr@ietf.org>; 
> lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>
> Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
> Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
>  
> We have a pretty full schedule and we add you as optional. I took a look at 
> the draft and it is all over the place right now with standardization 
> requested for one solution but 3 separate solutions partially specified. It 
> could benefit from some WG mailing list discussion prior to a 10 minute 
> presentation where we wouldn’t have time to discuss the many issues.
>  
> One major issue is that you should be extending RFC 7684 rather than RFC 3630 
> and it seems you these app-server selection metrics should be associated with 
> a prefix and

[Lsr] Fwd: New Version Notification for draft-acee-lsr-ospf-transport-instance-02.txt

[Yingzhen Qu]

Hi,

We submitted a new version of this draft with detailed OSPFv2 and OSPFv3 
encodings. Please review and send your comments.

Thanks,
Yingzhen

> 
> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>
> Sent: Sunday, February 21, 2021 11:21 AM
> To: Abhay Roy mailto:ab...@arrcus.com>>; Acee Lindem 
> mailto:a...@cisco.com>>; Sina Mirtorabi  <mailto:smirt...@cisco.com>>; Yingzhen Qu  <mailto:yingzhen...@futurewei.com>>
> Subject: New Version Notification for 
> draft-acee-lsr-ospf-transport-instance-02.txt
>  
> 
> A new version of I-D, draft-acee-lsr-ospf-transport-instance-02.txt
> has been successfully submitted by Yingzhen Qu and posted to the
> IETF repository.
> 
> Name:   draft-acee-lsr-ospf-transport-instance
> Revision:   02
> Title:  OSPF Transport Instance Extensions
> Document date:  2021-02-19
> Group:  Individual Submission
> Pages:  14
> URL:   
> https://www.ietf.org/archive/id/draft-acee-lsr-ospf-transport-instance-02.txt 
> <https://www.ietf.org/archive/id/draft-acee-lsr-ospf-transport-instance-02.txt>
>  
> Status: 
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/ 
> <https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/> 
> Htmlized:  
> https://datatracker.ietf.org/doc/html/draft-acee-lsr-ospf-transport-instance 
> <https://datatracker.ietf.org/doc/html/draft-acee-lsr-ospf-transport-instance>
>  
> Diff:  
> https://www.ietf.org/rfcdiff?url2=draft-acee-lsr-ospf-transport-instance-02 
> <https://www.ietf.org/rfcdiff?url2=draft-acee-lsr-ospf-transport-instance-02> 
> 
> Abstract:
>OSPFv2 and OSPFv3 include a reliable flooding mechanism to
>disseminate routing topology and Traffic Engineering (TE) information
>within a routing domain.  Given the effectiveness of these
>mechanisms, it is convenient to envision using the same mechanism for
>dissemination of other types of information within the domain.
>However, burdening OSPF with this additional information will impact
>intra-domain routing convergence and possibly jeopardize the
>stability of the OSPF routing domain.  This document presents
>mechanism to relegate this ancillary information to a separate OSPF
>instance and minimize the impact.
> 
>   
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org 
> <http://tools.ietf.org/>.
> 
> The IETF Secretariat

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 110 LSR Presentation Slot Requests

[Yingzhen Qu]

Hi all,



We're now accepting agenda requests for the LSR Working Grouping meeting
IETF 110. Please send your requests to lsr-cha...@ietf.org with the
following information:

presentation title, draft name/link, speaker, and desired duration
(covering presentation and discussion).



LSR session is scheduled on Monday, March 8th, 17:00-19:00 UTC+1.

https://datatracker.ietf.org/meeting/110/agenda



Thanks,

Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03

[Yingzhen Qu]

Hi Tom,

We published the new version a while back, so just wondering whether you got a 
chance to review the changes? Please kindly let us know if you have other 
comments.

Thanks,
Yingzhen

On Jan 5, 2021, at 10:02 AM, Yingzhen Qu 
mailto:yingzhen...@futurewei.com>> wrote:

Hi Tom,

Thank you for your review and comments.

We’ll publish a new version to address your comments within a couple of days.

Thanks,
Yingzhen


On Jan 5, 2021, at 9:04 AM, tom petch 
mailto:ie...@btconnect.com>> wrote:

From: Christian Hopps
Sent: Tuesday, January 05, 2021 16:54
> On Jan 5, 2021, at 11:47 AM, tom petch 
> mailto:ie...@btconnect.com>> wrote:
>
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Christian Hopps mailto:cho...@chopps.org>>
> Sent: 05 January 2021 09:19
>
> This begins a 2 week WG adoption call for the following draft:
>
>  
> https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-isis-yang-augmentation-v1%2F=04%7C01%7Cyingzhen.qu%40futurewei.com%7C2a746233cc21444a04b608d8b1a4393e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454666271945908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=P6mbsiz6uADWt%2FafxPcjh6ADttVUFNycty982MKy3AM%3D=0>
>
> Please indicate your support or objection by January 19th, 2021.
>
> 
>
> Object, strongly.
>
> In an earlier version, there was one YANG module and the accompanying text 
> related to that module.
>
> A second YANG module has been dropped into the I-D while the text is 
> untouched.  Thus
> the Abstract is wrong
> the Introduction is wrong
> IANA Considerations  are wrong
> and so on.
>
> This second module lacks references while introducing technical objects such 
> as udabm-length or r-flag with no indication where in the 68 documents 
> credited to the LSR WG (plus those of ISO) information may be found to judge 
> whether or not the YANG is suitable.
>
> The security considerations is out-of-date, the references do not reflect RFC 
> published last year, YANG import lack references, the key references are 
> listed as Informative.
>
> And, contrary to the announcement, the intended status of the I-D is  
> Informational.
>
> I am surprised that anyone should consider this to be in a state fit for 
> adoption!

Adoption just means the WG is willing to take on the work. It does not imply 
that the work is done or even close to being done.

That said thanks for pointing out work that needs to be done prior to 
considering a WGLC on this document. :)


Chris,

as you doubtless realise, I am saying that this version is not ready for 
adoption.  Intended status Informational?  That to me is a show-stopper (even 
if you do not consider the misleading Abstract and so on to be - which I do!)

Tom Petch


Thanks,
Chris.

>
> Tom Petch
>
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris.
>

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03

[Yingzhen Qu]

Speaking as co-author, I am not aware of any IPR on the draft.

Thanks,
Yingzhen

> On Jan 5, 2021, at 6:50 AM, Acee Lindem (acee) 
>  wrote:
> 
> Speaking as co-author:
> 
> I am not aware of any undisclosed IPR. 
> Thanks,
> Acee
> 
> On 1/5/21, 4:20 AM, "Christian Hopps"  wrote:
> 
>This begins a 2 week WG adoption call for the following draft:
> 
>  
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-isis-yang-augmentation-v1%2Fdata=04%7C01%7Cyingzhen.qu%40futurewei.com%7C681a90865bfe47cb433b08d8b1896f31%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454551139457297%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0bMg%2F5y2IQPiHFfT%2BfYih2dUYs0wwREDA0yIEpi3p3g%3Dreserved=0
> 
>Please indicate your support or objection by January 19th, 2021.
> 
>Authors, please respond to the list indicating whether you are aware of 
> any IPR that applies to this draft.
> 
>Thanks,
>Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Cyingzhen.qu%40futurewei.com%7C681a90865bfe47cb433b08d8b1896f31%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454551139467290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Ms2B%2F5HdJLENjUx6kyOdo2LSW57lg9rXV1iNNB%2FbE64%3Dreserved=0

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03

[Yingzhen Qu]

Hi Tom,

Thank you for your review and comments.

We’ll publish a new version to address your comments within a couple of days.

Thanks,
Yingzhen


On Jan 5, 2021, at 9:04 AM, tom petch 
mailto:ie...@btconnect.com>> wrote:

From: Christian Hopps
Sent: Tuesday, January 05, 2021 16:54
> On Jan 5, 2021, at 11:47 AM, tom petch 
> mailto:ie...@btconnect.com>> wrote:
>
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Christian Hopps mailto:cho...@chopps.org>>
> Sent: 05 January 2021 09:19
>
> This begins a 2 week WG adoption call for the following draft:
>
>  
> https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/
>
> Please indicate your support or objection by January 19th, 2021.
>
> 
>
> Object, strongly.
>
> In an earlier version, there was one YANG module and the accompanying text 
> related to that module.
>
> A second YANG module has been dropped into the I-D while the text is 
> untouched.  Thus
> the Abstract is wrong
> the Introduction is wrong
> IANA Considerations  are wrong
> and so on.
>
> This second module lacks references while introducing technical objects such 
> as udabm-length or r-flag with no indication where in the 68 documents 
> credited to the LSR WG (plus those of ISO) information may be found to judge 
> whether or not the YANG is suitable.
>
> The security considerations is out-of-date, the references do not reflect RFC 
> published last year, YANG import lack references, the key references are 
> listed as Informative.
>
> And, contrary to the announcement, the intended status of the I-D is  
> Informational.
>
> I am surprised that anyone should consider this to be in a state fit for 
> adoption!

Adoption just means the WG is willing to take on the work. It does not imply 
that the work is done or even close to being done.

That said thanks for pointing out work that needs to be done prior to 
considering a WGLC on this document. :)


Chris,

as you doubtless realise, I am saying that this version is not ready for 
adoption.  Intended status Informational?  That to me is a show-stopper (even 
if you do not consider the misleading Abstract and so on to be - which I do!)

Tom Petch


Thanks,
Chris.

>
> Tom Petch
>
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris.
>

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Yingzhen Qu]

I have read the draft and support its adoption.

Thanks,
Yingzhen

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Wednesday, December 2, 2020 at 9:49 AM
To: "Acee Lindem (acee)" , lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Resent-From: 
Resent-Date: Wednesday, December 2, 2020 at 9:49 AM

Speaking as WG member:

I have read this draft and support adoption.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, December 1, 2020 at 4:13 PM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

[Yingzhen Qu]

I have reviewed the draft and support progressing this document.

A couple of nits in the abstract:
   This document defines a YANG module for managing the reverse metric
   extension to the the intermediate system to intermediate system
   routeing|routing protocol.

Thanks,
Yingzhen

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Tuesday, December 1, 2020 at 3:46 PM
To: "Acee Lindem (acee)" , "lsr@ietf.org" 

Subject: Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse 
Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01
Resent-From: 
Resent-Date: Tuesday, December 1, 2020 at 3:45 PM

I have reviewed the draft and support progressing this document.

   Les

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Monday, November 30, 2020 10:15 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse 
Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric 
augmentation is ready for publication. This begins a two week last call for the 
subject draft. Please indicate your support or objection on this list prior to 
12:00 AM UTC on December 15th, 2020. Also, review comments are certainly 
welcome.
Thanks,
Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

[Yingzhen Qu]

Hi Aijun,

Please see my response below inline.

Thanks,
Yingzhen

From: Aijun Wang 
Date: Wednesday, November 18, 2020 at 6:27 PM
To: Yingzhen Qu , "'Acee Lindem (acee)'" 

Cc: 'lsr' 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt

Hi, Yingzhen:

Please see whether the replies below inline can solve your concerns or not.

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org  On Behalf Of Yingzhen Qu
Sent: Wednesday, November 18, 2020 8:57 PM
To: Aijun Wang ; 'Acee Lindem (acee)' 

Cc: 'lsr' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt

Hi Aijun,


[WAJ] In your 109 meeting presentation 
slides-109-lsr-5-ospf-transport-instance-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fslides-109-lsr-5-ospf-transport-instance-00=04%7C01%7Cyingzhen.qu%40futurewei.com%7C74ad191b60404efd872b08d88c32b130%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637413496658792571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0zEyN2fX7sFk9H1yDe06BiCmZEQigkS2tlEDAtsC7qU%3D=0>,
 you mentioned also the similar information that should be transferred via the 
OSPF protocol. I think this is the direction and we can prepare for it in 
advance. Putting such non-routing information in one independent TLV can 
certainly keep the stability of IGP protocol.

Just to respond this comment here. The purpose of OSPF transport instance is to 
carry non-routing information for applications without impacting routing 
calculation and convergence. When you say “this is the direction”, do you mean 
using OSPF transport instance to carry application data or to use base OSPF 
instance?
[WAJ] use base OSPF instance is better. I think the reason to advertise the 
server info via IGP protocol is to let the router select the right path to 
server.

[Yingzhen]: The path calculation to servers is done in the base instance. 
Transport instance doesn’t do or impact base instance path calculation.

Also how putting such non-routing information in one independent TLV can keep 
the stability of IGP protocol?
[WAJ] The router can easily recognize such info when it do SPF calculation, 
skip some steps(for example, topology calculation) then.
And, considering the interface that connects the server to the router is always 
passive, would you like to put these info into Stub-Link TLV that defined in 
the passive interface draft?

[Yingzhen]: It’s not only about route computing, you will need to flood all the 
application information.

Depending on the application, this kind of information may need to be updated 
very often, for example CPU usage, and this will certainly have some impacts. 
Especially when there more applications and each of them needs to be updated at 
different intervals and frequencies.
[WAJ] They should all meet the minimum threshold, as also mentioned in Acee’s 
presentation file.

[Yingzhen]: We considered scalability issues and ways for mitigation, but I 
don’t think it was discussed it in your draft. Please let me know if I missed 
it. Also it’s not a good idea to mix flooding application information together 
with routing information.

Thanks,
Yingzhen

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Tuesday, November 17, 2020 at 11:06 PM
To: "'Acee Lindem (acee)'" mailto:a...@cisco.com>>
Cc: 'lsr' mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt
Resent-From: mailto:yingzhen...@huawei.com>>
Resent-Date: Tuesday, November 17, 2020 at 11:06 PM

Hi, Acee:

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, November 18, 2020 12:39 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: 'lsr' mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: 'lsr' mailto:lsr@ietf.org>>
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt


Hi, Acee:



-Original Message-
From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang mailto:wang...@chinatelecom.cn>>
Cc: 'lsr' mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt



Speaking as WG member and longtime steward  of the IGPs:



Hi Aijun,



My opinion is that we should not overload the base IGP topology advertisements 
with everyone's favorite obscure use case. Hence, I 

Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

[Yingzhen Qu]

Hi Aijun,


[WAJ] In your 109 meeting presentation 
slides-109-lsr-5-ospf-transport-instance-00,
 you mentioned also the similar information that should be transferred via the 
OSPF protocol. I think this is the direction and we can prepare for it in 
advance. Putting such non-routing information in one independent TLV can 
certainly keep the stability of IGP protocol.

Just to respond this comment here. The purpose of OSPF transport instance is to 
carry non-routing information for applications without impacting routing 
calculation and convergence. When you say “this is the direction”, do you mean 
using OSPF transport instance to carry application data or to use base OSPF 
instance? Also how putting such non-routing information in one independent TLV 
can keep the stability of IGP protocol? Depending on the application, this kind 
of information may need to be updated very often, for example CPU usage, and 
this will certainly have some impacts. Especially when there more applications 
and each of them needs to be updated at different intervals and frequencies.

Thanks,
Yingzhen

From: Lsr  on behalf of Aijun Wang 

Date: Tuesday, November 17, 2020 at 11:06 PM
To: "'Acee Lindem (acee)'" 
Cc: 'lsr' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt
Resent-From: 
Resent-Date: Tuesday, November 17, 2020 at 11:06 PM

Hi, Acee:

From: Acee Lindem (acee) 
Sent: Wednesday, November 18, 2020 12:39 PM
To: Aijun Wang 
Cc: 'lsr' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: 'lsr' mailto:lsr@ietf.org>>
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt


Hi, Acee:



-Original Message-
From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang mailto:wang...@chinatelecom.cn>>
Cc: 'lsr' mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt



Speaking as WG member and longtime steward  of the IGPs:



Hi Aijun,



My opinion is that we should not overload the base IGP topology advertisements 
with everyone's favorite obscure use case. Hence, I think it would be a big 
mistake to add this stub link TLV to the base LSAs.

[WAJ] Putting the information in other regular TLVs, or putting them in LSA of 
one independent IGP instance(as you proposed in 109 meeting) will be more 
expensive. Do you agree this statement?



No – bloating the primary LSAs with non-routing information will be more 
expensive due to the dynamics of LSA origination and route computation.

[WAJ] what’s your recommendation then? The router can skip such information 
when they do SPF calculation, just need only add the information to the 
attached leaf router when the computation is completed. The LSA update is 
periodic and event driven. Advertising such information in a controlled manner 
does not deteriorate the flooding status.



Rather, exactly what problem are you trying to solve? Previously, you were 
trying to associate the passive interface attribute with a prefix and making 
some inference related to an inter-AS boundary (this was not entirely clear). 
What problem are you trying to solve? Precisely, what do you want the 
controller to learn (i.e., address or interface index) and what is it going to 
do with it.

[WAJ] Passive Interfaces are already deployed within the network in many 
places, as stated in the 
draft-wang-lsr-passive-interface-attribute-06#section-1.
 What we want to know, is the position of passive interface. Previously, we 
want piggyback such information within its associated prefix, but after 
discussion on the mail list, define one new TLV to contain it and other future 
information may be more acceptable and extensible.



And how do identify and even 

[Lsr] Draft LSR IETF 109 Agenda Available

[Yingzhen Qu]

Hi all,

The draft agenda for LSR meeting is available at:
https://www.ietf.org/proceedings/109/agenda/agenda-109-lsr-01.html

Please take a look and let us know if you have any questions or if we
have missed anything.

Presenters:

Please send your slides to lsr-cha...@ietf.org no later than the Friday
before our meeting.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

[Yingzhen Qu]

I support the adoption of this draft. It’s a simple and useful extension.

Thanks,
Yingzhen

From: Lsr 
Date: Sunday, October 25, 2020 at 7:03 PM
To: Acee Lindem (acee) , lsr@ietf.org 

Subject: Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS 
MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02
As one of co-authors of the draft, I support the adoption.

Best regards,
Mach

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, October 23, 2020 10:43 PM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS 
MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS TE 
in IPv6 only networks. The authors have asked for WG adoption.

This begins a two week LSR Working Group Adoption Poll for “ISIS Extensions in 
Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering” - 
draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 AM UTC on 
November 7th, 2020. Please indicate your support of objection on this list 
prior to the end of the adoption poll.

Thanks,
Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 109 LSR Presentation Slot Requests

[Yingzhen Qu]

Hi all,



We're now accepting agenda requests for the LSR Working Grouping meeting
IETF 109. Please send your requests to lsr-cha...@ietf.org indicating draft
name, speaker, and desired duration (covering presentation and discussion).



LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT.



Thanks,

Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr