Skip to main content

Early Review of draft-ietf-ospf-sr-yang-20
review-ietf-ospf-sr-yang-20-yangdoctors-early-rahman-2023-04-03-00

Request Review of draft-ietf-ospf-sr-yang
Requested revision No specific revision (document currently at 32)
Type Early Review
Team YANG Doctors (yangdoctors)
Deadline 2023-03-25
Requested 2023-02-23
Requested by Christian Hopps
Authors Yingzhen Qu , Acee Lindem , Zhaohui (Jeffrey) Zhang , Ing-Wher (Helen) Chen
I-D last updated 2023-04-03
Completed reviews Rtgdir Last Call review of -22 by Julien Meuric (diff)
Yangdoctors Last Call review of -28 by Reshad Rahman (diff)
Yangdoctors Early review of -20 by Reshad Rahman (diff)
Comments
Getting ready to WGLC this document.
Assignment Reviewer Reshad Rahman
State Completed
Request Early review on draft-ietf-ospf-sr-yang by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/pchLiAxcx1LEsJRqM1OMxhH62D8
Reviewed revision 20 (document currently at 32)
Result Ready w/issues
Completed 2023-04-03
review-ietf-ospf-sr-yang-20-yangdoctors-early-rahman-2023-04-03-00
Main comments
=============

- Please add lots of references in the YANG. There are many (most/all?) nodes
e.g. m-bit, protocol-srgb etc etc, and probably types, which need references to
the relevant sections in corresponding RFCs. - The document needs a least 1,
probably more, examples. - The abstract mentions OSPF, the overview mentions
OSPFv2 only and the YANG module has OSPFv2 and OSPFv3. - sr-algorithm should be
a leafref to an algorithm somewhere, right now it's a uint8. - No need to
redefine uint24, it's already define in RFC8294. - Leaf preference, no need for
range 0..255 since it's a uint8 - Looking at RFC9020, I see that container
segment-routing, in grouping sr-control-plane, is non-presence and leaf receive
has default value true, meaning receive is true by default even if the
container hasn’t been created. Is that the intention? And is it the desired
behaviour in OSPF? If no, you can add a refine statement. My guess though is
that is a mistake in RFC9020.

Questions
=========

- extended-prefix-range-tlvs is used only for ospfv2. Is that on purpose. Since
there's an "af" node in the grouping, I assumed it'd be used for ospfv3 also.
BTW 'af' is defined as uint8, there's an address-family type in RFC6991 and
that should be used instead. - Is uint16 sufficient for range-size? - I see
augment ospf:ospfv2 when rt:type = ospfv2, is the when-stmt needed? The ospfv2
container should only exist for ospfv2? - Leaf sid is a uint32. In SR models,
is the Sid always represented as a uint32 or is there a type defined. And
should it be a choice for 20-bit label v/s 32-bit SID. - List
lan-adj-sid-sub-tlv in container lan-adj-sid-sub-tlvs, no need for a key?

Regards,
Reshad.