Hi Tarek, In that case, there is more wrong than just the RPC since you haven't augmented ietf-routing.yang properly to define an MPLS-specific RIB. Furthermore, I don't think you should. We need the optional MPLS augmentations for the IPv4 and IPv6 address families as these are what one would need in for a IPv4 or IPv6 RIB for a device that supports MPLS.
Your augmentation to the active-route RPC needs to just be removed. Acee On 8/10/20, 4:24 PM, "Tarek Saad" <ts...@juniper.net> wrote: Hi Acee, The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to return the matching active route identified by a "destination address". The MPLS module is trying to reuse this RPC so to query the MPLS RIB to return the matching active route identified by a "local label". The RPC defined in RFC 8349 readily accepts MPLS AFI in it (/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress it with a "when check". IMO, it is reusable as-is but the text below is limiting the leaf name that identifies an entry in RIB to "destination-address" only - in MPLS RIB the entry leaf name that identifies an entry is "local-label". > action active-route { > description > "Return the active RIB route that is used for the > destination address. > > Address-family-specific modules MUST augment input > parameters with a leaf named 'destination-address'."; Regards, Tarek On 8/10/20, 3:27 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote: [External Email. Be cautious of content] All (Speaking as an author of RFC 8349), I just looked at this in more detail and I don't think the ietf-mpls.yang model should be augmenting the /rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to return the address-family specific active-route corresponding to the destination-address. This model attempts to overload this RPC with a different action all together - returning a route that has the local-label as an optional attribute. I'd reject the Errata and believe the augmentation should be removed from ietf-mpl.yang. Whether it is replaced with a different one is up to the co-authors of ietf-mpls.yang. Thanks, Acee On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)" <rwil...@cisco.com> wrote: [Resend to hopefully pass recipient limit filter] Hi Tom, I would be interested to hear from the original authors. My impression is that this is a technically reasonable change, but I don't think that an erratum can create a new revision of a YANG module. If this erratum was processed as "Hold for document update" then would that be sufficient to do the right thing in the MPLS YANG module? Regards, Rob > -----Original Message----- > From: tom petch <ie...@btconnect.com> > Sent: 10 August 2020 17:32 > To: RFC Errata System <rfc-edi...@rfc-editor.org>; lho...@nic.cz; Acee > Lindem (acee) <a...@cisco.com>; yingzhen...@huawei.com; war...@kumari.net; > Rob Wilton (rwilton) <rwil...@cisco.com>; joe...@bogus.com; > kent+i...@watsen.net; lber...@labn.net > Cc: ts...@juniper.net; netmod@ietf.org > Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251) > > From: netmod <netmod-boun...@ietf.org> on behalf of RFC Errata System > <rfc-edi...@rfc-editor.org> > Sent: 07 August 2020 16:45 > > <tp> > This is the erratum of whose arrival I speculated on this list on June > 16th. > > There is a degree of urgency about it. The I-D in question is mpls-base- > yang, currently in IETF Last Call, which is a Normative dependency of bfd- > yang which is a Normative dependency for a small mountain of I-D which > have been waiting a year or so (e.g. ospf-yang). > > I suspect that the technically perfect solution would involve a YANG > union, choice or some such structure but as I said in my Last Call comment > I can live with a label that contains such as 'address' encompassing such > as 'label' in the context of forwarding. I take labels to mean what > labels mean rather than what I might find in a work of reference. > > Tom Petch > > The following errata report has been submitted for RFC8349, > "A YANG Data Model for Routing Management (NMDA Version)". > > -------------------------------------- > You may review the report below and at: > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6251__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxw8DnSr2A$ > > -------------------------------------- > Type: Technical > Reported by: Tarek Saad <ts...@juniper.net> > > Section: 7 > > Original Text > ------------- > The RPC "active-route" is used to retrieve the active route in a RIB. > RFC8349 defined two AFIs (v4/v6). > > draft-ietf-mpls-base-yang is defining a new RIB AFI for MPLS as per > section 3 in RFC8349. > > The RPC has a "MUST" statement that all RIBs must augment input > parameters with a leaf named 'destination-address'. > > For MPLS RIB, it makes sense to augment with leaf named 'local-label' > since MPLS routes are identified by MPLS label. > > We ask to make the following change: > > OLD: > action active-route { > description > "Return the active RIB route that is used for the > destination address. > > Address-family-specific modules MUST augment input > parameters with a leaf named 'destination-address'."; > > > Corrected Text > -------------- > NEW: > action active-route { > description > "Return the active RIB route that is used for the > destination address. > > Address-family-specific modules MUST augment input > parameters with a suitable leaf that identifies the > route."; > > > Notes > ----- > > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8349 (draft-ietf-netmod-rfc8022bis-11) > -------------------------------------- > Title : A YANG Data Model for Routing Management (NMDA > Version) > Publication Date : March 2018 > Author(s) : L. Lhotka, A. Lindem, Y. Qu > Category : PROPOSED STANDARD > Source : Network Modeling > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxxyc2_LZA$ Juniper Business Use Only _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod