Hi Acee, Tarek, Tom,
Thank for all for your time and help in resolving this issue.
I will reject the erratum.
Regards,
Rob
> -----Original Message-----
> From: Tarek Saad <tsaad....@gmail.com>
> Sent: 14 August 2020 17:30
> To: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; Tarek Saad
> <ts...@juniper.net>; tom petch <ie...@btconnect.com>; Rob Wilton (rwilton)
> <rwil...@cisco.com>; RFC Errata System <rfc-edi...@rfc-editor.org>;
> lho...@nic.cz; yingzhen...@huawei.com; war...@kumari.net
> Cc: m...@ietf.org; netconf-cha...@ietf.org; netmod@ietf.org; draft-ietf-
> mpls-base-y...@ietf.org
> Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251)
>
> Thanks Acee. Yes, will do in the next rev we'll push soon.
>
> Regards,
> Tarek
>
> On 8/14/20, 12:29 PM, "mpls on behalf of Acee Lindem (acee)" <mpls-
> boun...@ietf.org on behalf of acee=40cisco....@dmarc.ietf.org> wrote:
>
> Hi Tarek,
> Can you also add the description of the native MPLS RIB to the text?
> Thanks,
> Acee
>
> On 8/14/20, 12:27 PM, "mpls on behalf of Acee Lindem (acee)" <mpls-
> boun...@ietf.org on behalf of acee=40cisco....@dmarc.ietf.org> wrote:
>
> Hi Tarek,
> This works for me.
> Thanks,
> Acee
>
> On 8/14/20, 12:25 PM, "Tarek Saad" <ts...@juniper.net> wrote:
>
> Hi Acee and Tom,
>
> The authors of ID: draft-ietf-mpls-base-yang met and we
> discussed the points below.
> We understand that RFC8349 defines an AF-agnostic model for
> RIBs. RFC8349 defined only two types of RIBs (IPv4 and IPv6 RIBs), but we
> envision other types of RIBs too (e.g. L2 RIB, MCAST RIB, etc.), in
> addition to MPLS RIB -- and we hope all such RIBs indeed leverage the
> generic RIB model introduced in RFC8349.
>
> We revisited Acee's suggestion and made a small modification
> (on top of it) that makes IP routes, MPLS routes (and possibly L2 or MCAST
> routes in future) - all have similar MPLS augmentation (in terms of local-
> label) while still adhering with RFC8349 to augment with leaf destination-
> prefix.
>
> augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
> when "derived-from-or-self(../../rt:address-family, "
> + "'mpls:mpls')" {
> description
> "This augment is valid only for native MPLS routes.";
> }
> description
> "This leaf augments a native MPLS route.";
> leaf destination-prefix {
> type leafref {
> path "../local-label";
> }
> description
> "MPLS destination prefix.";
> }
> }
>
> We follow same approach for the active route RPC and continue
> to use a leaf "destination-address" as input (that points to a local-label
> leaf).
> If this is acceptable, we believe the errata 6251 can be
> rejected and we'll proceed with the change in the MPLS RIB model.
>
> Regards,
> Tarek (for authors)
>
> On 8/11/20, 9:08 AM, "Acee Lindem (acee)" <a...@cisco.com>
> wrote:
>
> [External Email. Be cautious of content]
>
>
> 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.
>
> Thanks,
> Acee
>
> On 8/11/20, 6:10 AM, "tom petch" <ie...@btconnect.com>
> wrote:
>
> From: Acee Lindem (acee) <a...@cisco.com>
> 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" <ie...@btconnect.com>
> wrote:
>
> Tarek
>
> Picking up on an earlier point,
>
> ________________________________________
> From: Tarek Saad <ts...@juniper.net>
> 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)"
> <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-editor@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
>
>
>
> Juniper Business Use Only
>
>
> Juniper Business Use Only
>
> _______________________________________________
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
