Hi Ketan, As with the other AD comments, I respond to the DISCUSS-level comments first.
> On Apr 1, 2025, at 10:57 AM, Ketan Talaulikar via Datatracker > <nore...@ietf.org> wrote: > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-ospf-sr-yang-37: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however. > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > A couple of points for discussion: > > <discuss-1> I see the following in the Appendix B: > > 1833 augment /rt:routing/rt:control-plane-protocols > 1834 /rt:control-plane-protocol/ospf:ospf: > 1835 +--rw segment-routing > 1836 | +--rw enabled? boolean > 1837 | +--rw bindings {mapping-server}? > 1838 | +--rw advertise > 1839 | | +--rw policies* leafref > 1840 | +--rw receive? boolean > 1841 +--rw protocol-srgb {sr-mpls:protocol-srgb}? > 1842 +--rw srgb* [lower-bound upper-bound] > 1843 +--rw lower-bound uint32 > 1844 +--rw upper-bound uint32 > > But I am not able to find these augmentations in the model itself. Am I > missing something? YANG is not my forte. I am unable to find this across > modules and wanted to cross-check. This is imported from the ietf-segment-routing-mpls YANG module. Hopefully, you're at least using a modern mailer viewer. See the line in red below or look for "uses sr-mpls.sr-control-plane". augment "/rt:routing/rt:control-plane-protocols" + "/rt:control-plane-protocol/ospf:ospf" { when "derived-from(/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospf')" { description "This augments the OSPF routing protocol when used."; } description "This augments the OSPF protocol configuration with segment routing for the MPLS data plane. The following semantic validation be performed for the configuration data: - Assure the binding policies prefixes do not overlapp."; reference "RFC 9020 - YANG Data Model for Segment Routing"; uses sr-mpls:sr-control-plane; container protocol-srgb { if-feature "sr-mpls:protocol-srgb"; uses sr-cmn:srgb; description "Per-protocol SRGB."; } } > > Also, I am not able to find the RW (config) options for enabling (with a bool) > SR-MPLS for a specific OSPF area, or interface in the model. Have I missed > this as well? If it is not covered, was this discussed during the development > of this model in the WG? This isn't there. As one of the most active members of the LSR WG (in terms of drafts), why is this the first time you are looking at this? I guess you are ashamed 😎 Please provide the semantics of these parameters and the co-authors will consider - you don't need to be a YANG expert to provide this. > > <discuss-2> I see that the model defines grouping for ospfv3-adj-sid-sub-tlvs > but not for OSPFv2 for the same thing (it is modeled directly as a container). > I would like to understand why so? Because OSPFv3 is fundamentally different in that the extensions are whole contained in OSPFv3 E-LSAs and in OSPFv2 they are advertised in the ancillary OSPFv2 Extended Prefix LSA. OSPFv3 with Extended LSAs (RFC 8362) is superior to both IS-IS and OSPFv2 and it is unfortunate that vendor politics have delayed its adoption as the irrefutable next-generation IGP. Thanks, Acee > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please find below some comments that are in the idnits output of v37: > > > 91 2. OSPF Segment Routing YANG Data Module Scope > > 93 This document defines a model for OSPF Segment Routing Extensions for > 94 both OSPFv2 [RFC8665] and OSPFv3 [RFC8666]. > > <major> ... for the MPLS data plane. > > 96 The OSPF SR YANG module requires support for the base segment routing > 97 module [RFC9020], which defines the global segment routing > 98 configuration independent of any specific routing protocol > 99 configuration, and support of OSPF base model [RFC9129] which defines > 100 basic OSPF configuration and state. > > 102 The ietf-ospf-sr-mpls data module defines both the data nodes to > 103 configure OSPF segment routing MPLS extensions and the additions to > 104 the OSPF Link State Advertisements (LSAs) necessary to support MPLS > 105 segment routing. The OSPF configuration includes: > > <minor> s/MPLS segment routing/SR-MPLS > > > 156 * OSPFv3 Adj-SID Sub-TLV in the OSPFv3 Router-Link TLV [RFC8362]. > > 158 * OSPFv3 Adj-SID Sub-TLV in the OSPFv3 Router-Link TLV [RFC8362]. > > 160 * OSPFv3 Lan Adj-SID Sub-TLV in the OSPFv3 Router-Link TLV > 161 [RFC8362]. > > <nit> s/Lan/LAN > > <minor> Please add [RFC8666] reference as well above for (LAN) Adj-SID > encodings > > > 418 /* Groupings */ > 419 grouping sid-tlv-encoding { > 420 description > 421 "SID TLV Encoding - 20-bit label or 32-bit SID whose > > <minor> s/SID/SID index > > 422 interpretation is dependent on the TLV length (3 for an > 423 MPLS label or 4 for a 32-bit value) or the TLV V-Flag and > 424 L-Flag settings: > > 426 If the V-Flag is set to 0 and L-Flag is set to 0: > 427 The SID/Index/Label field is a 4-octet index defining > 428 the offset in the SID/Label space advertised by this > 429 router. > > 431 If V-Flag is set to 1 and L-Flag is set to 1: The > 432 ID/Index/Label field is a 3-octet local label where the > 433 20 rightmost bits are used for encoding the label value."; > 434 reference > 435 "RFC 8665: OSPF Extensions for Segment Routing, Section 5 > 436 RFC 8666: OSPFv3 Extensions for Segment Routing, Section 3"; > 437 leaf sid-raw { > 438 type uint32; > 439 description > 440 "Raw SID value - labels are in the rightmost 20 bits of > 441 the value"; > 442 } > 443 choice sid-value { > 444 case label-sid { > 445 leaf label-value { > 446 type uint32 { > 447 range "0 .. 1048575"; > 448 } > 449 description > 450 "A 20-bit MPLS Label"; > 451 } > 452 } > 453 case offset-sid { > 454 leaf offset-value { > > <major> I am not familiar of this "offset" term. What is used more often is > "index" since the value is an index into the (SRGB) label space advertised. > It is not an "offset" since SRGB may comprise of multiple non-contiguous > blocks - they need to be arrange in the order of advertisement to form a > single block and then this index is used to pick the label value. To me, > offset sounds more like something done in memory location that assume it to be > contiguous. > Suggest ... > s/label-sid/sid-label > s/offset-sid/sid-index ... s/offset-value/index-value > > 455 type uint32; > 456 description > 457 "Offset into a label space advertised by this router."; > 458 } > 459 } > 460 description > 461 "Choice of either a 20-bit MPLS lable or 32-bit offset into > 462 an advertised label space."; > 463 } > 464 } > > > 466 grouping sid-sub-tlv { > 467 description > 468 "SID/Label sub-TLV grouping."; > 469 reference > 470 "RFC 8665: OSPF Extensions for Segment Routing > 471 (Section 6)"; > > KT> Reference should be section 2.1 of RFC8665? > > 472 container sid-sub-tlv { > 473 description > 474 "Used to advertise the SID/Label associated with a > 475 prefix or adjacency."; > 476 leaf length { > 477 type uint16; > 478 description > 479 "Length of the SID value. YANG model specification > 480 is necessary since it dictates the semantics of the > 481 SID."; > 482 } > 483 uses sid-tlv-encoding; > 484 } > 485 } > > > 602 grouping sid-range-tlvs { > 603 description > 604 "SID Range TLV grouping."; > 605 reference > 606 "RFC 8665: OSPF Extensions for Segment Routing > 607 (Section 3.2)"; > 608 container sid-range-tlvs { > 609 description > 610 "List of SID range TLVs. Note that the order of advertised > 611 SID ranges is implementation dependent."; > > <major> Please update "Note that the order of advertised SID ranges is > implementation dependent." - the ordering is pretty important and MUST be as > per what has been received in the LSA on the wire. This is the SRGB. > > 612 list sid-range-tlv { > 613 description > 614 "SID range TLV."; > 615 leaf range-size { > 616 type rt-types:uint24; > 617 description > 618 "SID range."; > 619 } > 620 uses sid-sub-tlv; > 621 } > 622 } > 623 } > > 625 grouping local-block-tlvs { > 626 description > 627 "The SR local block TLV contains the > 628 range of labels reserved for local SIDs."; > 629 reference > 630 "RFC 8665: OSPF Extensions for Segment Routing > 631 (Section 3.3)"; > 632 container local-block-tlvs { > 633 description > 634 "List of SRLB TLVs."; > > <major> Here too the ordering has to be as on the wire for SRLB - if similar > text is clarified above for SRGB. > > 635 list local-block-tlv { > 636 description > 637 "SRLB TLV."; > 638 leaf range-size { > 639 type rt-types:uint24; > 640 description > 641 "SID range. The return of a zero value would indicate > 642 an error."; > 643 } > 644 uses sid-sub-tlv; > 645 } > 646 } > 647 } > > > 1561 Author affiliation with The MITRE Corporation is provided for > 1562 identification purposes only, and is not intended to convey or imply > 1563 MITRE's concurrence with, or support for, the positions, opinions or > 1564 viewpoints expressed. MITRE has approved this document for Public > 1565 Release, Distribution Unlimited, with Public Release Case Number > 1566 18-3281. > > <major> With the text above (which applies MITRE has some sort of an approval > authority over this document), it seems more appropriate for this author to > drop > their MITRE Corporation affiliation. > > > _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
