Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-08-01

From: Xufeng Liu <[email-masked]>
Date: Mon, 1 Aug 2016 16:30:42 +0000

Participants:
Igor, Xufeng, Sergio, Dieter, Pawel Ka

- Make LLCL entry as rich as connectivity entry, to have enough TE information for path computation.
  > Xufeng to prepare the model change proposal.

- Have a list of attributes to be used for technology specific augmentations.
  > Dieter to prepare the list for the next meeting.

- Write a tutorial document describing the use cases and how to use  the topology model.
  > Agree to prepare.

- There will be no meetings for the next two weeks.

Thanks,

- Xufeng

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

---

From: Dieter Beller <[email-masked]>
Date: Mon, 22 Aug 2016 21:59:02 +0200

Hi all,

please find below where I believe the TE topology Yang model is not
technology independent:

The following is defined for example for TE-links:

|
+-rw performance-metric-throttle {te-performance-metric}?

|     |
+-rw unidirectional-delay-offset?
uint32

|     |
+-rw measure-interval?
uint32

|     |
+-rw advertisement-interval?                uint32

|     |
+-rw suppression-interval?
uint32

|     |
+-rw threshold-out

|     |
|  +-rw
unidirectional-delay?
uint32

|     |
|  +-rw
unidirectional-min-delay?
uint32

|     |
|  +-rw
unidirectional-max-delay?
uint32

|     |
|  +-rw
unidirectional-delay-variation?
uint32

|     |
|  +-rw
unidirectional-packet-loss?
decimal64

|     |
|  +-rw
unidirectional-residual-bandwidth?
decimal64

|     |
|  +-rw
unidirectional-available-bandwidth?   decimal64

|     |
|  +-rw
unidirectional-utilized-bandwidth?
decimal64

|     |
+-rw threshold-in

|     |
|  +-rw
unidirectional-delay?
uint32

|     |
|  +-rw
unidirectional-min-delay?
uint32

|     |
|  +-rw
unidirectional-max-delay?             uint32

|     |
|  +-rw
unidirectional-delay-variation?
uint32

|     |
|  +-rw
unidirectional-packet-loss?
decimal64

|     |
|  +-rw
unidirectional-residual-bandwidth?
decimal64

|     |
|  +-rw
unidirectional-available-bandwidth?   decimal64

|     |
|  +-rw
unidirectional-utilized-bandwidth?
decimal64

|     |
+-rw threshold-accelerated-advertisement

|     |
+-rw unidirectional-delay?
uint32

|     |
+-rw unidirectional-min-delay?             uint32

|     |
+-rw unidirectional-max-delay?             uint32

|     |
+-rw unidirectional-delay-variation?       uint32

|     |
+-rw unidirectional-packet-loss?           decimal64

|
|     +-rw
unidirectional-residual-bandwidth?
decimal64

|     |
+-rw unidirectional-available-bandwidth?   decimal64

|     |
+-rw unidirectional-utilized-bandwidth?    decimal64

IMHO, these are typical attributes for packet technologies.
For optical transport technologies, however, delay variation and
packet loss

do not really exist. residual-/available-/utilized-bandwidth are
better expressed in terms of number of ODUk containers (for the
electrical OTN

layers) or available optical central frequencies (for the photonic
OTN layer, see GMPLS  OSPF-TE extensions for fix/flex grid in
WSONs).

For the ODUk containers, a list is needed as opposed to a single
value and for the central frequencies could be a bit-field.

Other examples are the following:

|
+-rw interface-switching-capability*
[switching-capability]

|     |
+-rw switching-capability
identityref

|     |
+-rw encoding?                          identityref

|     |
+-rw max-lsp-bandwidth* [priority]

|     |
|  +-rw priority     uint8

|     |
|  +-rw bandwidth?   decimal64

|
+-rw max-link-bandwidth?
decimal64

|     +-rw
max-resv-link-bandwidth?          decimal64

|     +-rw
unreserved-bandwidth*
[priority]

|     |
+-rw priority     uint8

|     |
+-rw bandwidth?   decimal64

I think that we need technology specific augmentations for packet
network specific TE-properties and we also need technology specific

augmentations as far as the link capacity and utilization is
concerned (I don't like the term bandwidth because it is rather a
term used to

describe the analog spectrum of a signal as opposed to digital data
rates).

Thanks,

Dieter

On 01.08.2016 18:30, Xufeng Liu wrote:

Participants:

- Make LLCL entry as rich as connectivity
entry, to have enough TE information for path computation.

> Xufeng to prepare the model change
proposal.

- Have a list of attributes to be used for
technology specific augmentations.

> Dieter to prepare the list for the
next meeting.

- Write a tutorial document describing the
use cases and how to use  the topology model.

> Agree to prepare.

- There will be no meetings for the next
two weeks.

Thanks,

- Xufeng

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