Subject: [Teas] YANG label type definition for multiple technologies

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Thu, 9 Jun 2016 16:46:23 +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: [email-masked]
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..