Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Les Ginsberg (ginsberg)]

Chongfeng –

We are at the stage of last call.
The document has been presented and discussed previously – it is time for WG 
members to render their opinions.

For folks who have actively followed/participated in the discussion, it is very 
unlikely that we will alter opinions by further discussion. Which means if you 
and I have different points of view it is very unlikely that I will alter your 
opinion and very unlikely that you will alter mine.
In that context, I typically do not reply when someone posts their opinion and 
it is different than mine. The point of last call is to get the opinions of WG 
members.

In this case, however, I will respond with some clarifications – not in the 
hopes of changing your mind – but only to provide additional clarity as to why 
I have the opinion that I do.

The use of MT in support of NRP – at whatever scale – clearly requires 
additional SPF calculations – which is something which is expressly identified 
as undesirable in draft-ietf-teas-nrp-scalability.
draft-ietf-teas-nrp-scalability also states (as you have pointed out) that 
“control plane extensions” are seen as undesirable.

Having implemented the use of MT for purposes other than supporting the 
reserved AFI/SAFI specific topologies specified in RFC 5120, I can tell you 
that there is a significant amount of “control plane work” associated with 
adding such support. The fact that no new protocol extensions are required is 
not the same as saying no new control plane work is required. I can assure you 
that there would be a significant amount of control plane work required.

So I do see that draft-ietf-lsr-isis-sr-vtn-mt is at odds with 
draft-ietf-teas-nrp-scalability.

Thanx for listening.

Les


From: Lsr  On Behalf Of Chongfeng Xie
Sent: Wednesday, January 10, 2024 7:41 PM
To: Les Ginsberg (ginsberg) ; jmh 
; Acee Lindem ; TEAS WG 
; lsr 
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06


Hi Les,

Thanks for your comments.

This is an informational document which describes the applicability of existing 
IS-IS MT mechanisms for building SR based NRPs. All the normative references 
are either RFCs or stable WG documents. It is true that some informative 
references are individual documents, while they just provide additional 
information related to this topic, thus would not impact the stability and 
maturity of the proposed mechanism.

The text you quoted from draft-ietf-teas-nrp-scalability are about the 
considerations when the number of NRP increases, how to minimize the impact to 
the routing protocols (e.g. IGP). While as described in the scalability 
considerations section of this document, the benefit and limitation of using 
this mechanism for NRP are analyzed, and it also sets the target scenarios of 
this mechanism:

 “The mechanism described in this document is considered useful for network 
scenarios in which the required number of NRP is small”

Thus it is clear that this solution is not recommended for network scenarios 
where the number of required NRP is large.

Please note section 3 of draft-ietf-teas-nrp-scalability also mentioned that:

  “The result of this is that different operators can choose to deploy 
things at different scales.”

And

  “In particular, we should be open to the use of approaches that do not 
require control plane extensions and that can be applied to deployments with 
limited scope.”

 According to the above text, we believe the mechanism described in this 
document complies to the design principles discussed in 
draft-ietf-teas-nrp-scalability and provides a valid solution for building NRPs 
in a limited scope.

 Hope this solves your concerns about the maturity and scalability of this 
mechanism.

 Best regards,

Chongfeng


From: Les Ginsberg \(ginsberg\)
Date: 2024-01-11 08:21
To: Joel Halpern; Acee 
Lindem; t...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
(NOTE: I am replying to Joel’s post rather than the original last call email 
because I share some of Joel’s concerns – though my opinion on the merits of 
the draft is very different.
Also, I want to be sure the TEAS WG gets to see this email.)

I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt.

It is certainly true, as Joel points out, that this draft references many 
drafts which are not yet RFCs – and in some cases are not even WG documents. 
Therefore, it is definitely premature to last call this draft.

I also want to point out that the direction TEAS WG has moved to recommends 
that routing protocols NOT be used 

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

[Wei Wang]

Hi all,


  I support the adoption of this draft.
  This solution is useful for the transmission of the information 
of stub link, which enables BGP-LS to not only collect the topology information 
of individual ASes, but also collect the connection information between 
different ASes. And this mechanism may make it easier for the controller to 
obtain the global network topology.




Best Regards,
Wei


-- Original --
From:   
 "Yingzhen Qu"  
  
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

[Lsr] [Technical Errata Reported] RFC2328 (7757)

