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

[tom petch <[e-mail]>]

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
>     >
>     >
>     >
>     >
>
>
>
>