Hi all, I tend to agree with Ketan.
From an OPS standpoint, we need to make it clear in the spec which one takes precedence and have guards to prevent conflicting instructions. Cheers, Med De : Ketan Talaulikar <ketant.i...@gmail.com> Envoyé : mardi 1 avril 2025 19:40 À : Acee Lindem <acee.i...@gmail.com> Cc : The IESG <i...@ietf.org>; draft-ietf-ospf-sr-y...@ietf.org; lsr-cha...@ietf.org; lsr <lsr@ietf.org>; Christian Hopps <cho...@chopps.org> Objet : Re: Ketan Talaulikar's Discuss on draft-ietf-ospf-sr-yang-37: (with DISCUSS and COMMENT) 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<mailto:acee.i...@gmail.com>> wrote: Hi Ketan, > On Apr 1, 2025, at 1:10 PM, Ketan Talaulikar > <ketant.i...@gmail.com<mailto: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<mailto: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<mailto: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. > > > > > > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
