Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2017-01-25

From: Xufeng Liu <[email-masked]>
Date: Thu, 26 Jan 2017 01:03:21 +0000

Attendees:
Igor, Xufeng, Italo, Carlo, Sergio, Pavan, Rakesh, Dieter

- Discussed the potential impacts of I2RS base topology model only being applicable to I2RS
  > TE topology model would be affected by the result.
  > TE topology can be designed with or without augmenting I2RS base topology.
  > There are pros and cons for each alternative.
  > We keep the current design for now, unless there will be a scope
    change for I2RS base topology change, which we don't expect currently.

- After last revision, we have following modeling changes, which need texts
  > Added NSRLG
    o Igor
  > Performance metric will be defined as a grouping in base (te-types) model
  > Add support for TE application, which can be specified on a TE link
    o Pavan
  > Bug fixes:
    o network-ref
    o tunnel-tp-ref in tunnel-src and tunnel-des
  > Added support for tunnel-ttp in tunnel-ttp
    O Igor already has the text
  > Added support for specifying default attributes of connectivity
    matrix and LLCL
  > Make underlay tunnel-id rw
  > Added a flag to request to be shared or dedicated
  > Added client-layer-adaptation to support more than 2 layers in
    a multi-layer topology
    o Italo

- Continued discussion on multi-layer topologies covering more than 2 layers.
  > Reviewed the changes of client-switching-capabilities to ttp:

augment /nw:networks/nw:network/nw:node:
   +--rw te-node-id?   te-types:te-node-id
   +--rw te!
      +--rw tunnel-termination-point* [tunnel-tp-id]
         +--rw tunnel-tp-id                           binary
         +--rw config
+        |  +--rw client-layer-adaptation
+        |  |  +--rw switching-capability* [switching-capability encoding]
+        |  |     +--rw switching-capability    identityref
+        |  |     +--rw encoding                identityref
         +--ro state
+        |  +--ro client-layer-adaptation
+        |  |  +--ro switching-capability* [switching-capability encoding]
+        |  |     +--ro switching-capability    identityref
+        |  |     +--ro encoding                identityref

  > Open item: is this ok for OTN signaling type? One proposal is to
    o Add OTN to swithing-capability
    o Add ODU1, ODU2, ..., ODUFlex to encoding

  > TTP <-> LTP (already exists)
    TTP <-> TTP (needs to add to support transitional link) called
    "transitional-link"

  > Check the cases for transitional links, and come back with any
    confirmations or suggestions.

Thanks,

- Xufeng

Note: Please drop me an email if you need an invite for joining the weekly call.