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

"Tarek Saad (tsaad)" <> Fri, 12 February 2016 04:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ACC941B3F39 for <>; Thu, 11 Feb 2016 20:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pdc9_En9NFmv for <>; Thu, 11 Feb 2016 20:02:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCFC01B3F30 for <>; Thu, 11 Feb 2016 20:02:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=15674; q=dns/txt; s=iport; t=1455249725; x=1456459325; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kvl0F0tssI5y2R3KN3xRyOOsqw/Kfd6B+BY+CunyVZE=; b=VLfuNOfh3+1PumzfMkKpd9Cv7NDelSMYhqeOLW2ByaLcd6KeYcoHa2tY 8d0F0NS/Y+jRKGTSCVbjsFlTh7lrvA1UHq5ypDg1PYGKv03SCAkm9Ce5t ymJ4yIfV1bbpg8RJ7jH2YdChezpwlG4jh5OAAOK95cMsEn51gdTj48lOP w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.22,434,1449532800"; d="scan'208,217"; a="76242506"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2016 04:02:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u1C424G2015423 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 04:02:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 22:02:03 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 22:02:03 -0600
From: "Tarek Saad (tsaad)" <>
To: Loa Andersson <>, "" <>
Thread-Topic: [mpls] discussion on a common top for yang models related to MPLS
Thread-Index: AQHRYBGj5p9ngrmVc0+QaGahv9jb/J8n5OmA
Date: Fri, 12 Feb 2016 04:02:03 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D2E2133D80958tsaadciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] discussion on a common top for yang models related to MPLS
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2016 04:02:08 -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:


  *   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

Tarek (on behalf of co-authors)

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


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:<>
Senior MPLS Expert                <>
Huawei Technologies (consultant)     phone: +46 739 81 21 64

mpls mailing list<>