[RFC Errata System]

The following errata report has been submitted for RFC2328,
"OSPF Version 2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7757

--
Type: Technical
Reported by: Lokesh Venkata Kumar Chakka 

Section: A.4.5

Original Text
-
Forwarding address
Data traffic for the advertised destination will be forwarded to this address. 
If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded 
instead to the LSA's originator (i.e., the responsible AS boundary router).

Corrected Text
--
Forwarding address
Data traffic for the advertised destination will be forwarded to this address. 
If the Forwarding address is set to a Router ID address value other than 
0.0.0.0, data traffic will be forwarded to that Router instead to the LSA's 
originator (i.e., the responsible AS boundary router).

Notes
-
Data traffic destined to the network indicated by Link State ID will be routed 
to that Router ID mentioned in forwarding address. If forwarding address is set 
to 0.0.0.0, it will be forwarded to LSA Originator itself.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC2328 (no draft string recorded)
--
Title   : OSPF Version 2
Publication Date: April 1998
Author(s)   : J. Moy
Category: INTERNET STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

[Lsr] 答复: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Xuguoqi]

Hi,

  Support, I've read this document and support its publication.  It is 
reasonable to reuse MT for NRPs to meet the requirements in some network 
scenarios.

Best regard

Guoqi

-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2024年1月9日 06:50
收件人: Lsr 
主题: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology 
(MT) for Segment Routing based Network Resource Partition (NRP)" - 
draft-ietf-lsr-isis-sr-vtn-mt-06

This begins a two week LSR Working Group last call for the “Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)”. Please express your support or objection prior to Tuesday, January 
23rd, 2024. 

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] [Editorial Errata Reported] RFC2328 (7756)

[RFC Errata System]

The following errata report has been submitted for RFC2328,
"OSPF Version 2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7756

--
Type: Editorial
Reported by: Lokesh Venkata Kumar Chakka 

Section: A.4.5

Original Text
-
AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary 
routers, and describe destinations external to the AS. For details concerning 
the construction of AS-external-LSAs, see Section 12.4.3

Corrected Text
--
AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary 
routers, and describe destinations external to the AS. For details concerning 
the construction of AS-external-LSAs, see Section 12.4.4

Notes
-
Incorrect references. Construction of AS-external-LSAs explained in Section 
12.4.4. Not in 12.4.3

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC2328 (no draft string recorded)
--
Title   : OSPF Version 2
Publication Date: April 1998
Author(s)   : J. Moy
Category: INTERNET STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Chongfeng Xie]

Hi Les,

Thanks for your comments.

This is an informational document which describes the applicability of existing 
IS-IS MT mechanisms for building SR based NRPs. All the normative references 
are either RFCs or stable WG documents. It is true that some informative 
references are individual documents, while they just provide additional 
information related to this topic, thus would not impact the stability and 
maturity of the proposed mechanism.

The text you quoted from draft-ietf-teas-nrp-scalability are about the 
considerations when the number of NRP increases, how to minimize the impact to 
the routing protocols (e.g. IGP). While as described in the scalability 
considerations section of this document, the benefit and limitation of using 
this mechanism for NRP are analyzed, and it also sets the target scenarios of 
this mechanism:

 “The mechanism described in this document is considered useful for network 
scenarios in which the required number of NRP is small”

Thus it is clear that this solution is not recommended for network scenarios 
where the number of required NRP is large.

Please note section 3 of draft-ietf-teas-nrp-scalability also mentioned that:

  “The result of this is that different operators can choose to deploy 
things at different scales.”

And

  “In particular, we should be open to the use of approaches that do not 
require control plane extensions and that can be applied to deployments with 
limited scope.”

 According to the above text, we believe the mechanism described in this 
document complies to the design principles discussed in 
draft-ietf-teas-nrp-scalability and provides a valid solution for building NRPs 
in a limited scope.

 Hope this solves your concerns about the maturity and scalability of this 
mechanism.

 Best regards,

Chongfeng

 
From: Les Ginsberg \(ginsberg\)
Date: 2024-01-11 08:21
To: Joel Halpern; Acee Lindem; t...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
(NOTE: I am replying to Joel’s post rather than the original last call email 
because I share some of Joel’s concerns – though my opinion on the merits of 
the draft is very different.
Also, I want to be sure the TEAS WG gets to see this email.)
 
