[mpls] YANG label type definition for multiple technologies

"Tarek Saad (tsaad)" <tsaad@cisco.com> Thu, 09 June 2016 16:46 UTC

Return-Path: <tsaad@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294A212D88A; Thu, 9 Jun 2016 09:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuW17E78XJjT; Thu, 9 Jun 2016 09:46:25 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849E612D87E; Thu, 9 Jun 2016 09:46:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34672; q=dns/txt; s=iport; t=1465490785; x=1466700385; h=from:to:cc:subject:date:message-id:mime-version; bh=1owxb5Mvh/5uuPYxhq7G7X/5tty2qy4p1rNwNyHPYBU=; b=Zqu15Xf5re5oBpZjNHTwBy7Oznltrnh0SVFkBz9fkYZ97KP7+6LV1BXn fnaI8Wyy35RV2HhXQb8qiFU3+2o85RbhyJwP0MRrJxRoTyv+i5OG1dL07 T3ZTnC1Ez/WenYdTyKpezGE7xHFgcabZElWrmp6morlrRnOUUBbIYEdwJ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAADjnFlX/5NdJa1EFwOCcA8/Vn0Gu?= =?us-ascii?q?QWCD4ESBV8EFwEMhW8egRs4FAEBAQEBAQFlJ4RFAQICAiMKORMOBAEdAhUECAE?= =?us-ascii?q?DBgIEGRcdBwMEAQ0FiC8OLax9hQ2LfAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFB?= =?us-ascii?q?YYigXeHB1YHgXs4ExiCLgWIZY9wAYYChWiCPIFpF4Q7iGWPZAEeNoIHHIEAS24?= =?us-ascii?q?BiEUrGH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.26,445,1459814400"; d="scan'208,217";a="283760390"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 16:46:24 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u59GkOkk015851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 16:46:24 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 12:46:23 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 12:46:23 -0400
From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
To: "teas@ietf.org" <teas@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: YANG label type definition for multiple technologies
Thread-Index: AQHRwm50Gf0siyjQDUGiThHMY6d/xQ==
Date: Thu, 9 Jun 2016 16:46:23 +0000
Message-ID: <B42B518C-BA31-48D9-BBBB-116617BA1550@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.16.0.160506
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.246.218]
Content-Type: multipart/alternative; boundary="_000_B42B518CBA3148D9BBBB116617BA1550ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_8B2KUYsqLVv5KpquIbE9v1VQB0>
Cc: Igor Bryskin <Igor.Bryskin@huawei.com>, =?utf-8?B?UGF3ZcWCIEthY3ptYXJlaw==?= <PKaczmarek@advaoptical.com>, Xufeng Liu <xliu@kuatrotech.com>, Vishnu Pavan Beeram <vbeeram@juniper.net>, "Rakesh Gandhi \(rgandhi\)" <rgandhi@cisco.com>, "Chenxia \(D\)" <jescia.chenxia@huawei.com>, Raqib Jones <raqib@Brocade.com>, Anurag Sharma <AnSharma@infinera.com>, "Wen, Bin" <Bin_Wen@cable.comcast.com>
Subject: [mpls] YANG label type definition for multiple technologies
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2016 16:46:27 -0000

Hi WGs,

In our last TE YANG meeting, the team discussed the issue of a unified YANG label type that can apply to multiple technologies. Below are some minutes. Let us know if you have further comments/suggestions.
For reference, RFC3471 (section 3.2.1) defines the generalized label as a variable length field whose interpretation is dependent on the link label type.
Also RFC7139 (section 6.1) defines the OTN label as variable size field too.

Two options were discussed: A) strict label type definition per technology, B) unified generic label type that applies to all technologies

Couple of things that we thought may need to be covered:

  1.  Sanity on label value(s) on per technology:
     *   For A) the sanity could be implicit in the label type definition, e.g.
  typedef mpls-label {
    type uint32 {
      range "0..1048575";
    }
  }

     *   For B):
                                                               i.      the sanity can be done in YANG with a “must” check under the respective leaf(s), or
                                                             ii.      the sanity can be left for the device backend to validate input values – no check in YANG


  1.  We debated if an abstract (technology-independent) YANG model(s) may require the use of generic label type – e.g. to cover a case of multiple technologies objects being represented in same model.


Here are options we discussed:
A. Per-technology strict type definitions (e.g. mpls-label, otn-label, etc..):
- MPLS technology type:
  typedef mpls-label {
    type uint32 {
      range "0..1048575";
    }
  }

in MPLS model use:
e.g. for MPLS LSPs, use
  leaf incoming-label {
    type mpls:mpls-label;
  }

- OTN technology (rfc7139, section 6.1 defines variable size field):
  typedef otn-label {
    type binary;
  }

e.g. for OTN LSPs, use
  leaf incoming-label {
    type otn:otn-label;
  }

B. Generalized label type (liberal):
Geneic label covers all label types by defining it as binary with no strict length check.
typedef generic-label {
  type binary;
}

somewhat similar to way ip-address type is defined in YANG:
typedef ip-address {
 type union {
   type ipv4-address;
   type ipv6-address;
 }
}

in MPLS model use:
e.g. for MPLS LSPs, use
  leaf incoming-label {
    type generic-label;
    must “0 <= current() <= 1048575”
  }

Regards,
Tarek




From: tsaad@cisco.com
When: 9:00 AM - 10:00 AM June 10, 2016
Subject: MPLS and TE tunnels YANG data model meeting
Location: webex


Refreshing invite for MPLS and TE tunnels YANG data model meeting. Please forward to anyone I missed.




-- Do not delete or change any of the following text. --


Join WebEx meeting<https://cisco.webex.com/ciscosales/j.php?MTID=m0ca390b72d0429c54da97264fbbf4bf7>
Meeting number: 208 554 462
Meeting password: 3jwMRXEd


If you are a host, go here<https://cisco.webex.com/ciscosales/j.php?MTID=mf7213fd8aaf17fc2e70c282a3e3d8376> to view host information.

Join by phone
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 208 554 462
Numeric meeting password: 24305603
Global call-in numbers<https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=350124967&tollFree=1> | Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>


Can't join the meeting? Contact support.<https://cisco.webex.com/ciscosales/mc>

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session..