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

[Dieter Beller <[e-mail]>]

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:[e-mail]] 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 <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/teas" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/teas

 

_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas" rel="nofollow">https://www.ietf.org/mailman/listinfo/teas