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

[Aijun Wang]

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 broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There are multiple neighbors on one interfaces, which are located in different AS. How to encode the information within one inter-AS reachability TLV? 2)	How the inter-AS based solutions solve the non inter-AS scenario requirements(A.2)?One point that I want to remind for your misunderstanding: the proposed Stub-link TLV can contain other attributes sub-TLVs of the link.And, if the interfaces share the same prefixes, they are in the same IP subnet. Is there any ambiguously for the IP topology recovery?What I want to emphasize is that the existing solutions are suitable for inter-AS point-to-point TE, the proposed solutions are suitable(more efficient)for inter-AS topology recovery(p2p, p2mp and broadcast etc.) and also other non inter-as traffic optimization scenarios.  They are not contrary. Aijun WangChina TelecomOn Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg)  wrote:







Aijun –
 
Please see inline.
 



From: Aijun Wang 

Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps' ; 'Huzhibo' 
Cc: 'Acee Lindem' ; 'Yingzhen Qu' ; 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月16日 0:16
收件人: 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)
 
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.
[WAJ] Current encoding has covered the unnumbered scenario. For Pt-2-MP scenario, they share also the same subnet, please see our previous discussion at

https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/
 
[LES:] I have no idea why you think the email you point to resolved the issue. It was an early email in a very long thread, the lack of support for unnumbered etc. continued to be discussed in subsequent
 emails by multiple participants and has been raised again by multiple participants in this second adoption call thread.
The minor changes you made to the encoding of Stub Link advertisement does nothing to resolve the issue.
The fundamental issue is that the same prefix can be associated with multiple links, so what you have defined is ambiguous in some cases.
Either you don’t understand this or don’t think this is important – I am not sure which – but many of us do believe this is important.
 
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.
[WAJ] If you make such claims, then please give the encoding example for A.1 Figures 2(LAN scenario). How to configure/encode the several neighbors that located in different AS in one inter-AS reachability
 TLV? 
 
[LES:] RFC 9346/RFC 5362 provide a robust way to uniquely identify inter-AS links, verify two-way connectivity, and optionally advertise additional link attributes if desired. (Apply this portion
 of the response to your other comments below.)
You apparently think this is too onerous and you propose a different mechanism that isn’t robust, does not allow two-way connectivity verification, and doesn’t support link attribute advertisement.
But because you see it as “simpler” you think you have sufficient justification to overlook its flaws.
I don’t agree.
 
The long-lived success of the IGPs has happened because we have worked diligently to provide robust solutions – not settle for solutions that only work some of the time.
 
 

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

[internet-drafts]

Internet-Draft draft-ietf-lsr-ospfv3-extended-lsa-yang-27.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-27.txt
   Pages:   29
   Dates:   2024-01-16

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-27.html

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

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] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

[Acee Lindem]

Hi Tom. 

