Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-05.txt

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Mon, 5 Nov 2018 17:04:19 +0000

Hi Tom,

Thank you much for your review comments. We have addressed your comments in latest revision of the drafts (draft-ietf-mpls-static-yang-07 and draft-ietf-mpls-base-yang-09). Please let us know if you have any further comments or whether you're satisfied with the resolution.

Regards,
Tarek

-----Original Message-----
From: mpls <[email-masked]> on behalf of "t.petch" <[email-masked]>
Date: Friday, February 16, 2018 at 5:55 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-05.txt

    As a YANG module, I think that this needs some - well, quite a lot of -
    work
    
    - Terminology section needs to reference RFC8174
    
    - ietf-netmod-revised-datastores is the correct reference for most of
    the terms in the Terminology section
    
    - ietf-rib needs a reference (ietf-routing is the usual base routing
    module)
    
    - it references YANG 1.0 and not 1.1 - if this is justified, it needs an
    explanation
    
    - it is not NMDA compliant - this needs changing or justifying
    
    - " and augments the MPLS Base YANG model defined in module
       "ietf-mpls" in [I-D.saad-mpls-static-yang].
    
    ietf-mpls does not appear an the referenced I-D
    
    - the I-D has five authors, the YANG module has ten
    
    - the module lacks a copyright clause
    
    - the imports need references, best provided with a reference clause for
    each,  and again in the text of the I-D and in the I-D References
    section
    see
    draft-ietf-ccamp-alarm-module
    for an example of this
    
    - good practice is to list the prefix used and the RFC in which they can
    be found somewhere in the text of the I-D
    draft-ietf-netmod-rfc8022bis
    has an example of this
    
    - the YANG module needs a reference back to the RFC in which it appears
    along with a note to the RC editor to replace XXXX with the relevant
    number - you have a reference to RFC3031 which is sadly mistaken
    
    - If a reference to RFC3031 is warranted, then it needs to appear in the
    text of the I-D and in the References section
    
    - static-extended - same comments
    
    - Security Considerations needs updating - it needs to call out the
    vulnerable objects
    
    Tom Petch
    
    ----- Original Message -----
    From: <[email-masked]>
    To: <[email-masked]>
    Cc: <[email-masked]>
    Sent: Thursday, February 15, 2018 5:42 PM
    Subject: I-D Action: draft-ietf-mpls-static-yang-05.txt

    >
    > A New Internet-Draft is available from the on-line Internet-Drafts
    directories.
    > This draft is a work item of the Multiprotocol Label Switching WG of
    the IETF.
    >
    >         Title           : A YANG Data Model for MPLS Static LSPs
    >         Authors         : Tarek Saad
    >                           Kamran Raza
    >                           Rakesh Gandhi
    >                           Xufeng Liu
    >                           Vishnu Pavan Beeram
    > Filename        : draft-ietf-mpls-static-yang-05.txt
    > Pages           : 20
    > Date            : 2018-02-15
    >
    > Abstract:
    >    This document contains the specification for the MPLS Static Label
    >    Switched Paths (LSPs) YANG model.  The model allows for the
    >    provisioning of static LSP(s) on LER(s) and LSR(s) devices along a
    >    LSP path without the dependency on any signaling protocol.  The
    MPLS
    >    Static LSP model augments the MPLS base YANG model with specific
    data
    >    to configure and manage MPLS Static LSP(s).
    >
    >
    > The IETF datatracker status page for this draft is:
    > https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/
    >
    > There are also htmlized versions available at:
    > https://tools.ietf.org/html/draft-ietf-mpls-static-yang-05
    > https://datatracker.ietf.org/doc/html/draft-ietf-mpls-static-yang-05
    >
    > A diff from the previous version is available at:
    > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-static-yang-05
    >
    >
    > Please note that it may take a couple of minutes from the time of
    submission
    > until the htmlized version and diff are available at tools.ietf.org.
    >
    > Internet-Drafts are also available by anonymous FTP at:
    > ftp://ftp.ietf.org/internet-drafts/
    >
    > _______________________________________________
    > I-D-Announce mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/i-d-announce
    > Internet-Draft directories: http://www.ietf.org/shadow.html
    > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
    
    _______________________________________________
    mpls mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mpls

---

From: tom petch <[email-masked]>
Date: Wed, 7 Nov 2018 09:38:14 +0000

Getting there

The convention is to limit editors to five, lest there is no room for
anything else on page one.  Some ADs are more aggressive on this than
others but seven is likely to draw comment; the usual technique is to
have
one name as (Editor) and list the others at the end.  If you want more
than five, then you will likely be asked to justify that they all made
significant contributions

Abstract

You will likely be asked to expand LER and LSR on first use.  I do not
think that they are well enough known IETF-wide to not need expanding.
An Abstract needs to be understandable on its own without recourse to
the Definitions section

