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

[tom petch <[e-mail]>]

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