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

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

[Acee Lindem]

Hi Tom, 

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


> On Jan 13, 2024, at 07:42, tom petch  wrote:
> 
> From: Lsr  on behalf of The IESG 
> 
> Sent: 11 January 2024 14:35
> 
> 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.
> 
> 
> 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 daigram, 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. 

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

[tom petch]

From: Lsr  on behalf of The IESG 
Sent: 11 January 2024 14:35

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.


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

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

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

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

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

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

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

[The IESG]

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