Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[tom petch <[e-mail]>]

Tarek

Picking up on an earlier point,

________________________________________
From: Tarek Saad <[e-mail]>
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".

<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)" <[e-mail]> 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)" <[e-mail]> 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 <[e-mail]>
        > Sent: 10 August 2020 17:32
        > To: RFC Errata System <[e-mail]>; [e-mail]; Acee
        > Lindem (acee) <[e-mail]>; [e-mail]; [e-mail];
        > Rob Wilton (rwilton) <[e-mail]>; [e-mail];
        > [e-mail]; [e-mail]
        > Cc: [e-mail]; [e-mail]
        > Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
        >
        > From: netmod <[e-mail]> on behalf of RFC Errata System
        > <[e-mail]>
        > 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 <[e-mail]>
        >
        > 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
        > [e-mail]
        > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxxyc2_LZA$



Juniper Business Use Only