Hi Acee,
Thanks for the update - I will clear my DISCUSS and retain all comments
(even though you have taken care of some of them from a quick glance).
There is one typo though below:
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.";
}
description
"SR TLVs for OSPFv2 Extended Link TLV in OSPFv2 Type 10
(area-scoped) Extended Link Opaque LSAs.";
reference
"RFC 8665: OSPF Extensions for Segment Routing
(Section 6)";* uses ospfv3-adj-sid-sub-tlvs;
uses ospfv3-lan-adj-sid-sub-tlvs;*
}
They should be ospfv2
Thanks,
Ketan
On Wed, Apr 2, 2025 at 5:07 PM Acee Lindem <[email protected]> wrote:
> I've added -38. Please take a look.
>
> > On Apr 1, 2025, at 1:40 PM, Ketan Talaulikar <[email protected]>
> wrote:
> >
> > 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 <[email protected]> wrote:
> > Hi Ketan,
> >
> > > On Apr 1, 2025, at 1:10 PM, Ketan Talaulikar <[email protected]>
> wrote:
> > >
> > > Hi Acee,
> > >
> > > Thanks for your quick response and please check inline below.
> > >
> > >
> > > On Tue, Apr 1, 2025 at 10:19 PM Acee Lindem <[email protected]>
> 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 <
> [email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
