Subject: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-11-30

From: Xufeng Liu <[email-masked]>
Date: Tue, 6 Dec 2016 20:33:27 +0000

Attendees:
Igor, Xufeng, Dieter, Sergio, Pavan, Italo

- Discussed the impacts of ospf TE potential changes
  > There are two on-going proposals that may affect the TE topology model
    1) https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/
    2) https://datatracker.ietf.org/doc/draft-hegde-ospf-advertising-te-protocols/

  > To make TE topology model match the above proposals:
    For draft 2), a list of applications can be added to the link:

augment /nw:networks/nw:network/nt:link:
   +--rw te!
      +--rw config
      |  +--rw te-link-attributes
      |     +--rw access-type?                      te-types:te-link-access-type
      |     +--rw administrative-group?             te-types:admin-groups
      |     +--rw te-delay-metric?                  uint32
      |     +--rw te-srlgs
+      |     +--rw te-application* [app]
+      |        +--rw app* identityref  // {rsvp, sr, ...}

For draft 1), the current structure is not compatible. There are a few options:

    1.1 Restructure te link container, which complicates everything existing:

augment /nw:networks/nw:network/nt:link:
   +--rw te!
      +--rw config
      |  +--rw te-link-attributes
+      |     +--rw te-application* [app]
+      |        +--rw app* identityref  // {rsvp, sr, ...}
>         |     +--rw access-type?                      te-types:te-link-access-type
>         |     +--rw administrative-group?             te-types:admin-groups
>         |     +--rw te-delay-metric?                  uint32
>         |     +--rw te-srlgs

    1.2 Add some application flag for the link and for each attribute,
    which also makes the model less usable and confusing:

augment /nw:networks/nw:network/nt:link:
   +--rw te!
      +--rw config
      |  +--rw te-link-attributes
+           +--rw app-bit-map                bits // one bit for each app
      |     +--rw access-type?                      te-types:te-link-access-type
      |     +--rw administrative-group?             te-types:admin-groups
      |     +--rw te-delay-metric?                  uint32
+     |     +--rw te-delay-metric-bit-map?          bits
      |     +--rw te-srlgs
+     |     +--rw te-srlgs-bit-map?                 bits

   1.3 Reuse information-source container, which does not seem to be suitable:

      |  +--ro information-source-entry* [information-source]
      |  |  +--ro information-source                te-info-source: ospf
      |  |  +--ro information-source-state
      |  |  |  +--ro credibility-preference?    uint16

      |  +--ro information-source-entry* [information-source]
      |  |  +--ro information-source                te-info-source: ospf-for-rsvp
      |  |  +--ro information-source-state
      |  |  |  +--ro credibility-preference?    uint16

      |  +--ro information-source-entry* [information-source]
      |  |  +--ro information-source                te-info-source: ospf-for-sr
      |  |  +--ro information-source-state
      |  |  |  +--ro credibility-preference?    uint16

   1.4 Keep current TE topology model structure and let implementation
       do the mapping.

- Discussed which model to hold performance metric (base model, or packet)?
  > This section is needed for some technologies, but not all technologies.
    If we put it into base model, some technologies need to ignore it;
    if we put it into technology augmentation model, each augmentation
    needs to repeat the same augmentation.
  > There are a few options:
    1. Optional feature in base model
       o Not use in OTN
       o Not use in DWDM
    2. Not in base
       o IP pkt does augmentation
       o Eth does augmentation
  > Both approaches have issues.
  > Attendees came up a compromise of the two options as below.
    Workgroup feedbacks are appreciated:
    3. In base model, grouping is defined, but schema tree is not
       defined for this section.
       o Performance metric is defined as a reusable grouping, either
         in the base model, or in a common types model.
       o The schema tree of the base model does not include this
         section so that OTN and DWDM users will not see the clutter.
       o For each technology that needs this section, a one-line
         "uses" statement is added to include this section to cover
         this feature.

Thanks,

- Xufeng

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

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Dec 2016 14:16:55 +0000

Hi guys,

Huawei folks working on the TE Topology model implementation have brought to my attention that unlike TE nodes and TE links, TTPs do not have Underlay/Source/Supporting attributes. Note that because (in contrast to TE nodes/links) TTPs are not independent entities in a TE topology (always belong to respective hosting TE nodes), there is no need for Underlay and Source TTP attributes (could be derived from the hosting TE node attribute). However, list of Supporting TTPs per TTP is useful for the same reason as Supporting TE link/node - to let the client track abstract/logical entities to their respective real/physical ones.  I suggest adding the list. Let's discuss.

Igor