Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo

Sergio,

Connectivity matrix is relevant to all layers , not just OCh. I am aware of ODU physical switches which are severely constrained because, to lower the cost, they are implemented as cascades of ADMs.
Furthermore, this is much more pronounced/obvious when you consider, say, OTN/ODUk domains, presented as TE nodes. In this case, there is no guarantee that, say, ODU2 TE path arriving at such a node over one of the inter-domain TE links can exit the node from any other of its inter-domain links (because the necessary intra-node TE path may not be feasible). To describe such limitations we need a connectivity matrix to decorate the abstract TE nodes.

Igor

From: Belotti, Sergio (Nokia - IT) [mailto:sergio.belotti@nokia.com]
Sent: Monday, May 23, 2016 10:48 AM
To: Igor Bryskin; Beller, Dieter (Nokia - DE); Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: R: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo

Hi Igor,
I'm a little confused : connectivity matrix is a concept introduced in the WSON context afaik, I do not understand  the relationship at OTN/ODUk where we suppose to have no blocking matrix .
Probably need to clarify the picture in the coming call.

Cheers
Sergio

Sergio Belotti

Da: Teas [mailto:teas-bounces@ietf.org] Per conto di Igor Bryskin
Inviato: lunedì 23 maggio 2016 16:25
A: Beller, Dieter (Nokia - DE); Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Oggetto: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo

Dieter,

Your understanding is correct, and it does not contradict to what Cyril is saying. For example, a connectivity matrix in the OCh layer must provided on a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk layer the connectivity matrix entry should be specific, generally speaking,  to ODU type. As you see, this has nothing to do with the inter-layer relationships.

Cheers,
Igor

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, May 23, 2016 10:06 AM
To: Igor Bryskin; Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo

Hi Igor, Cyril, all,
fixed client to server mappings is s multi-layer aspect if I'm not wrong.

I thought that the connectivity matrix was trying to address abstraction drawbacks within a single network layer, i.e., to provide additional
information that would get lost during the abstraction process (example: srlg information associated with the underlying topology that was
abstracted into a single node).

Thanks,
Dieter
On 23.05.2016 15:51, Igor Bryskin wrote:
Cyril,

You are absolutely right. But this belongs to the layer specific augmentations, agreed?

On the other hand I do a see a value in adding an abstract label to the connectivity matrix (just like a label object in the TE path), so the basic model will be more complete to address more than one layer.

Igor

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo

Hi,
Another item that can be considered is to add a Label (Following RFC7579) restrictions. This is needed, for example,  in case of Fixed muxponders, where the connectivity between the Low order ODUs to the high-order ODU is fixed on each end.
Can it be added to the list of changes for the connectivity matrix?

Thanks,
Cyril

On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>> wrote:
Authors and contributors have discussed the use case of abstract topology,
to address the incompleteness of connectivity matrix.

Current connectivity modeling is as follows:

      |     +--rw connectivity-matrix* [id]
      |     |  +--rw id            uint32
      |     |  +--rw from
      |     |  |  +--rw tp-ref?   leafref
      |     |  +--rw to
      |     |  |  +--rw tp-ref?   leafref
      |     |  +--rw is-allowed?   Boolean

A Link TP may connect or disconnect to another Link TP, without detailed
information such as cost and resource sharing restriction. To get a better
abstraction of such connectivity, the following additional attributes are
planned to be added:

  max-bandwidth?               decimal64
  max-resv-bandwidth?          decimal64
  unreserved-bandwidth* [priority]
  priority     uint8
     +-- bandwidth?   decimal64
     +-- te-default-metric uint32
  performance-metric // re-use the container from te-link-atrributes
  te-srlgs           // re-use the container from te-link-atrributes

Comments are welcome.

Thanks,

- Xufeng

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas

_______________________________________________

Teas mailing list

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

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