Folks, Many messages for this thread are being blocked by the list server, requiring manual effort by the chairs to release them. Here are the headers from one such message:
To: Tarek Saad <[email protected]>, tom petch <[email protected]>, "Rob Wilton (rwilton)" <[email protected]>, RFC Errata System <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> CC: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> At a minimum, I suggest removing [email protected] and [email protected] in your next Reply-All. Thanks! PS: I’ll release the messages stuck in the queue now. Kent Pending posts: From: [email protected] <mailto:[email protected]> on Fri Aug 14 09:25:03 2020 Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251) Cause: Too many recipients to the message From: [email protected] <mailto:[email protected]> on Fri Aug 14 09:27:16 2020 Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251) Cause: Too many recipients to the message From: [email protected] <mailto:[email protected]> on Fri Aug 14 09:29:05 2020 Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251) Cause: Too many recipients to the message From: [email protected] <mailto:[email protected]> on Fri Aug 14 09:30:28 2020 Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251) Cause: Too many recipients to the message From: [email protected] <mailto:[email protected]> on Fri Aug 14 09:41:14 2020 Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251) Cause: Too many recipients to the message From: [email protected] <mailto:[email protected]> on Fri Aug 14 10:38:23 2020 Subject: RE: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251) Cause: Too many recipients to the message K. > On Aug 14, 2020, at 7:45 AM, tom petch <[email protected]> wrote: > > From: Acee Lindem (acee) <[email protected] <mailto:[email protected]>> > Sent: 11 August 2020 14:08 > > Hi Tom, Draft Authors, > > The draft could easily be fixed. You just need to: > > 1. Expand on the single sentence in section 2.1 on the need for non-IP MPLS > routes. Given that the draft wasn't modeled correctly, this wasn't apparent > to most of the reviewers. > 2. Add an MPLS AF only augmentation (enforced via a when statement) to each > route for the MPLS AF specific destination-prefix or destination-address. > 3. Limit the current local-label augmentation to non-MPLS AFs. > 4. Limit the active-route augmentation to AF MPLS and change the input to > destination-address. > > <tp> > 'easily' mmm... I have been getting my mind around this and see what Acee > means and agree. The I-D specifies an MPLS address family but then does not > create the RIB entries for it in the way that e.g. IPv4 unicast does in > RFC8349. Easy may be but quite a change Another option, again a significant > change, would be to cater only for IP address family with MPLS and drop the > MPLS address family. Either way, whatever the authors decide, I cannot > personally see this falling within the scope or an Erratum or for the IETF > Last Call to complete in a week's time. > > I have dropped the RFC Editor and netconf-chairs pro tem > > Tom Petch > > Thanks, > Acee > > On 8/11/20, 6:10 AM, "tom petch" <[email protected]> wrote: > > From: Acee Lindem (acee) <[email protected]> > Sent: 11 August 2020 10:47 > > Hi Tom, > I fully understood your original comment. There are other problems with > this model. See inline. > > On 8/11/20, 4:59 AM, "tom petch" <[email protected]> wrote: > > Tarek > > Picking up on an earlier point, > > ________________________________________ > From: Tarek Saad <[email protected]> > Sent: 10 August 2020 21:23 > > 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". > > It is not reusable as is since the augmentation RPC augmentation must have > a when statement restricting it to AF MPLS. Also, local-label is a leaf which > is applicable to all address families. It cannot be the AF MPLS > destination-prefix. This augmentation is missing. > > <tp> > I am probably getting out of my depth here, On 1may20 I raised the issue > of why the 'MUST' in the description in RFC8349 was not enforced in the YANG > and 5may20 Martin explained that there is a rule in the YANG ABNF of > input-stmt that makes the obvious impossible:-( You are raising more > profound issues about the RIB that I had not perceived when I reviewed > mpls-base-yang for which I, and I hope everyone else, will be grateful. > > If this mpls I-D is to proceed in the immediate future, it looks like the > action may have to be deferred for future study. > > More generally, I think that the interaction of forward by address and > forward by label is challenging. When first I looked at the MPLS I-D I was > surprised at the way RFC8349 was augmented. I had not seen MPLS as an > alternative to IPv4 or IPv6 or ... in the way in which the RFC is used > although the RFC does state that it can be; rather, to me, labels are a > different animal, but I assumed that everyone knew what they were doing. > > Tom Petch > > > Thanks, > Acee > > > <tp> > There should be a 'when' check to enforce the 'MUST' but the rules of > YANG do not allow it in this structure. I raised this on the NETMOD list at > the time of WGLC and Martin pointed me to a rule in the ABNF which prohibits > such a check. He also said that the rule was not needed and would be a > candidate to remove when YANG is revised. > > Hence I have always thought of this MUST in the documentation as a > constraint that must be enforced in the YANG > > Tom Petch >> 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)" <[email protected]> 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)" <[email protected]> > 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 <[email protected]> >> Sent: 10 August 2020 17:32 >> To: RFC Errata System <[email protected]>; [email protected]; Acee >> Lindem (acee) <[email protected]>; [email protected]; [email protected]; >> Rob Wilton (rwilton) <[email protected]>; [email protected]; >> [email protected]; [email protected] >> Cc: [email protected]; [email protected] >> Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251) >> >> From: netmod <[email protected]> on behalf of RFC Errata System >> <[email protected]> >> 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 <[email protected]> >> >> 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 >> [email protected] >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxxyc2_LZA$ > > > > Juniper Business Use Only > > > _______________________________________________ > netmod mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
