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

Hi Dieter,

Your understanding is correct. But it does not contradict to a bundled TE link having a single LTP.
We think of LTP is a part (root) of any TE link.

Igor


From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Wednesday, July 06, 2016 1:06 PM
To: Igor Bryskin; Xufeng Liu; Vishnu Pavan Beeram; Tarek Saad; Himanshu Shah; Rajan Rao; Zhangxian (Xian); Anurag Sharma
Cc: BRUNGARD, DEBORAH A (ATTLABS); Tony Le; teas@ietf.org; Oscar Gonzalez De Dios; Khaddam, Mazen (CCI-Atlanta); Belotti, Sergio (Nokia - IT); Lou Berger; Zafar Ali (zali); Susan Hares
Subject: Re: [Teas] te-topology yang model: relationships between te-link and te-tps for optical transport networks

Hi Igor,
On 05.07.2016 16:00, Igor Bryskin wrote:
Hi Dieter,

Currently we model LTP per TE link, not per component link. Could you elaborate why should we do otherwise?
my question is related to this part in the model:

augment /nw:networks/nw:network/nt:link:
   +--rw te!
      +--rw config
      |  +--rw (bundle-stack-level)?
      |  |  +--:(bundle)
      |  |  |  +--rw bundled-links
      |  |  |     +--rw bundled-link* [sequence]
      |  |  |        +--rw sequence      uint32
      |  |  |        +--rw src-tp-ref?   -> ../../../../../../nw:node[nw:node-id = current()/../../../../../nt:source/source-node]/termination-point/tp-id
      |  |  |        +--rw des-tp-ref?   -> ../../../../../../nw:node[nw:node-id = current()/../../../../../nt:destination/dest-node]/termination-point/tp-id
      |  |  +--:(component)
      |  |     +--rw component-links
      |  |        +--rw component-link* [sequence]
      |  |           +--rw sequence             uint32
      |  |           +--rw src-interface-ref?   string
      |  |           +--rw des-interface-ref?   string
      |  +--rw te-link-template*     -> ../../../../../te/templates/link-template/name {template}?
      |  +--rw te-link-attributes


My interpretation is that a TE-link can optionally be composed of a bundle of component links like in GMPLS. Is my understanding incorrect?


Thanks,
Dieter



Thanks,
Igor

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Tuesday, July 05, 2016 9:29 AM
To: Xufeng Liu; Vishnu Pavan Beeram; Igor Bryskin; Tarek Saad; Himanshu Shah; Rajan Rao; Zhangxian (Xian); Anurag Sharma
Cc: Oscar Gonzalez De Dios; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; Belotti, Sergio (Nokia - IT); teas@ietf.org<mailto:teas@ietf.org>
Subject: te-topology yang model: relationships between te-link and te-tps for optical transport networks

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), 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.








_______________________________________________

Teas mailing list

Teas@ietf.org<mailto:Teas@ietf.org>

https://www.ietf.org/mailman/listinfo/teas
