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

["Acee Lindem (acee)" <[e-mail]>]

Hi Tarek, 

On 8/10/20, 7:27 PM, "Tarek Saad" <[e-mail]> wrote:

    Hi Acee,

    Are you checking https://tools.ietf.org/html/draft-ietf-mpls-base-yang-14?
    If so, Figure 2 shows the module is augmenting IPv4/IPv6 AFI with MPLS for paths - check the paths
    augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
    augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
    augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop:

    You'll notice the MPLS augmentation above is applicable for all RIB types (including IPv4/IPv6 and the new AFI introduced by this module). The MPLS augmentation for IPv4/IPv6 RIBs are specific to IP prefixes that are MPLS enabled.

That is how I originally interpreted this augmentation. Precisely, what constitutes a route with MPLS enabled? Is it any route for the which the MPLS augmentations are applicable or only routes on which they are present?  

    You'll also notice draft-ietf-mpls-base-yang is defining a new RIB address-family for MPLS as per section 3 in RFC8349 (search for "identity mpls" in YANG module).
    The new MPLS RIB address-family is meant for "non IP" MPLS routes (e.g. MPLS routes installed by RSVP on transit nodes, cross-connects, etc.).

Then what is missing is an augmentation for the destination-prefix that is specific to the MPLS AFI. You should not be overloading the local-label which applicable to all AFIs is also the destination-prefix for the MPLS AFI. 

     
     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 an native MPLS route.";
       leaf destination-prefix {
         type rt-types:mpls-label;
         description
           "MPLS destination prefix.";
       }
     }

    Given the above, can you take another look and let us know?

I think you must follow the AFI specific augmentations set forth in RFC 8349. It is not for the augmenting models to break these conventions

One more nit, why is label-block_state not label-block-state? 

Thanks,
Acee





    Regards,
    Tarek


    On 8/10/20, 4:39 PM, "Acee Lindem (acee)" <[e-mail]> wrote:

        [External Email. Be cautious of content]


        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" <[e-mail]> 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)" <[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


        Juniper Business Use Only


    Juniper Business Use Only