[Teas] te-topology yang model: relationships between te-link and te-tps for optical transport networks

[Dieter Beller <[e-mail]>]

Hi Xufeng, all,

in optical transport networks (DWDM and electrical OTN layers) we have a finite set of (C)TPs (=connection termination points) on our links.
So, there is typically the following containment relationship:

te-link (--> list of component links if bundling is applied - optional) --> list of te-tps (finite set of CTPs )

Looking at the latest version of our Yang model (https://github.com/ietf-mpls-yang/te/blob/master/ietf-te-topology.yang" rel="nofollow">https://github.com/ietf-mpls-yang/te/blob/master/ietf-te-topology.yang), it is not obvious
how this containment relationship is modeled, which was our assumption. Our suspicion is that this relationship is not modeled at all.

Could you please let us know if our understanding is correct. If so, we propose to model the above relationships in both directions:

te-link (--> list of component links) --> list of te-tps

te-tp (--> component link) --> te-link.


Thanks,
Dieter & Sergio

On 02.07.2016 01:26, Xufeng Liu wrote:

Participants:

Igor, Xufeng, Pavan, Sergio, Mateusz, Manali, Dieter, Tarek, Oscar, Anurag

 

- Preparing draft update

  > Dieter described multi-layer and transitional link.

  > Igor's description for inter-domain topology merging.

 

- Model change to support inter-domain links:

augment /nw:networks/nw:network/nt:link:

   +--rw te!

      +--rw config

      |  +--rw (bundle-stack-level)?

      |  +--rw te-link-template*     leafref {template}?

      |  +--rw te-link-attributes

      |     +--rw schedules

      |     |  +--rw schedule* [schedule-id]

      |     |     +--rw schedule-id          uint32

      |     |     +--rw start?               yang:date-and-time

@@ -436,6 +439,9 @@ augment /nw:networks/nw:network/nt:link:

       |     |     +--rw schedule-duration?   string

       |     |     +--rw repeat-interval?     string

       |     +--rw access-type?                      te-link-access-type

+      |     +--rw external-domain

+      |     |  +--rw remote-te-node-id?      te-node-id

+      |     |  +--rw remote-te-link-tp-id?   te-tp-id

+++    |     |  +--rw plug-id?                uint32|string|uri    <<<<< TBD

       |     +--rw is-abstract?                      empty

       |     +--rw name?                             string

       |     +--rw underlay! {te-topology-hierarchy}?

 

 

@@ -590,6 +596,9 @@ augment /nw:networks/nw:network/nt:link:

          |  |     +--ro schedule-duration?   string

          |  |     +--ro repeat-interval?     string

          |  +--ro access-type?                      te-link-access-type

+         |  +--ro external-domain

+         |  |  +--ro remote-te-node-id?      te-node-id

+         |  |  +--ro remote-te-link-tp-id?   te-tp-id

          |  +--ro is-abstract?                      empty

          |  +--ro name?                             string

          |  +--ro underlay! {te-topology-hierarchy}?

 

- Discussed Anurag's comments

  > Anurag presented transport modeling analysis slides.

  > Discussed access link modeling.

  > Anurag proposed to use URI as the type for node-id and te-link-id instead of yang:dotted-quad and uint32.

  > Participants debated on the attribute types and could not convince each other.

  > Will bring the type issue to the working group.

 

Thanks,

 

- Xufeng

 

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

 

There will be no meeting on July 4 because of US holiday.