Subject: [mpls] discussion on a common top for yang models related to MPLS

From: Loa Andersson <[email-masked]>
Date: Fri, 5 Feb 2016 20:34:21 +0800

All,

We have had discussion among the MPLS, TEAS and CCAMP working group
chairs - but as individual contributors, with chair half off. We agree
that this discussion should be taken to the working group(s).

The YANG models for MPLS and GMPLS are quite rapidly taking shape. MPLS
and GMPLS technologies have traditionally been very close, but their
development has been a bit disjoint. For the YANG models we would like
to minimize duplication of models/work and think the structure should
have a common the top,  with specific technologies augmented below.

The structure in general as well as the YANG model at the common top
needs to be the generic and aligned across the output of at least
CCAMP, MPLS and TEAS working groups. There has been good work 
progressing on TE specifics, e.g., see draft-ietf-teas-yang-te, but
other areas remain. On the LDP side of the house draft-raza-mpls-
ldp-mldp-yang is rapidly progressing towards working group adoption.

The models defined in draft-saad-mpls-static-yang could serve as the
start on filling some of the remaining gaps; covering core xMPLS
definitions and static LSPs.  There are a number of ways to make the
structure intuitive and generic, and serve as a foundation for
technology specific models.  -- This effort can be viewed as the same
type of work that was done for TE, see draft-ietf-teas-yang-te.

We think it would be a good idea  if the authors and the  WG considers
how to structure xMPLS definitions and static LSPs models to best
foster common use across the different related models being worked on 
across  different WGs.

We are sending this mail in hopes of getting this discussion started.

Thank you,
Lou and Loa
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 5 Feb 2016 13:58:04 +0000

Loa,

I definitely agree (co-author hat off, and user hat on). Avoiding duplication and doing better organization would indeed be a good thing to do.   

1) If MPLS base model (and subsequent models - LDP, TE etc.) augments the (IP) routing/routing-protocol, then it might not well apply to GMPLS. Is there an existing thought-process on this topic? 

Either ignore the above and have GMPLS argument mpls base model, or get MPLS base on an independent path (off of (IP) routing/routing-protocol).

2) In terms of hierarchy, is the below envisioned?

	MPLS base => Static LSP and dynamic LSP
		MPLS static LSP => 
		MPLS dynamic LSP => 	
			LDP
			mLDP (MP)
			TE (RSVP-TE P2P)
			TE (RSVP-TE P2MP)			    

-- 
Cheers,
Rajiv  

-----Original Message-----
From: mpls <[email-masked]> on behalf of Loa Andersson <[email-masked]>
Date: Friday, February 5, 2016 at 7:34 AM
To: "[email-masked]" <[email-masked]>
Subject: [mpls] discussion on a common top for yang models related to MPLS

>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 9 Feb 2016 15:43:08 +0000

My preference wasn’t quite clear in the previous email, so let me state it explicitly - (1), IMO, MPLS base should reside off the root, and for (2) it might be worth dividing the subsequent models as either non-routing or routing, given that MPLS control plane e.g. LDP would be routing dependent, whereas static LSP _could_ not be. 

For (2), a hierarchy something like his works out (where non-routing is nothing but MPLS base)

	MPLS Base
		<non-routing>
			Static LSP
		<routing>
			Static LSP
			Dynamic LSP - LDP, mLDP, RSVP-TE, 

However, it creates an interesting challenge for aligning the yang models and while keeping the hierarchy simple.

Is it worth having a focused team figuring out MPLS base staying off the root, whereas routing-dependent MPLS control plane protocols e.g. LDP staying off routing?

-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: Rajiv Asati <[email-masked]>
Date: Friday, February 5, 2016 at 8:58 AM
To: Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls] discussion on a common top for yang models related to MPLS

>Either ignore the above and have GMPLS argument mpls base model as is, or get MPLS base on an independent path (off of (IP) routing/routing-protocol) and work out the subsequent models.
>
>

---

