Hi Tom, > On Jan 2, 2024, at 06:11, tom petch <[email protected]> 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 <[email protected]> on behalf of [email protected] > <[email protected]> > Sent: 19 December 2023 21:41 > To: [email protected] > Cc: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