> On Jan 16, 2024, at 10:26 AM, Acee Lindem  wrote:
> 
> Hi Tom, 
> 
>> On Jan 16, 2024, at 06:50, tom petch  wrote:
>> 
>> From: Acee Lindem 
>> Sent: 15 January 2024 20:30
>> 
>> Hi Tom,
>> 
>> Since this YANG model describes the RFC 8362 encodings, those encodings 
>> should be the primary reference all the leaves and identifies.
>> 
>> 
>> 
>> Acee
>> 
>> I think that you are wrong.  The historian in me knows that given a choice 
>> or primary or secondary sources, the secondary can only get it wrong; you 
>> always go back to the primary (unless or until the primary is replaced which 
>> is not the case for most of the definitions here).
> 
> We can disagree then - I have included both references. Note that in any 
> case, someone really want to dig into the contents of an OSPFv3 LSDB would 
> need to reference both RFCs if they were not very familiar with OSPFv3 and 
> the extended encodings.  
> 
> 
> 
>> 
>>> On Jan 13, 2024, at 07:42, tom petch  wrote:
>>> 
>>> From: Lsr  on behalf of The IESG 
>>> 
>>> Sent: 11 January 2024 14:35
>>> 
>> 
>> 
>>> 
>>> Most of my comments on this I-D from August are addressed but I still have 
>>> some doubts.
>>> 
>>> p.11 identity nu-bit
>>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
>>> better reference
>> 
>> Agreed. However, I think including both references would be good since RFC 
>> 8362 includes the
>> flags in TLVs
>> 
>>> 
>>> identity la-bit
>>> here RFC8362 changes the meaning so I think the reference to RFC8362 is ok
>> 
>> Actually, for the LA-bit, both references would be good.
>> 
>>> p.11 identity p-bit
>>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
>>> better reference
>> 
>> Same as nu-bit.
>> 
>>> p.12 identity dn-bit
>>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
>>> better reference
>> 
>> Same as nu-bit.
>> 
>>> p.12 identity e-bit
>>> this is not esplained in the referenced RFC8362; in fact, this one defeats 
>>> me.  It is present in  a diagram, s.3.6,  but with no explanation.  Reading 
>>> RFC5340 it could be A.4.3 but I am not sure
>> 
>> If one is familiar with OSPF, it is clear. For AS External and NSSA metrics, 
>> there are type 1 and type 2 metrics. Type 1 are simply added to intra-area 
>> metric to the originator. Type 2 metrics are considered greater than type 1 
>> metrics. This hasn’t changed since RFC 1247 - just the OSFPv3 and OSPFv3 
>> extended-LSA encodings. Since the description is brief, I’ll include it in 
>> its entirety.
>> 
>> 
>> Indeed I learnt about Type 1 and Type 2 25 years ago and know them well; but 
>> in the modern  context of SR, IPv6, OSPFv3, extended LSA etc I did not 
>> recognise the terse allusion.
> 
> Yes - since it was not that verbose. I included the complete description in 
> the description. 
> 
> 
>> 
>> And why do you not include the AC bit defined in RFC9513?
> 
> We have a separate model for these OSPFv3 segment routing extensions. 
> However, since the AC-bit is not unique to segment routing, I could just as 
> well include it here. We’ll see if I get any more IETF Last Call comments. 

Actually, the ac-bit is already included in this model - 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-srv6-yang/

Thanks,
Acee



> 
> Thanks,
> Acee
> 
> 
>> 
>> Tom Petch
>> 
>> Thanks,
>> Acee
>> 
>> 
>> 
>> 
>>> 
>>> Tom Petch
>>> 
>>> 
>>> 
>>> 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 file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>>> 
>>> 
>>> 
>>> No IPR declarations have been submitted directly on this I-D.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

[Reshad Rahman]

 Hi Acee,
Sounds good!
Regards,Reshad.
On Tuesday, January 16, 2024, 12:45:40 PM EST, Acee Lindem 
 wrote:  
 
 Hi Reshad, 


On Jan 16, 2024, at 11:41, Reshad Rahman  
wrote:
 Hi,
Apologies if this has been discussed before but I didn't follow this document.
- Should interface-id and neighbor-interface-id be of type if:if-index instead 
of uint32? I took a look at RFC8362, still not clear to me.

It could very well be the if-index but it doesn’t have to me. It is whatever 
the neighbor choses to use to uniquely identify its interfaces. Excerpted from 
RFC 5340, Appendix A.3.2:
   Interface ID
  32-bit number uniquely identifying this interface among the
  collection of this router's interfaces.  For example, in some
  implementations it may be possible to use the MIB-II IfIndex
  ([INTFMIB]).


- Should leaf metric be of type ospf-metric or ospf-leaf-metric instead of 
uint16?

The 24 bit metrics should be ospf:ospf-metric. The 16-bit metric should be 
ospf:ospf-link-metric. I’ll update these in the next revision.  
Thanks,Acee




Regards,Reshad.
On Thursday, January 11, 2024, 09:36:03 AM EST, The IESG 
 wrote:  
 
 
The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'YANG Model for OSPFv3 Extended LSAs'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/



No IPR declarations have been submitted directly on this I-D.





___
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] [Errata Verified] RFC4576 (7765)

[RFC Errata System]

The following errata report has been verified for RFC4576,
"Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in 
BGP/MPLS IP Virtual Private Networks (VPNs)". 

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

--
Status: Verified
Type: Editorial

