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. 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? <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? ---------------------------------------------------------------------- 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
