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

From: "Xufeng Liu" <[email-masked]>
Date: Mon, 16 May 2016 09:27:23 -0400

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

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 23 May 2016 09:40:58 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 23 May 2016 13:51:53 +0000

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:[email-masked]] 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 <[email-masked]<mailto:[email-masked]>> wrote:
Authors and contributors have discussed the use case of abstract topology,
to address the incompleteness of connectivity matrix.

  max-bandwidth?               decimal64

Comments are welcome.

Thanks,

- Xufeng

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 23 May 2016 10:02:15 -0400

Hi,

As you indicated, having an abstract label in the base would be better, its
applicable to all MPLS/GMPLS networks.

For layer specific label format/restrictions, this indeed belongs to the
layer specific augmentations.

Thanks,
Cyril

On 23 May 2016 at 09:51, Igor Bryskin <[email-masked]> wrote:

> 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:[email-masked]] *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,
>

---

From: Dieter Beller <[email-masked]>
Date: Mon, 23 May 2016 16:06:20 +0200

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:[email-masked]]
On Behalf Of Cyril Margaria

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
<[email-masked]>
wrote:

Authors and contributors have discussed
the use case of abstract topology,

|     |  +--rw id            uint32

|     |  +--rw from

|     |  +--rw to

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

priority     uint8

+-- bandwidth?   decimal64

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

[email-masked]

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 23 May 2016 14:25:04 +0000

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:[email-masked]]
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,

Igor

Hi,

Thanks,
Cyril

  max-bandwidth?               decimal64

Comments are welcome.

Thanks,

- Xufeng

Teas mailing list

---

From: Dieter Beller <[email-masked]>
Date: Mon, 23 May 2016 16:43:44 +0200

Hi Igor,

I am confused - maybe something we can clarify during our TEAS call
today that will start in 15min.

Thanks,

Dieter

On 23.05.2016 16:25, Igor Bryskin
wrote:

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:[email-masked]]

Cc: TEAS WG

Hi Igor, Cyril, all,

fixed client
to server mappings is s multi-layer aspect if I'm not wrong.

information that would get lost during the abstraction process
(example: srlg information associated with the underlying
topology that was

Thanks,

Dieter

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:

To: Xufeng Liu

Cc: TEAS WG

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.

Thanks,

Cyril

Authors and contributors have
discussed the use case of abstract topology,

|     |  +--rw id            uint32

|     |  +--rw from

|     |  +--rw to

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

priority     uint8

+-- bandwidth?   decimal64

Comments are welcome.

Thanks,

- Xufeng

Teas mailing list

[email-masked]

Teas mailing list

[email-masked]

---

From: "Belotti, Sergio (Nokia - IT)" <[email-masked]>
Date: Mon, 23 May 2016 14:47:46 +0000

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:[email-masked]] 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,

Cheers,
Igor

Hi Igor, Cyril, all,

Thanks,
Dieter

Igor

Hi,

Thanks,
Cyril

  max-bandwidth?               decimal64

Comments are welcome.

Thanks,

- Xufeng

Teas mailing list

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 23 May 2016 14:50:19 +0000

Sure, we can do this.

Igor

From: Dieter Beller [mailto:[email-masked]]
Sent: Monday, May 23, 2016 10:44 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,

I am confused - maybe something we can clarify during our TEAS call today that will start in 15min.

Thanks,
Dieter
On 23.05.2016 16:25, Igor Bryskin wrote:
Dieter,

Cheers,
Igor

Hi Igor, Cyril, all,

Thanks,
Dieter

Igor

Hi,

Thanks,
Cyril

  max-bandwidth?               decimal64

Comments are welcome.

Thanks,

- Xufeng

Teas mailing list

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 23 May 2016 14:59:35 +0000

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:[email-masked]]
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,

Cheers
Sergio

Sergio Belotti

Dieter,

Cheers,
Igor

Hi Igor, Cyril, all,

Thanks,
Dieter

Igor

Hi,

Thanks,
Cyril

  max-bandwidth?               decimal64

Comments are welcome.

Thanks,

- Xufeng

Teas mailing list