Reported by: Julian Cowley 
Date Reported: 2024-01-15
Verified by: John Scudder (IESG)

Section: 7

Original Text
-
   [OSPFv2]   Postel, J., "Suggested Telnet Protocol Changes", RFC 328,
  April 1972.

Corrected Text
--
   [OSPFv2]   Moy, J., "OSPF Version 2", RFC 2328, April 1998.

Notes
-
The error was caused by a missing 2 in front of the RFC number in the reference.

--
RFC4576 (draft-ietf-ospf-2547-dnbit-04)
--
Title   : Using a Link State Advertisement (LSA) Options Bit to 
Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
Publication Date: June 2006
Author(s)   : E. Rosen, P. Psenak, P. Pillay-Esnault
Category: PROPOSED 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] [Errata Verified] RFC9513 (7766)

[RFC Errata System]

The following errata report has been verified for RFC9513,
"OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)". 

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

--
Status: Verified
Type: Editorial

Reported by: tom petch 
Date Reported: 2024-01-16
Verified by: John Scudder (IESG)

Section: 6

Original Text
-
   The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
   is defined to advertise the anycast property:

  0  1  2  3  4  5  6  7
 +--+--+--+--+--+--+--+--+
 |AC|EL| N|DN| P| x|LA|NU|
 +--+--+--+--+--+--+--+--+

   Figure 2: OSPFv3 Prefix Options Field


Corrected Text
--
   The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
   is defined to advertise the anycast property:

  0  1  2  3  4  5  6  7
 +--+--+--+--+--+--+--+--+
 |AC| E| N|DN| P| x|LA|NU|
 +--+--+--+--+--+--+--+--+

   Figure 2: OSPFv3 Prefix Options Field


Notes
-
Bit 1 is defined in RFC9089 section 6 as   
 *  Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
  allocated to the E-Flag (ELC Flag).
It is not the EL bit or flag.

Verifier note: I added a space before the E in Tom's proposed correction, to 
make the diagram line up.

--
RFC9513 (draft-ietf-lsr-ospfv3-srv6-extensions-15)
--
Title   : OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)
Publication Date: December 2023
Author(s)   : Z. Li, Z. Hu, K. Talaulikar, Ed., P. Psenak
Category: PROPOSED STANDARD
Source  : Link State Routing
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

[Acee Lindem]

Hi Reshad, 

> On Jan 16, 2024, at 11:41, Reshad Rahman  
> wrote:
> 
> Hi,
> 
> Apologies if this has been discussed before but I didn't follow this document.
> 
> - Should interface-id and neighbor-interface-id be of type if:if-index 
> instead of uint32? I took a look at RFC8362, still not clear to me.

It could very well be the if-index but it doesn’t have to me. It is whatever 
the neighbor choses to use to uniquely identify its interfaces. Excerpted from 
RFC 5340, Appendix A.3.2:


   Interface ID
  32-bit number uniquely identifying this interface among the
  collection of this router's interfaces.  For example, in some
  implementations it may be possible to use the MIB-II IfIndex
  ([INTFMIB]).


> - Should leaf metric be of type ospf-metric or ospf-leaf-metric instead of 
> uint16?

The 24 bit metrics should be ospf:ospf-metric. The 16-bit metric should be 
ospf:ospf-link-metric. I’ll update these in the next revision.  

Thanks,
Acee



> 
> Regards,
> Reshad.
> 
> On Thursday, January 11, 2024, 09:36:03 AM EST, The IESG 
>  wrote:
> 
> 
> 
> The IESG has received a request from the Link State Routing WG (lsr) to
> consider the following document: - 'YANG Model for OSPFv3 Extended LSAs'
>as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org  mailing lists by 2024-01-25. 
> Exceptionally, comments may
> be sent to i...@ietf.org  instead. In either case, 
> please retain the beginning
> of the Subject line to allow automated sorting.
> 
> 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 file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> ___
> 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] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Les Ginsberg (ginsberg)]

Aijun –

Please see inline.

From: Aijun Wang 
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps' 
; 'Huzhibo' 
Cc: 'Acee Lindem' ; 'Yingzhen Qu' 
; 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月16日 0:16
收件人: Christian Hopps mailto:cho...@chopps.org>>; Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org>>
抄送: Acee Lindem mailto:acee.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)



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.

