Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-14.txt> (A YANG Data Model for MPLS Base) to Proposed Standard

[Tarek Saad <[e-mail]>]

Hi Tom,

Thanks. See inline..

    <tp2>
    Tarek
    I am not sure if we are on the same wavelength.  I was looking at the next hop or input augments which go
    augment 
    description [omitted by me last time]
    uses
    when
    so 'when' is a child of uses and makes that conditional whereas the description is not conditional and so will always be added and there is nothing else in the augment for these three cases AFAICT.
    I get the difference between the augment to all RIBs (strictly speaking this is conditional, on if-feature mpls) and the augment specific to AF mpls but still think it should be
    augment
    when
    description
    uses
    so 'when' is a child of augment and so nothing is added when the YANG 'when' evaluates to false.
[TS]: we reviewed the code - and in the snippet below - we believe the uses of the grouping is subject to 'condition-foo' under it evaluating to 'true'.
uses foo {
 when "condition-foo";
}

So, if the description under the "uses" is somewhat misleading, we are propose the below change to the description. Let us know if this addresses your concern.

OLD:
    uses rib-mpls-properties {
      /* MPLS AF aaugmentation to native MPLS RIB */
      when "derived-from-or-self(../../rt:address-family, "
         + "'mpls:mpls')" {
        description
          "This augment is valid only for routes of native MPLS
           RIB.";
      }

NEW:
    uses rib-mpls-properties {
     when "derived-from-or-self(../../rt:address-family, "
        + "'mpls:mpls')" {
       description
         "This grouping is added only for routes of native MPLS
          RIB.";
    }


    Tom Petch.

On 8/24/20, 7:23 AM, "tom petch" <[e-mail]> wrote:

    From: Tarek Saad <[e-mail]>
    Sent: 21 August 2020 22:01

    Hi Tom,

    Thanks again. Please see responses inline..

    On 8/21/20, 12:14 PM, "tom petch" <[e-mail]> wrote:

        From: mpls <[e-mail]> on behalf of Tarek Saad <[e-mail]>
        Sent: 17 August 2020 17:40

        Thanks Acee and Tom.
        I'm merging the discussion on the other thread (titled: [mpls] [netmod] [Technical Errata) and providing the update.
        We have uploaded a new revision https://tools.ietf.org/html/draft-ietf-mpls-base-yang-15 that addresses the comments previously raised.
        Please let us know if there are further comments.

        <tp>
        Tarek

        I think that the YANG 'when' clauses are slightly misplaced.  You have
        augment
        uses
        when
        which makes the 'augment' unconditional and the 'uses' conditioned.  Look at RFC8349 and it has

    [TS]: Indeed, our intent is to make the 'augment' unconditional (applicable to all RIBs) and the specific grouping 'uses' conditional.
    For example in the below snippet below, the leafs 'mpls-enabled' and 'local-label' are unconditionally augmented to all RIBs, but ' destination-prefix' of 'rib-mpls-properties ' is only applicable to native MPLS RIB - address-family=mpls).

    <tp2>
    Tarek
    I am not sure if we are on the same wavelength.  I was looking at the next hop or input augments which go
    augment 
    description [omitted by me last time]
    uses
    when
    so 'when' is a child of uses and makes that conditional whereas the description is not conditional and so will always be added and there is nothing else in the augment for these three cases AFAICT.
    I get the difference between the augment to all RIBs (strictly speaking this is conditional, on if-feature mpls) and the augment specific to AF mpls but still think it should be
    augment
    when
    description
    uses
    so 'when' is a child of augment and so nothing is added when the YANG 'when' evaluates to false.

    Tom Petch.

      augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
        if-feature "mpls";
        description
          "This augmentation is applicable to all MPLS routes.";
        leaf mpls-enabled {
          type boolean;
          default "false";
          description
            "Indicates whether MPLS is enabled for this route.";
        }
        leaf local-label {
          when "../mpls-enabled = 'true'";
          type rt-types:mpls-label;
          description
            "MPLS local label associated with the route.";
        }
        uses rib-mpls-properties {
          /* MPLS AF aaugmentation to native MPLS RIB */
          when "derived-from-or-self(../../rt:address-family, "
             + "'mpls:mpls')" {
            description
              "This augment is valid only for routes of native MPLS
               RIB.";
          }
        }
      }     .

        augment
        when
        uses

        'present in the AF RIB(s) in the MPLS Architecture'
        I do not understand.  RFC3031 does not use 'RIB' nor 'AF' nor do I think the terms were in use then.  RIB v routing table was a contentious point in the genesis of RFC8349 and I think we should only talk of RIBs when we use it in the RFC8349 sense.  I think you are saying that all routes in all RIBS are augmented with the label information needed for MPLS forwarding but I do not see that in the words.
    [TS]: Yes, your reading is correct. I tried to clarify this in section 2.1 and illustrated it in section 2.3 (see below):

    >>>>
    2.1.  Model Overview

       This document models MPLS labeled routes as an augmentation of the
       generic routing RIB data model as defined in [RFC8349].  For example,
       IP prefix routes (e.g. routes stored in IPv4 or IPv6 RIBs) are
       augmented to carry additional data to enable it for MPLS forwarding.
    <<<<

    >>>>
    2.3.  Model Design
    ....
                                    +-----------------+
                                    | MPLS base model |
                                    +-----------------+
                                  ____/  |  |_____  |________
                                 /       |        \          \
                                /        |         \          \
                               o         o          o          +
                        +---------+  +---------+  +--------+ +-----------+
                        | RIB(v4) |  | RIB(v6) |  | RIB(x) | | RIB(mpls) |
                        +---------+  +---------+  +--------+ +-----------+


               +: created by the MPLS base model
               o: augmented by the MPLS base model

            Figure 2: Relationship between MPLS model and RIB instances

       As shown in Figure 2, the MPLS base YANG model augments defined
       instance(s) of AF RIB(s) with additional data that enables MPLS
       forwarding for destination prefix(es) store in such RIB(s).  For
       example, an IPv4 prefix stored in RIB(v4) is augmented to carry a
    <<<<

        (!RFC8349})

        RFC6991 needs adding to the Normative References
    [TS]: thanks, will be corrected.


        leaf start-label
        must '. >= ../end-label'
        "The start label must be less than or equal to end-label"
        umm

        augment .../route
        if-feature "mpls";
        "This augmentation is applicable to all MPLS routes"
        true but incomplete IMHO
        "This augmentation is applicable to all routes in all RIBs on a device with the feature MPLS enabled"
        and I think this important in understanding what the YANG is trying to do, which I did not with -14
    [TS]: ack, I can update this description accordingly.

        /aaugmentation/augmentation/
    [TS]: thanks for reporting this.

    Regards,
    Tarek

        I am still digesting this I-D.  I am not clear what the plans of the AD are right now in terms of timescale.

        In passing, I pointed out to the BFD WG that their YANG model stopped being compatible with the MPLS YANG model in 2018, when /config got removed from /mpls/interface.  They are having a closer look.

        Tom Petch

        Regards,
        Tarek (for co-authors)

        On 8/6/20, 4:31 AM, "tom petch" <[e-mail]> wrote:


            This I-D breaks a MUST in RFC8349 Routing Management) and, as such, will
            not interoperate with devices that implement RFC8349 correctly.

            RFC8349 provides a YANG action to return the active route for a
            destination address but omits the destination address, saying that
            modules using this must augment the input with a leaf
            destination-address.  This I-D augments the input with a leaf
            local-label so implementations of RFC8349 that 'know' there will be a
            leaf destination-address will fail to interoperate with this I-D.

            The authors said, at WGLC, that RFC8349 is wrong, that MPLS has label
            not address and so the I-D must provide an augment with a label and
            RFC8349 should change.  I disagree; I think that this is reading too
            many semantics into an identifier.

            Tom Petch

            On 05/08/2020 18:04, The IESG wrote:
            >
            > The IESG has received a request from the Multiprotocol Label Switching WG
            > (mpls) to consider the following document: - 'A YANG Data Model for MPLS Base'
            >    <draft-ietf-mpls-base-yang-14.txt> as Proposed Standard
            >
            > The IESG plans to make a decision in the next few weeks, and solicits final
            > comments on this action. Please send substantive comments to the
            > [e-mail] mailing lists by 2020-08-19. Exceptionally, comments may
            > be sent to [e-mail] instead. In either case, please retain the beginning
            > of the Subject line to allow automated sorting.
            >
            > Abstract
            >
            >
            >     This document contains a specification of the MPLS base YANG model.
            >     The MPLS base YANG model serves as a base framework for configuring
            >     and managing an MPLS switching subsystem on an MPLS-enabled router.
            >     It is expected that other MPLS YANG models (e.g.  MPLS Label Switched
            >     Path (LSP) Static, LDP or RSVP-TE YANG models) will augment the MPLS
            >     base YANG model.
            >
            >
            >
            >
            > The file can be obtained via
            > https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/
            >
            >
            >
            > No IPR declarations have been submitted directly on this I-D.
            >
            >
            >
            >
            >
            > _______________________________________________
            > IETF-Announce mailing list
            > [e-mail]
            > https://www.ietf.org/mailman/listinfo/ietf-announce
            > .
            >
        _______________________________________________
        mpls mailing list
        [e-mail]
        https://www.ietf.org/mailman/listinfo/mpls