Hi Acee, The area-level will control the origination of the SR information in the area-scoped RI LSAs (SR algo, SRGB, etc.) without that the interface enablement will not amount to much really. Practically, the area enablement is more significant IMHO - when enabled, it can be also enabled for all interfaces in that area (as in a hierarchical thing).
Thanks, Ketan On Tue, Apr 1, 2025 at 11:05 PM Acee Lindem <acee.i...@gmail.com> wrote: > Hi Ketan, > > > On Apr 1, 2025, at 1:10 PM, Ketan Talaulikar <ketant.i...@gmail.com> > wrote: > > > > Hi Acee, > > > > Thanks for your quick response and please check inline below. > > > > > > On Tue, Apr 1, 2025 at 10:19 PM Acee Lindem <acee.i...@gmail.com> wrote: > > 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". > > > > KT> Got it. Thanks. I hope my eyesight for YANG models improves as I > work through this gig. > > > > > > 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 😎 > > > > KT> Yes, I am ashamed :-( ... no excuses to offer! > > 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. > > > > KT> Please check if the "enabled" option for SR-MPLS can be provided > under the area-level so as to control enablement in specific portions of an > OSPF network. It was something that was helpful in the early days of SR. > Same applies for ISIS as well. That said, this is not something that > qualifies as a DISCUSS if not taken up in this document. > > I found what was intended for interfaces in ietf-segment-routing-mpls.yang > - I will add augmentations to ietf-ospf-sr-mpls module. I am ashamed 😎 > > So, at the area level it is a simply boolean? What if SR is not enabled in > any interfaces in the area and it is enabled at the top level? Similarly, > what if it is enabled on interfaces but not enabled at the area level? > Should this be prevented? In other words, what is intended here? > > Thanks, > Acee > > > > > > > > > > > > > > > > <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. > > > > KT> Sure. However, the same applies to prefix SID as well which is > modeled as a grouping for both OSPFv2 and v3. However, adj SID is modeled > as a grouping only for OSPFv3. In other words, why not define "grouping > ospfv2-adj-sid-sub-tlvs" and included it with "uses" under the following > augment for OSPFv2 > > > > augment "/rt:routing/" > > + "rt:control-plane-protocols/rt:control-plane-protocol/" > > + "ospf:ospf/ospf:areas/" > > + "ospf:area/ospf:database/" > > + "ospf:area-scope-lsa-type/ospf:area-scope-lsas/" > > + "ospf:area-scope-lsa/ospf:version/ospf:ospfv2/" > > + "ospf:ospfv2/ospf:body/ospf:opaque/" > > + "ospf:extended-link-opaque/ospf:extended-link-tlv" { > > when "derived-from(/rt:routing/rt:control-plane-protocols/" > > + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" { > > description > > "This augmentation is only valid for OSPFv2."; > > } > > Am I missing something here? > > > > Thanks, > > Ketan > > > > > > 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