I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt.
 
It is certainly true, as Joel points out, that this draft references many 
drafts which are not yet RFCs – and in some cases are not even WG documents. 
Therefore, it is definitely premature to last call this draft.
 
I also want to point out that the direction TEAS WG has moved to recommends 
that routing protocols NOT be used as a means of supporting NRP. 
 
https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl
 states:
 
“…it is desirable for NRPs to have no more than small impact (zero being 
preferred) on the IGP information that is propagated today, and to not required 
additional SPF computations beyond those that are already required.”
 
https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl
 states:
 
“The routing protocols (IGP or BGP) do not need to be involved in any of these 
points, and it is important to isolate them from these aspects in order that 
there is no impact on scaling or stability.”
 
Another draft which is referenced is 
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ - which is not 
a WG document and – based on the recommendations in 
draft-ietf-teas-nrp-scalability – I would argue that the IGPs should NOT be 
extended as proposed in this draft. So if a WG adoption call were to initiated 
for draft-dong-lsr-sr-enhanced-vpn, I would oppose it.
 
This then puts draft-ietf-lsr-isis-sr-vtn-mt in the position of publishing 
information about a solution which the IETF is discouraging. I do not know why 
the IETF would want to do this.
 
If, despite all of the above, at some point it is judged not premature to 
publish this draft, I think the draft should at least include statements 
indicating that this approach is not a recommended deployment solution.
 
   Les
 
 
From: Lsr  On Behalf Of Joel Halpern
Sent: Wednesday, January 10, 2024 3:22 PM
To: Acee Lindem ; t...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
 
Given that the documents that provide the basic definitions needed for this are 
still active Internet Drafts, it seems premature to last call this document.
As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, 
which defines the terms needed to understand this draft, is an Informative 
reference.
Yours,
Joel
PS: I considered not writing this email, as it seems 

[Lsr] 答复: IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)"

[Lizhenbin]

Hi All,

No, I'm not aware of any IPR regarding this document.

Best regards,
Zhenbin (Robin)



-邮件原件-
发件人: Acee Lindem  
发送时间: 2024年1月9日 6:43
收件人: draft-ietf-lsr-isis-sr-vtn...@ietf.org
抄送: Lsr 
主题: IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology (MT) 
for Segment Routing based Network Resource Partition (NRP)"

Co-Authors, 

Are you aware of any IPR that applies to draft-ietf-lsr-isis-sr-vtn-mt-06.
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).
 
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 been disclosed in conformance with IETF rules.

Thanks,
Acee

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

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Chongfeng Xie]

Hi Joel,

Thanks for your comments. It is good to know you also think using MT to support 
NRP is a good idea.

Regarding the timing of the last call, the enhanced VPN framework draft has 
finished the WG LC in TEAS WG, and this document has been stable for quite a 
while, thus it seems now is the right time to last call this document in LSR WG.

As for the reference to draft-ietf-teas-ietf-network-slices, I agree after the 
terminology alignment it is better to be listed as normative reference. We can 
make this change in next revision.

Best regards,

Chongfeng

From: Joel Halpern
Date: 2024-01-11 07:22
To: Acee Lindem; teas; lsr
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Given that the documents that provide the basic definitions needed for this are 
still active Internet Drafts, it seems premature to last call this document.
As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, 
which defines the terms needed to understand this draft, is an Informative 
reference.
Yours,
Joel
PS: I considered not writing this email, as it seems quite reasonable to use MT 
to support what I expect NRPs to be.  So in principle I think the document is a 
good idea.
On 1/10/2024 6:12 PM, Acee Lindem wrote:
Note that we are last calling this informational document relating to IS-IS 
deployment of NRPs using multi-topology. If you have comments, please send them 
to the LSR list.  

Thanks,
Acee

Begin forwarded message:

From: Acee Lindem 
Subject: Working Group Last Call for "Applicability of IS-IS Multi-Topology 
(MT) for Segment Routing based Network Resource Partition (NRP)" - 
draft-ietf-lsr-isis-sr-vtn-mt-06
Date: January 8, 2024 at 5:50:21 PM EST
To: Lsr 

This begins a two week LSR Working Group last call for the “Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)”. Please express your support or objection prior to Tuesday, January 
23rd, 2024. 

Thanks,
Acee