[WAJ] Current encoding has covered the unnumbered scenario. For Pt-2-MP 
scenario, they share also the same subnet, please see our previous discussion 
at https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/



[LES:] I have no idea why you think the email you point to resolved the issue. 
It was an early email in a very long thread, the lack of support for unnumbered 
etc. continued to be discussed in subsequent emails by multiple participants 
and has been raised again by multiple participants in this second adoption call 
thread.

The minor changes you made to the encoding of Stub Link advertisement does 
nothing to resolve the issue.

The fundamental issue is that the same prefix can be associated with multiple 
links, so what you have defined is ambiguous in some cases.

Either you don’t understand this or don’t think this is important – I am not 
sure which – but many of us do believe this is important.



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.

[WAJ] If you make such claims, then please give the encoding example for A.1 
Figures 2(LAN scenario). How to configure/encode the several neighbors that 
located in different AS in one inter-AS reachability TLV?



[LES:] RFC 9346/RFC 5362 provide a robust way to uniquely identify inter-AS 
links, verify two-way connectivity, and optionally advertise additional link 
attributes if desired. (Apply this portion of the response to your other 
comments below.)

You apparently think this is too onerous and you propose a different mechanism 
that isn’t robust, does not allow two-way connectivity verification, and 
doesn’t support link attribute advertisement.

But because you see it as “simpler” you think you have sufficient justification 
to overlook its flaws.

I don’t agree.



The long-lived success of the IGPs has happened because we have worked 
diligently to provide robust solutions – not settle for solutions that only 
work some of the time.



   Les



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.

[WAJ] And, please give the solution for the non inter-AS scenario(A.2). Please 
do not mention the bogus AS again



This addresses all cases - numbered and 

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

[Reshad Rahman]

 Hi,
Apologies if this has been discussed before but I didn't follow this document.
- Should interface-id and neighbor-interface-id be of type if:if-index instead 
of uint32? I took a look at RFC8362, still not clear to me.- Should leaf metric 
be of type ospf-metric or ospf-leaf-metric instead of uint16?
Regards,Reshad.
On Thursday, January 11, 2024, 09:36:03 AM EST, The IESG 
 wrote:  
 
 
The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'YANG Model for OSPFv3 Extended LSAs'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/



No IPR declarations have been submitted directly on this I-D.





___
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] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

[Acee Lindem]

Hi Tom, 

> On Jan 16, 2024, at 06:50, tom petch  wrote:
> 
> From: Acee Lindem 
> Sent: 15 January 2024 20:30
> 
> Hi Tom,
> 
> Since this YANG model describes the RFC 8362 encodings, those encodings 
> should be the primary reference all the leaves and identifies.
> 
> 
> 
> Acee
> 
> I think that you are wrong.  The historian in me knows that given a choice or 
> primary or secondary sources, the secondary can only get it wrong; you always 
> go back to the primary (unless or until the primary is replaced which is not 
> the case for most of the definitions here).

We can disagree then - I have included both references. Note that in any case, 
someone really want to dig into the contents of an OSPFv3 LSDB would need to 
reference both RFCs if they were not very familiar with OSPFv3 and the extended 
encodings.  



> 
>> On Jan 13, 2024, at 07:42, tom petch  wrote:
>> 
>> From: Lsr  on behalf of The IESG 
>> 
>> Sent: 11 January 2024 14:35
>> 
> 
> 
>> 
>> Most of my comments on this I-D from August are addressed but I still have 
>> some doubts.
>> 
>> p.11 identity nu-bit
>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
>> better reference
> 
> Agreed. However, I think including both references would be good since RFC 
> 8362 includes the
> flags in TLVs
> 
>> 
>> identity la-bit
>> here RFC8362 changes the meaning so I think the reference to RFC8362 is ok
> 
> Actually, for the LA-bit, both references would be good.
> 
>> p.11 identity p-bit
>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
>> better reference
> 
> Same as nu-bit.
> 
>> p.12 identity dn-bit
>> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
>> better reference
> 
> Same as nu-bit.
> 
>> p.12 identity e-bit
>> this is not esplained in the referenced RFC8362; in fact, this one defeats 
>> me.  It is present in  a diagram, s.3.6,  but with no explanation.  Reading 
>> RFC5340 it could be A.4.3 but I am not sure
> 
> If one is familiar with OSPF, it is clear. For AS External and NSSA metrics, 
> there are type 1 and type 2 metrics. Type 1 are simply added to intra-area 
> metric to the originator. Type 2 metrics are considered greater than type 1 
> metrics. This hasn’t changed since RFC 1247 - just the OSFPv3 and OSPFv3 
> extended-LSA encodings. Since the description is brief, I’ll include it in 
> its entirety.
> 
> 
> Indeed I learnt about Type 1 and Type 2 25 years ago and know them well; but 
> in the modern  context of SR, IPv6, OSPFv3, extended LSA etc I did not 
> recognise the terse allusion.

