Re: [mpls] Structure of draft-ietf-mpls-static-yang

[tom petch <[e-mail]>]

Tarek,

On address family, I think that this is a lost cause, there are too many
of them!

You use the definition in RFC8349 which ties the use of address family
to RIB which seems to mean there will be a mpls RIB distinct from the
ipv4-unicast or ipv6-unicast RIB.  But then the module contains
    when "derived-from-or-self(../../../../../rt:address-family, "
       + "'mpls:mpls')" {
      description
        "This augment is valid only for IPv4 unicast.";
which confuses me - to restrict this to IPv4 unicast, I would expect
       + "'v4ur:ipv4-unicast')" {
but then that does not make it mpls specific - it will augment all
ipv4-unicast routes.  (Should there be a ipv4-unicast-mpls address
family/RIB? I don't think so).

While I have some familiarity with the technology of MPLS (and its
management by SMI), I still struggle to fit MPLS into the framework of
RFC8349, even though MPLS gets a specific mention in that RFC, namely

"   o  The data model should be suitable for the common address families
      -- in particular, IPv4 and IPv6 -- and for unicast and multicast
      routing, as well as Multiprotocol Label Switching (MPLS).
"
Whether that text intends to say that MPLS is an address family, I find
ambiguous.

Meanwhile, I have gone fishing on the netmod WG list.

Tom Petch

----- Original Message -----
From: "t.petch" <[e-mail]>
To: "Tarek Saad (tsaad)" <[e-mail]>; "mpls" <[e-mail]>;
<[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, November 15, 2018 1:00 PM
Subject: Re: Structure of draft-ietf-mpls-static-yang


> 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)" <[e-mail]>
> To: "tom petch" <[e-mail]>; "mpls" <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, November 14, 2018 2:24 PM
> Subject: Re: Structure of draft-ietf-mpls-static-yang
>
>
> > + 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 <[e-mail]>
> > Date: Tuesday, November 13, 2018 at 12:19 PM
> > To: Tarek Saad <[e-mail]>, mpls <[e-mail]>
> > Cc: "[e-mail]"
> <[e-mail]>
> > Subject: Re: Structure of  draft-ietf-mpls-static-yang
> >
> >     ----- Original Message -----
> >     From: "Tarek Saad (tsaad)" <[e-mail]>
> >     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.
> > [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.
> >
> >     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.
> > [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.
> >
> >     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.
> >
> > [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
> >
> >     > Regards,
> >     > Tarek
> >     >
> >     > -----Original Message-----
> >     > From: tom petch <[e-mail]>
> >     > Date: Tuesday, November 13, 2018 at 7:37 AM
> >     > To: Tarek Saad <[e-mail]>, mpls <[e-mail]>
> >     > Cc: "[e-mail]"
> >     <[e-mail]>
> >     > Subject: Structure of  draft-ietf-mpls-static-yang
> >     >
> >     >     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
> >     >
> >     >
> >     >
> >     >
> >
> >
> >
> >
>