___
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] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Chris:

For the use case A.1(inter-as topology recovery), RFC9346/RFC5392 based 
solution requires the prerequisite knowledge of remote identifier on each stub 
link. Considering there maybe tens/hundreds of links among the ASBRs, there is 
no easy way to get such information automatically now.

And, there are situations that the stub links are not the inter-as link【use 
case A.2(Egress Engineering for Anycast Servers)]】, which is not suitable to 
reuse the RFC9346/RFC5392 based solution.

Then, it is necessary to extend the protocol to solve the above scenarios in 
one general manner.

Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Christian Hopps
发送时间: 2024年1月10日 18:17
收件人: 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)

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

[As WG Member]

  To repeat from the first failed adoption call...

  "Reducing configuraiton" is not a reason to modify the
  routing protocols. Operators aren't doing by-hand manual
  configuration, and even if they were we shouldn't be
  trying to support it in this day and age.

Thanks,
Chris.

Huzhibo  writes:

> Hi Acee:
>
>
>
>   You're right, there are alternatives to address inter-domain 
> link advertisements, and this document attempts to address such issues 
> in a more simplified way, reducing the number of BGP-LS sessions 
> required, or avoid the configurations related to the peering AS 
> domains as required by RFC 9346. Do you have any suggestions for the 
> problems this article is trying to solve?



>
>
>
> Thanks
>
> Zhibo Hu
>
>
>
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> Sent: Tuesday, January 9, 2024 3:03 AM
> To: Yingzhen Qu 
> Cc: lsr 
> Subject: Re: [Lsr] WG Adoption Call -
> draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
>
>
>
> Speaking as WG member:
>
>
>
> I don’t support adoption of this draft.
>
>
>
> First of all, I think the basic premise of the draft is flawed in that 
> a link is advertised as a stub and, from that, one can deduce uses of 
> the link. Why not just advertise what is being deduced?
>
>
>
> Second, I don’t think the draft is necessary. The use case in A.1 is 
> solely for an IGP router to advertise this stub link characteristic to 
> a controller for inter-AS TE. Since it is only for the controller why 
> wouldn’t be BGP-LS be used? It seems this is how it ultimately gets to 
> the controller anyway. Furthermore, if it were to be put into the 
> IGPs, why wouldn’t something like RFC 9346 be used for inter-AS TE? 
> For the use case in A.2, anycast prefix advertisement is already 
> handled and documents exist to identify a prefix as an anycast 
> address. For the use case in A.3, I don’t even understand how it works 
> or what is supposed to happen between BGP and the IGPs? What is 
> different about this from normal BGP route recursion over the IGP 
> route? For this, the fact that it is a stub link is irrelevant.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
>
>
> On Jan 5, 2024, at 19:23, Yingzhen Qu 
> wrote:
>
>
>
> 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

___
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] 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] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-25.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-ospfv3-extended-lsa-yang-25.txt is now
available. It is a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   YANG Model for OSPFv3 Extended LSAs
   Authors: Acee Lindem
Sharmila Palani
Yingzhen Qu
   Name:draft-ietf-lsr-ospfv3-extended-lsa-yang-25.txt
   Pages:   29
   Dates:   2024-01-10

Abstract:

   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.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lsr-ospfv3-extended-lsa-yang-25.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-25

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

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Les Ginsberg (ginsberg)]

(NOTE: I am replying to Joel’s post rather than the original last call email 
because I share some of Joel’s concerns – though my opinion on the merits of 
the draft is very different.
Also, I want to be sure the TEAS WG gets to see this email.)

I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt.

It is certainly true, as Joel points out, that this draft references many 
drafts which are not yet RFCs – and in some cases are not even WG documents. 
Therefore, it is definitely premature to last call this draft.

I also want to point out that the direction TEAS WG has moved to recommends 
that routing protocols NOT be used as a means of supporting NRP.

https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl
 states:

“…it is desirable for NRPs to have no more than small impact (zero being 
preferred) on the IGP information that is propagated today, and to not required 
additional SPF computations beyond those that are already required.”

https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl
 states:

“The routing protocols (IGP or BGP) do not need to be involved in any of these 
points, and it is important to isolate them from these aspects in order that 
there is no impact on scaling or stability.”