Introduction

The MPLS Static LSP YANG model is broken !
The MPLS Static LSP YANG model is divided
would be better IMHO

 module ietf-mpls-static

   import ietf-mpls { ..  reference "draft-ietf-mpls-base-yang: MPLS
Base YANG Data Model";
You are asking the RFC-Editor to notice and replace this I-D name;
better to have
     reference "RFC YYYY: MPLS Base YANG Data Model";
with a note up front

// RFC Ed.: replace YYYY with RFC number assigned to
draft-ietf-mpls-base-yang
and remove this note

-  prefix "rt-types";  reference "RFC6991:
Right prefix, wrong RFC. Hint look at s.2.3:-)

   import ietf-te { ... reference "draft-ietf-teas-yang-te: A YANG Data
Model for Traffic Engineering Tunnels and Interfaces";
same idea but make it ZZZZ

   reference "RFC ZZZZ: A YANG Data Model for Traffic
                Engineering Tunnels and Interfaces";

and up front

// RFC Ed.: replace ZZZZ with RFC number assigned to
draft-ietf-teas-yang-te:
and remove this note

(Some editors use XXXX for all such I-Ds which I do not think very
helpful:-(

Figure 3: MPLS Static LSP YANG module
It is unusual to label YANG modules as Figures.

module ietf-mpls-static-extended

  import ietf-mpls { ...    reference "draft-ietf-mpls-base-yang: MPLS
Base YANG Data Model";

See above

  import ietf-routing {prefix "rt";
    reference "RFC6991: Common YANG Data Types";
See above

reference "draft-ietf-mpls-static-yang
reference "RFC XXXX
(you already have notes to replace XXXX)

Figure 4: Extended MPLS Static LSP YANG module
Again not wrong but unusual

Security Considerations
is not the current template since it lacks reference to RESTCONF which
then needs to be a Normative Reference

Also, it is weak in that it does not identify the nodes that need
protecting.  Here it is probably enough to say
'All nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default) may be considered sensitive or vulnerable
   in some network environments

draft-ietf-ccamp-mw-yang is an example of a more comprehensive analysis.

Tom Petch

----- Original Message -----
From: "Tarek Saad (tsaad)" <[email-masked]>
Sent: Monday, November 05, 2018 5:04 PM

> Hi Tom,
>
> Thank you much for your review comments. We have addressed your
comments in latest revision of the drafts
(draft-ietf-mpls-static-yang-07 and draft-ietf-mpls-base-yang-09).
Please let us know if you have any further comments or whether you're
satisfied with the resolution.

---

From: tom petch <[email-masked]>
Date: Sat, 10 Nov 2018 13:07:48 +0000

Tarek

A different and orthogonal question.  What is MPLS?

This I-D augments but has no associated conditional statement, 'when' or
if, which is unusual so
   augment "/rt:routing/mpls:mpls" {  container static-lsps {
will always add static-lsps if the YANG module is present and
  augment "/rt:routing/mpls:mpls/mpls-static:static-lsps" {
will always add extended which makes me wonder why there are separate
modules.

A similar question applies to base-yang which defines mpls as an address
family but does not use the previously defined mpls and mplstunnel
interface types.  It augments regardless, when other such modules have a
feature defined and then use if-feature to make the augments
conditional.

The mpls base augments to the routes uses the address family but not the
interface types.

So in generic IETF terms, what is mpls?  Address family, interface type,
feature, tunnel type?  And should e.g. static be separate, derived from
one of the base definitions?  Ditto extended.

Expert as the participants of the NETMOD WG are, I would not assume that
that expertise extends to MPLS, for many if not most of them (yes, I
know, there are exceptions) so IMHO you need to decide what you want and
then, if necessary, seek guidance in how to turn that into the DDL.

Tom Petch

----- Original Message -----
From: "tom petch" <[email-masked]>
To: "Tarek Saad (tsaad)" <[email-masked]>; "mpls" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>
Sent: Wednesday, November 07, 2018 9:38 AM

> >     As a YANG module, I think that this needs some - well, quite a
lot
> of -
> >     - ietf-netmod-revised-datastores is the correct reference for
most
> of
> >     - If a reference to RFC3031 is warranted, then it needs to
appear
> in the

---

From: tom petch <[email-masked]>
Date: Tue, 13 Nov 2018 12:37:50 +0000

I wonder if the IETF has yet worked out how to model routing protocols.
I asked, what is MPLS?  Looking at various modules, I see

RIP
     augment /routing/control-plane-protocols/control-plane-protocol:
       +--rw rip
          +--rw interfaces

OSPF
     augment /routing/control-plane-protocols/control-plane-protocol:
       +--rw ospf
          +--rw areas
          |  +--rw area* [area-id]
          |     +--rw interfaces

the other IxxxGP
  module: ietf-ixxx
    augment /routing/ribs/rib/routes/route:
      +--ro route-type?   enumeration
    augment /interfaces/interface:
      +--rw clns-mtu?   uint16
    augment /routing/control-plane-protocols/:control-plane-protocol:
      +--rw ixxx
         +--rw enable?                   boolean {admin-control}?
         +--rw system-id?                system-id
         +--rw area-address*             area-address

BGP
     augment "/routing-policy/defined-sets"
    module ietf-bgp {
           +--rw bgp!
             +--rw global
                +--rw afi-safis
                   +--rw afi-safi* [afi-safi-name]
                      +--rw ipv4-unicast
                      +--rw ipv6-unicast
                      +--rw l3vpn-ipv4-unicast

PIM
module: ietf-pim-base
     augment /routing/control-plane-protocols:
       +--rw pim!
          +--rw address-family* [address-family]
          |  +--rw address-family        identityref
          |  +--rw <per address family configuration>
          +--rw interfaces
             +--rw interface* [name]
                +--rw name              if:interface-ref
                +--rw address-family* [address-family]

MPLS

module: ietf-mpls
  augment /rt:routing:
    +--rw mpls
  augment /routing/ribs/rib/routes/:route:
    +--ro local-label?   rt-types:mpls-label
  augment
/routing/ribs/rib/routes/route/next-hop/next-hop-options/simple-next-hop
:
 ....
  identity mpls { base address-family;

Different! which is right?  Perhaps none of them.  It is very early days
for routing YANG modules, no RFC, limited experience.  I am mindful that
it took several years after the publication of the initial system YANG
modules for the advent of NDMA - a radically different approach - so
perhaps in a few years we will be looking at the routing modules and say
it needs a different approach.  Sigh

Tom Petch

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Tue, 13 Nov 2018 16:31:26 +0000

Hi Tom,

Thanks. To me, RIP/OSPF/PIM/BGP are all control plane protocols and would think should exist below /routing/control-plane-protocols.
MPLS on the contrary is a forwarding augmentation to existing V4/V6 routing table(s) (which are already defined at path  /routing/ribs/rib/routes/route/next-hop ) - the MPLS augmentation carries additional mpls specific data.
There are signaling control plane protocols specific to exchange MPLS labels (e.g. RSVP-TE, LDP) which I expect will exist at /routing/control-plane-protocols/control-plane-protocol (e.g. draft-ietf-teas-yang-rsvp)

Regards,
Tarek

-----Original Message-----
From: tom petch <[email-masked]>
Date: Tuesday, November 13, 2018 at 7:37 AM
To: Tarek Saad <[email-masked]>, mpls <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Structure of  draft-ietf-mpls-static-yang

    RIP
    
    OSPF
    
    the other IxxxGP
      module: ietf-ixxx
    
    BGP
    
    PIM
    module: ietf-pim-base
    
    MPLS
    
    module: ietf-mpls
      augment /rt:routing:
        +--rw mpls

    Tom Petch

---

From: tom petch <[email-masked]>
Date: Tue, 13 Nov 2018 17:19:34 +0000

----- Original Message -----
From: "Tarek Saad (tsaad)" <[email-masked]>
Sent: Tuesday, November 13, 2018 4:31 PM

> Hi Tom,
>
> Thanks. To me, RIP/OSPF/PIM/BGP are all control plane protocols and
would think should exist below /routing/control-plane-protocols.
> MPLS on the contrary is a forwarding augmentation to existing V4/V6
routing table(s) (which are already defined at path
/routing/ribs/rib/routes/route/next-hop ) - the MPLS augmentation
carries additional mpls specific data.
> There are signaling control plane protocols specific to exchange MPLS
labels (e.g. RSVP-TE, LDP) which I expect will exist at
/routing/control-plane-protocols/control-plane-protocol (e.g.
draft-ietf-teas-yang-rsvp)

Tarek

Yes, so BGP is out of line, but that is a problem for another WG.

The MPLS quirks are IMHO twofold.

Why define an address family?  I always think of AFI/SAFI when someone
says address family and I do not see MPLS figuring in that context.

Second, what are MPLS and MPLStunnel doing in the Interface Table?  Ok,
they are a carry over from the MIB but do they have any role here?

I am fishing for some 'when' (or if-feature) statements alongside the
'augment'
to make the augment conditional (although perhaps not as many as TEAS
created:-).  Instinctively I feel there should be something as e.g. OSPF
has although accepting your point about MPLS not being a protocol; but
then mpls-ldp is a protocol but has no conditionals that I can see.

At a slight tangent, I see in OSPF and others references such as
       container mpls {
         description "OSPF MPLS config state.";
         container te-rid {
           if-feature te-rid;
ie conditional but not on MPLS per se.

Tom Petch

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Wed, 14 Nov 2018 14:24:24 +0000

+ draft-ietf-ospf-yang authors
+ teas alias to comment on the utility of TE router-ID in the OSPF YANG model for other non-MPLS technologies too.

Hi Tom,

Inline..

-----Original Message-----
From: tom petch <[email-masked]>
Date: Tuesday, November 13, 2018 at 12:19 PM
To: Tarek Saad <[email-masked]>, mpls <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Structure of  draft-ietf-mpls-static-yang

    ----- Original Message -----
    From: "Tarek Saad (tsaad)" <[email-masked]>
    Sent: Tuesday, November 13, 2018 4:31 PM

    Tarek

    
    Why define an address family?  I always think of AFI/SAFI when someone
    says address family and I do not see MPLS figuring in that context.
[TS]: MPLS can augment routes in the V4/V6 AFI routing tables defined in RFC8349. However, there are other type of MPLS routes (cross-connects) that are not associated with an IP prefix or an AFI defined in RFC8349. Examples of such routes can be RSVP-LSP labels/cross-connects, per L2 or L3 VRF de-aggregation labels, etc.).. Such routes will exist in the new MPLS AFI table.
    
    Second, what are MPLS and MPLStunnel doing in the Interface Table?  Ok,
    they are a carry over from the MIB but do they have any role here?
[TS]: currently, this is enabling MPLS on the specific (sub)set of interfaces and setting minimal set of attributes - e.g. MPLS MTU.
    
[TS]: I think the assumption was MPLS is a base functionality that most router vendors will support - so we've avoided an if-feature check. However, I can see that some devices may not support MPLS (or may not turn MPLS), so we can look into adding a when or feature check to control augments to external YANG models. For MPLS LDP, yes, I think they can add the same for signaling MPLS. However, I am aware LDP protocol can be used for non-MPLS signaling too (e.g. ICCP) - so the LDP YANG modeling team may need to look at what augments can be controlled/associated with MPLS.

[TS]: Yes, although traditionally enabled for MPLS-TE, the TE router-ID can apply to non-MPLS technologies too (e.g. for GMPLS OTN, etc.).. IMO, Ideally this would not need to exist under mpls container.. We may need to raise this with OSPF team.

Regards,
Tarek
    
    Tom Petch

---

From: tom petch <[email-masked]>
Date: Thu, 15 Nov 2018 13:02:41 +0000

Tarek

Thanks for the explanation.  I did some more digging on Address Families
and have posted my thoughts to rtgwg; any one WG looks fine, look across
the Routing Area and I think the work would benefit from more
coordination.

On the more specific topic of this I-D, there are already several
definitions of mpls address families e.g.
   identity mpls-address-family {
   base "address-family";      description "MPLS RIB address family."; }
in
 draft-ietf-i2rs-rib-data-model

and that may be a challenge to resolve.

Tom Petch

----- Original Message -----
From: "Tarek Saad (tsaad)" <[email-masked]>
To: "tom petch" <[email-masked]>; "mpls" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 14, 2018 2:24 PM
Subject: Re: Structure of draft-ietf-mpls-static-yang

> + teas alias to comment on the utility of TE router-ID in the OSPF
YANG model for other non-MPLS technologies too.
> [TS]: MPLS can augment routes in the V4/V6 AFI routing tables defined
in RFC8349. However, there are other type of MPLS routes
(cross-connects) that are not associated with an IP prefix or an AFI
defined in RFC8349. Examples of such routes can be RSVP-LSP
labels/cross-connects, per L2 or L3 VRF de-aggregation labels, etc.)..
Such routes will exist in the new MPLS AFI table.
> [TS]: currently, this is enabling MPLS on the specific (sub)set of
interfaces and setting minimal set of attributes - e.g. MPLS MTU.
> [TS]: I think the assumption was MPLS is a base functionality that
most router vendors will support - so we've avoided an if-feature check.
However, I can see that some devices may not support MPLS (or may not
turn MPLS), so we can look into adding a when or feature check to
control augments to external YANG models. For MPLS LDP, yes, I think
they can add the same for signaling MPLS. However, I am aware LDP
protocol can be used for non-MPLS signaling too (e.g. ICCP) - so the LDP
YANG modeling team may need to look at what augments can be
controlled/associated with MPLS.
> [TS]: Yes, although traditionally enabled for MPLS-TE, the TE
router-ID can apply to non-MPLS technologies too (e.g. for GMPLS OTN,
etc.).. IMO, Ideally this would not need to exist under mpls container..
We may need to raise this with OSPF team.
>     >     Different! which is right?  Perhaps none of them.  It is
very
>     early days
>     >     it took several years after the publication of the initial
system
>     YANG
>     >     modules for the advent of NDMA - a radically different
approach -
>     so
>     >     perhaps in a few years we will be looking at the routing
modules
>     and say