From: Phil Bedard <[email-masked]>
Date: Tue, 09 Feb 2016 19:23:46 -0500

There is a consolidated MPLS model introduced by OpenConfig, the 02 version publisehd in October of last year.  

https://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-02

It has a base model which then has three different sub-models defined in the hierarchy covering types of LSPs: static, IGP-congruent/unconstrained (routing-dependent), and TE/constrained.  

Thanks, 

Phil

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 10 Feb 2016 00:31:29 +0000

I was going to bring exactly same point.

Over the last 6 months, in protocol/ services related modeling work we have put lot of effort trying to align with OpenConfig.
Keeping this alignment with base MPLS model would be rather logical step.

Regards,
Jeff

> On Feb 9, 2016, at 4:24 PM, Phil Bedard <[email-masked]> wrote:
>

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Fri, 12 Feb 2016 04:02:03 +0000

Hi Lou/Loa and WG,

The co-authors of draft-ietf-teas-yang-te/draft-ietf-teas-yang-rsvp and draft-saad-mpls-static-yang have been discussing a similar topic in the design meetings and would like to add their thoughts/input on this discussion.

1. On the reuse of generic models (e.g. static LSPs or TE tunnel/LSPs models) for multiple
   technologies. To accomplish this:

  *   there is a need for abstracted/generic model that is independent of any one technology
  *
  *   the generic/abstracted model needs to be attachable/mountable under possibly multiple target nodes in the model (tree) — possibly representing the different technologies that the model will support.
  *   For example, the MPLS static or TE LSPs models can show up under mpls or otn as:
  ../mpls/te/lips

              ../mpls/static-lsps
       and
              ../otn/te/lips
              ../otn/static-lsps

  *   augment the abstract/generic model with additional specific technology attributes

Interestingly, there are currently couple of proposals trying to solve the ability to mount a generic model at multiple target nodes in the tree by extending YANG for "mount” capability, refer to:
- draft-bjorklund-netmod-structural-mount-00
- draft-clemm-netmod-mount-00

2. On the decoupling of the generic model into device and device independent data:

  *   there's a need to reuse the generic model outside of the device (for example, on a TE controller). The model in draft-ietf-teas-yang-te allows setting per device interface TE attributes.

  *   The team is considering splitting this such that the device dependent data module augments the device independent data module

3. Current status of models/drafts:

  *   draft-ietf-teas-yang-te is proposing a generic/abstract model for TE tunnels/LSPs that is currently hanging from the top as: /te/tunnels or /te/lsps. We think this is suitable to remain in preparation to adding support for di mpls/etc. mounts for it once YANG “mount" capability is finalized.
  *   draft-saad-mpls-static-yang is currently proposing an MPLS specific model for static LSPs that is hanging below mpls base target node: ../mpls/static-lsps.
     *   The team is looking into:
     *   abstracting the static-lsps model so it's technology agnostic. Expect the generic static-lsps model to hang off the top of the tree as (1)
     *   reusing the generic static-lsps model for mpls possibly using YANG "mount" capability
     *   adding the MPLS specific properties in the mpls static-lsps model.
  *   draft-ietf-teas-yang-rsvp is contains two data pieces:
     *   RSVP-TE protocol specific data (applicable to all sessions/lsps)per TE LSP augmentation for RSVP-TE data
     *
     *   per TE LSP augmentation for RSVP-TE dat
     *   the RSVP protocol specific data reside under the “routing-instance”.  This allows tuning RSVP protocol properties on per routing instance

Regards,
Tarek (on behalf of co-authors)

On 2016-02-05, 7:34 AM, "mpls on behalf of Loa Andersson" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

All,

Thank you,
Lou and Loa
--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 12 Feb 2016 15:44:54 +0000

I agree, Jeff and Phil. Alignment is key. 

Will need to do the due diligence to find other discrepancies. 

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

> On Feb 9, 2016, at 7:31 PM, Jeff Tantsura <[email-masked]> wrote:
>