Another draft which is referenced is 
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ - which is not 
a WG document and – based on the recommendations in 
draft-ietf-teas-nrp-scalability – I would argue that the IGPs should NOT be 
extended as proposed in this draft. So if a WG adoption call were to initiated 
for draft-dong-lsr-sr-enhanced-vpn, I would oppose it.

This then puts draft-ietf-lsr-isis-sr-vtn-mt in the position of publishing 
information about a solution which the IETF is discouraging. I do not know why 
the IETF would want to do this.

If, despite all of the above, at some point it is judged not premature to 
publish this draft, I think the draft should at least include statements 
indicating that this approach is not a recommended deployment solution.

   Les


From: Lsr  On Behalf Of Joel Halpern
Sent: Wednesday, January 10, 2024 3:22 PM
To: Acee Lindem ; t...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06


Given that the documents that provide the basic definitions needed for this are 
still active Internet Drafts, it seems premature to last call this document.

As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, 
which defines the terms needed to understand this draft, is an Informative 
reference.

Yours,

Joel

PS: I considered not writing this email, as it seems quite reasonable to use MT 
to support what I expect NRPs to be.  So in principle I think the document is a 
good idea.
On 1/10/2024 6:12 PM, Acee Lindem wrote:
Note that we are last calling this informational document relating to IS-IS 
deployment of NRPs using multi-topology. If you have comments, please send them 
to the LSR list.

Thanks,
Acee


Begin forwarded message:

From: Acee Lindem 
Subject: Working Group Last Call for "Applicability of IS-IS Multi-Topology 
(MT) for Segment Routing based Network Resource Partition (NRP)" - 
draft-ietf-lsr-isis-sr-vtn-mt-06
Date: January 8, 2024 at 5:50:21 PM EST
To: Lsr 

This begins a two week LSR Working Group last call for the “Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)”. Please express your support or objection prior to Tuesday, January 
23rd, 2024.

Thanks,
Acee




___

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

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Joel Halpern]

Given that the documents that provide the basic definitions needed for 
this are still active Internet Drafts, it seems premature to last call 
this document.


As a lesser matter, it seems odd that 
draft-ietf-teas-ietf-network-slices, which defines the terms needed to 
understand this draft, is an Informative reference.


Yours,

Joel

PS: I considered not writing this email, as it seems quite reasonable to 
use MT to support what I expect NRPs to be.  So in principle I think the 
document is a good idea.


On 1/10/2024 6:12 PM, Acee Lindem wrote:
Note that we are last calling this informational document relating to 
IS-IS deployment of NRPs using multi-topology. If you have comments, 
please send them to the LSR list.


Thanks,
Acee


Begin forwarded message:

*From: *Acee Lindem 
*Subject: **Working Group Last Call for "Applicability of IS-IS 
Multi-Topology (MT) for Segment Routing based Network Resource 
Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06*

*Date: *January 8, 2024 at 5:50:21 PM EST
*To: *Lsr 

This begins a two week LSR Working Group last call for the 
“Applicability of IS-IS Multi-Topology (MT) for Segment Routing based 
Network Resource Partition (NRP)”. Please express your support or 
objection prior to Tuesday, January 23rd, 2024.


Thanks,
Acee



___
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] AD review of draft-ietf-lsr-ospfv3-extended-lsa-yang

[John Scudder]

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

### Section 4

  /*
   * OSPFv3 Extend LSA Type Identities
   */

Shouldn't that be "Extended" not "Extend"?

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

"This may be undesirable since both due to the fact that exposure may 
facilitate other attacks." Probably, delete "since both".
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 8665 and 8666 in the datatracker

[Acee Lindem]

Hi Tom, 

The ticket I opened is now fixed and a datatracker search for say, “ospf-“ will 
display both RFCs and drafts (including RFC 8665 and RFC 8666). The datatracker 
has seemingly gone through some major changes and instability but seems to work 
well now. 

Thanks,
Acee

> On Jan 10, 2024, at 12:26, tom petch  wrote:
> 
> I commented last month that I thought that RFC8665 should be in the 
> datatracker pages for LSR WG; I was wrong.
> 
> I raised an issue and now understand that the date that counts is when the 
> I-D was submitted to the RFC Editor.  For this I-D, that was before the OSPF 
> WG was wound up so that although by the time of publication, LSR as well 
> underway, yet it remained an OSPF RFC.  Other RFC with seemingly similar 
> metadata did not join the RFC Editor Queue until after the LSR WG had come 
> into being and so have been regarded as LSR RFC and listed as such in the 
> datatracker.
> 
> Tom Petch
> ___
> 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] 8665 and 8666 in the datatracker