Yes - since it was not that verbose. I included the complete description in the 
description. 


> 
> And why do you not include the AC bit defined in RFC9513?

We have a separate model for these OSPFv3 segment routing extensions. However, 
since the AC-bit is not unique to segment routing, I could just as well include 
it here. We’ll see if I get any more IETF Last Call comments. 

Thanks,
Acee


> 
> Tom Petch
> 
> Thanks,
> Acee
> 
> 
> 
> 
>> 
>> Tom Petch
>> 
>> 
>> 
>> 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 file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>> 
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] [Editorial Errata Reported] RFC9513 (7766)

[Acee Lindem]

This Errata is correct and should be accepted. 

Thanks,
Acee

> On Jan 16, 2024, at 06:52, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC9513,
> "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7766
> 
> --
> Type: Editorial
> Reported by: tom petch 
> 
> Section: 6
> 
> Original Text
> -
>   The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
>   is defined to advertise the anycast property:
> 
>  0  1  2  3  4  5  6  7
> +--+--+--+--+--+--+--+--+
> |AC|EL| N|DN| P| x|LA|NU|
> +--+--+--+--+--+--+--+--+
> 
>   Figure 2: OSPFv3 Prefix Options Field
> 
> 
> Corrected Text
> --
>   The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
>   is defined to advertise the anycast property:
> 
>  0  1  2  3  4  5  6  7
> +--+--+--+--+--+--+--+--+
> |AC|E| N|DN| P| x|LA|NU|
> +--+--+--+--+--+--+--+--+
> 
>   Figure 2: OSPFv3 Prefix Options Field
> 
> 
> Notes
> -
> Bit 1 is defined in RFC9089 section 6 as   
> *  Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
>  allocated to the E-Flag (ELC Flag).
> It is not the EL bit or flag.
> 
> 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.
> 
> --
> RFC9513 (draft-ietf-lsr-ospfv3-srv6-extensions-15)
> --
> Title   : OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)
> Publication Date: December 2023
> Author(s)   : Z. Li, Z. Hu, K. Talaulikar, Ed., P. Psenak
> Category: PROPOSED STANDARD
> Source  : Link State Routing
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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] RFC9513 (7766)

[RFC Errata System]

The following errata report has been submitted for RFC9513,
"OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)".

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

--
Type: Editorial
Reported by: tom petch 

Section: 6

Original Text
-
   The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
   is defined to advertise the anycast property:

  0  1  2  3  4  5  6  7
 +--+--+--+--+--+--+--+--+
 |AC|EL| N|DN| P| x|LA|NU|
 +--+--+--+--+--+--+--+--+

   Figure 2: OSPFv3 Prefix Options Field


Corrected Text
--
   The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340]
   is defined to advertise the anycast property:

  0  1  2  3  4  5  6  7
 +--+--+--+--+--+--+--+--+
 |AC|E| N|DN| P| x|LA|NU|
 +--+--+--+--+--+--+--+--+

   Figure 2: OSPFv3 Prefix Options Field


Notes
-
Bit 1 is defined in RFC9089 section 6 as   
 *  Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
  allocated to the E-Flag (ELC Flag).
It is not the EL bit or flag.

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.

