Re: [Lsr] SID et al. in Re: I-D Action: draft-ietf-ospf-sr-yang-25.txt

[Acee Lindem]

Hi Tom, 

> On Jan 2, 2024, at 06:11, tom petch  wrote:
> 
> a) I think that the treatment of SID index/label in this I-D needs more 
> explanation.
> 
> The I-D rightly says that this is either a 3-octet index or 4-octet label but 
> fails to say how the three octets are mapped into a YANG type uint32.  The 
> information is in RFC8665 but it took me a while to find it.  I think that it 
> needs repeating in this I-D with a reference to RFC8665.
> 
> Slightly harder is where to put this.  I think that it needs to be in the 
> YANG module as a description. Trouble is, there are lots of uint32 where this 
> is relevant.  Now if SID were a YANG derived type .

Unfortunately, this SID Value/Label encoding was set in IS-IS initially and 
migrated to OSPF. I was never happy with these encodings but the chefs in the 
kitchen were set on them. We can’t fix this  in the YANG model as it is what it 
is. I’ll update the descriptions. 




> 
> b) the I-D does not use the same name for bits as RFC8665 does.  Where this 
> happens, then I think there should be an explanation e.g.
> identity lo-bit
> description ' this bit is referred to as the L-flag in RFC8665 section 5.

I’ll change the definitions to -flag and -flags. The -bit and -bits is a 
holdover from when we were using YANG type bits. 


> 
> c) section 1.1 is out of date
> 
> d) CODE BEGINS 
> I think better as a new paragraph for ease of reference; I see this as common 
> practive
> 
> e) leaf mt-id
> if the only valid values are 0 to 127, then this could use a YANG range to 
> reflect that

I’m pretty confident that this range (set in RFC 4915) will never change. 
However, since this is “config false” data, it is better to not constrain it 
and return it even if it is incorrect. This is currently an area of discussion 
in the NETMOD WG. 



> 
> f) range-size
> likewise if this must be greater than zero, thrm the YANG could reflect that. 
> It could  even be a derived type to avoid repetition

Same as the above.

Thanks,
Acee




> 
> Tom Petch
> 
> 
> From: Lsr  on behalf of internet-dra...@ietf.org 
> 
> Sent: 19 December 2023 21:41
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-ospf-sr-yang-25.txt
> 
> Internet-Draft draft-ietf-ospf-sr-yang-25.txt is now available. It is a work
> item of the Link State Routing (LSR) WG of the IETF.
> 
>   Title:   A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane
>   Authors: Yingzhen Qu
>Acee Lindem
>Jeffrey Zhang
>Ing-Wher Chen
>   Name:draft-ietf-ospf-sr-yang-25.txt
>   Pages:   46
>   Dates:   2023-12-19
> 
> Abstract:
> 
>   This document defines a YANG data module that can be used to
>   configure and manage OSPF Extensions for Segment Routing for the MPLS
>   data plane.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-ospf-sr-yang-25.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ospf-sr-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
> 
> ___
> 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-ospf-sr-yang-27.txt

[internet-drafts]

Internet-Draft draft-ietf-ospf-sr-yang-27.txt is now available. It is a work
item of the Link State Routing (LSR) WG of the IETF.

   Title:   A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane
   Authors: Yingzhen Qu
Acee Lindem
Jeffrey Zhang
Ing-Wher Chen
   Name:draft-ietf-ospf-sr-yang-27.txt
   Pages:   49
   Dates:   2024-01-07

Abstract:

   This document defines a YANG data module that can be used to
   configure and manage OSPF Extensions for Segment Routing for the MPLS
   data plane.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ospf-sr-yang-27.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ospf-sr-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

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

[Aijun Wang]

Hi, All:

 

I am not aware of any IPR that applies to the draft.

 

The latest version of this draft(version-08) has made signification updates 
since its earlier version(version -02).

We are seeking one general solution that can cover more scenarios, as that are 
descried in Appendix A.1, A.2, A.3.

 

Wish to get to your support to forward and refine it.

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Yingzhen Qu
发送时间: 2024年1月6日 8:23
收件人: lsr ; lsr-chairs 
主题: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 
01/19/2024)

 

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