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

[Dieter Beller <[e-mail]>]

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:

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.