--
RFC9513 (draft-ietf-lsr-ospfv3-srv6-extensions-15)
--
Title   : OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)
Publication Date: December 2023
Author(s)   : Z. Li, Z. Hu, K. Talaulikar, Ed., P. Psenak
Category: PROPOSED STANDARD
Source  : Link State Routing
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

[tom petch]

From: Acee Lindem 
Sent: 15 January 2024 20:30

Hi Tom,

Since this YANG model describes the RFC 8362 encodings, those encodings should 
be the primary reference all the leaves and identifies.



Acee

I think that you are wrong.  The historian in me knows that given a choice or 
primary or secondary sources, the secondary can only get it wrong; you always 
go back to the primary (unless or until the primary is replaced which is not 
the case for most of the definitions here).

> On Jan 13, 2024, at 07:42, tom petch  wrote:
>
> From: Lsr  on behalf of The IESG 
> 
> Sent: 11 January 2024 14:35
>


> 
> Most of my comments on this I-D from August are addressed but I still have 
> some doubts.
>
> p.11 identity nu-bit
> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
> better reference

Agreed. However, I think including both references would be good since RFC 8362 
includes the
flags in TLVs

>
> identity la-bit
> here RFC8362 changes the meaning so I think the reference to RFC8362 is ok

Actually, for the LA-bit, both references would be good.

> p.11 identity p-bit
> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
> better reference

Same as nu-bit.

> p.12 identity dn-bit
> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a 
> better reference

Same as nu-bit.

> p.12 identity e-bit
> this is not esplained in the referenced RFC8362; in fact, this one defeats 
> me.  It is present in  a diagram, s.3.6,  but with no explanation.  Reading 
> RFC5340 it could be A.4.3 but I am not sure

If one is familiar with OSPF, it is clear. For AS External and NSSA metrics, 
there are type 1 and type 2 metrics. Type 1 are simply added to intra-area 
metric to the originator. Type 2 metrics are considered greater than type 1 
metrics. This hasn’t changed since RFC 1247 - just the OSFPv3 and OSPFv3 
extended-LSA encodings. Since the description is brief, I’ll include it in its 
entirety.


Indeed I learnt about Type 1 and Type 2 25 years ago and know them well; but in 
the modern  context of SR, IPv6, OSPFv3, extended LSA etc I did not recognise 
the terse allusion.

And why do you not include the AC bit defined in RFC9513?

Tom Petch
 
Thanks,
Acee




>
> Tom Petch
>
>
>
> 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 file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> ___
> 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] 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

[Giuseppe Fioccola]

Hi Acee, All,
I have read this document and support its progress.

Regards,

Giuseppe

-Original Message-
From: Lsr  On Behalf Of Acee Lindem
Sent: Monday, January 8, 2024 11:50 PM
To: Lsr 
Subject: [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] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Les:

 

-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: 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)

 

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-attribute
s-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.

[WAJ] Current encoding has covered the unnumbered scenario. For Pt-2-MP
scenario, they share also the same subnet, please see our previous
discussion at
https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/

 

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.

[WAJ] If you make such claims, then please give the encoding example for A.1
Figures 2(LAN scenario). How to configure/encode the several neighbors that
located in different AS in one inter-AS reachability TLV? 

 

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.

[WAJ] And, please give the solution for the non inter-AS scenario(A.2).
Please do not mention the bogus AS again

 

This addresses all cases - numbered and unnumbered.

There is therefore no need for a new mechanism.

[WAJ] Repeat again. The requirements of inter-AS TE solution are different
from the requirements of inter-AS topology recovery. We should find more
efficient solution to solve the latter scenario.

The inefficiency of existing solutions for inter-AS topology recovery lies
in that it requires the operators to get the other end information for every
inter-as links manually, this is very challenge and error-prone, as that
also indicated in RFC9346 and RFC5392 themselves.

 

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 <  lsr-boun...@ietf.org> On Behalf
Of Christian Hopps

> Sent: Wednesday, January 10, 2024 2:17 AM

> To: Huzhibo < 
huzhibo=40huawei@dmarc.ietf.org>

> Cc: Acee Lindem <  acee.i...@gmail.com>;
Yingzhen Qu 

> <  yingzhen.i...@gmail.com>;
 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-

>