[tom petch]

I commented last month that I thought that RFC8665 should be in the datatracker 
pages for LSR WG; I was wrong.

I raised an issue and now understand that the date that counts is when the I-D 
was submitted to the RFC Editor.  For this I-D, that was before the OSPF WG was 
wound up so that although by the time of publication, LSR as well underway, yet 
it remained an OSPF RFC.  Other RFC with seemingly similar metadata did not 
join the RFC Editor Queue until after the LSR WG had come into being and so 
have been regarded as LSR RFC and listed as such in the datatracker.

Tom Petch
___
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)

[Christian Hopps]

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

[As WG Member]

 To repeat from the first failed adoption call...

 "Reducing configuraiton" is not a reason to modify the
 routing protocols. Operators aren't doing by-hand manual
 configuration, and even if they were we shouldn't be
 trying to support it in this day and age.

Thanks,
Chris.

Huzhibo  writes:


Hi Acee:



  You're right, there are alternatives to address inter-domain
link advertisements, and this document attempts to address such
issues in a more simplified way, reducing the number of BGP-LS
sessions required, or avoid the configurations related to the peering
AS domains as required by RFC 9346. Do you have any suggestions for
the problems this article is trying to solve?








Thanks

Zhibo Hu



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
Sent: Tuesday, January 9, 2024 3:03 AM
To: Yingzhen Qu 
Cc: lsr 
Subject: Re: [Lsr] WG Adoption Call -
draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)



Speaking as WG member:



I don’t support adoption of this draft.



First of all, I think the basic premise of the draft is flawed in
that a link is advertised as a stub and, from that, one can deduce
uses of the link. Why not just advertise what is being deduced?



Second, I don’t think the draft is necessary. The use case in A.1 is
solely for an IGP router to advertise this stub link characteristic
to a controller for inter-AS TE. Since it is only for the controller
why wouldn’t be BGP-LS be used? It seems this is how it ultimately
gets to the controller anyway. Furthermore, if it were to be put into
the IGPs, why wouldn’t something like RFC 9346 be used for inter-AS
TE? For the use case in A.2, anycast prefix advertisement is already
handled and documents exist to identify a prefix as an anycast
address. For the use case in A.3, I don’t even understand how it
works or what is supposed to happen between BGP and the IGPs? What is
different about this from normal BGP route recursion over the IGP
route? For this, the fact that it is a stub link is irrelevant.



Thanks,

Acee









On Jan 5, 2024, at 19:23, Yingzhen Qu 
wrote:



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


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

[Huzhibo]

Hi Acee:

  You're right, there are alternatives to address inter-domain link 
advertisements, and this document attempts to address such issues in a more 
simplified way, reducing the number of BGP-LS sessions required, or avoid the 
configurations related to the peering AS domains as required by RFC 9346. Do 
you have any suggestions for the problems this article is trying to solve?

Thanks
Zhibo Hu

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
Sent: Tuesday, January 9, 2024 3:03 AM
To: Yingzhen Qu 
Cc: lsr 
Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Speaking as WG member:

I don’t support adoption of this draft.

First of all, I think the basic premise of the draft is flawed in that a link 
is advertised as a stub and, from that, one can deduce uses of the link. Why 
not just advertise what is being deduced?

Second, I don’t think the draft is necessary. The use case in A.1 is solely for 
an IGP router to advertise this stub link characteristic to a controller for 
inter-AS TE. Since it is only for the controller why wouldn’t be BGP-LS be 
used? It seems this is how it ultimately gets to the controller anyway. 
Furthermore, if it were to be put into the IGPs, why wouldn’t something like 
RFC 9346 be used for inter-AS TE? For the use case in A.2, anycast prefix 
advertisement is already handled and documents exist to identify a prefix as an 
anycast address. For the use case in A.3, I don’t even understand how it works 
or what is supposed to happen between BGP and the IGPs? What is different about 
this from normal BGP route recursion over the IGP route? For this, the fact 
that it is a stub link is irrelevant.

Thanks,
Acee




On Jan 5, 2024, at 19:23, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

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