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

From: Xufeng Liu <[email-masked]>
Date: Wed, 24 Aug 2016 19:16:28 +0000

Participants:
Igor, Xufeng, Dieter, Oscar

- Connectivity matrix
  > TE path needs to be able to specify node/connectivity-matrix id, to facilitate path computation, and to support parallel connectivity-matrix entries in a node.
    This needs to be in both te-topology model and te model.
    Will bring the topic to TE model discussion meeting.
  > Agreed to add underlay TE path for each connectivity-matrix entry.

- 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 meeting after Dieter is back
    from vacation.

- Schedule down time (in addition to up time)

      |  +--rw schedules
      |  |  +--rw schedule* [schedule-id]
      |  |     +--rw schedule-id            uint32
+      |  |     +--rw inclusive-exclusive?   enumeration
      |  |     +--rw start?                 yang:date-and-time
      |  |     +--rw schedule-duration?     string
      |  |     +--rw repeat-interval?       string

+        leaf inclusive-exclusive {
+          type enumeration {
+            enum inclusive {
+              description "The schedule element is inclusive.";
+            }
+            enum exclusive {
+              description "The schedule element is exclusive.";
+            }
+          }
+          description
+            "Whether the list item is inclusive or exclusive.";
+        }

- info-source: bgp-ls

    leaf information-source {
      type enumeration {
        enum "unknown" {
          description "The source is unknown.";
        }
        enum "locally-configured" {
          description "Configured entity.";
        }
        enum "ospfv2" {
          description "OSPFv2.";
        }
        enum "ospfv3" {
          description "OSPFv3.";
        }
        enum "isis" {
          description "ISIS.";
        }
+        enum "bgp-ls" {
+          description "BGP-LS.";
+          reference
+            "RFC7752: North-Bound Distribution of Link-State and
+             Traffic Engineering (TE) Information Using BGP";
+        }
        enum "system-processed" {
          description "System processed entity.";
        }
        enum "other" {
          description "Other source.";
        }
      }
      description
        "Indicates the source of the information.";
    }

- Clean up notifications
  We currently have notifications for te-node and te-link. These
  notifications are covered by draft-ietf-netconf-yang-push and
  draft-gonzalez-netconf-5277bis.
  We will remove these notifications from te-topology model.

- Need to complete counters/statistics. Each of us will think about
  what attributes are needed.
  > number of operational links/tunnels
  > number of recoverying links/tunnels
  > number of protection switches
  > number of protection reversions

Thanks,

- Xufeng

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

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 24 Aug 2016 20:25:02 +0000

Hi Xufeng,

You wrote:
"> TE path needs to be able to specify node/connectivity-matrix id, to facilitate path..."

Minor correction:
TE path needs to be able to specify node/connectivity-matrix entry id, to facilitate path...

Cheers,
Igor

From: Xufeng Liu [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 3:16 PM
To: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); [email-masked]; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: [email-masked]
Subject: IETF TE Topology YANG Model Design Meeting Notes - 2016-08-22

Participants:

- Connectivity matrix

    from vacation.

      |  +--rw schedules

- info-source: bgp-ls

- Clean up notifications

Thanks,

- Xufeng

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 25 Aug 2016 07:03:16 +0000

Hi, Xufeng,

   With regard to the following point:
 - Clean up notifications

The existing notification is really clear, in terms of event types. But I still cannot figure out how to use the model specified by draft-ietf-netconf-yang-push.  I wonder if you can give an example, say, how a creation of te-node can be modeled using the model provided in draft-ietf-netconf-yang-push?

Regards,
Xian

发件人: Xufeng Liu [mailto:[email-masked]]
发送时间: 2016年8月25日 3:16
收件人: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); [email-masked]; Belotti, Sergio (Nokia - IT); Anurag Sharma
抄送: [email-masked]
主题: IETF TE Topology YANG Model Design Meeting Notes - 2016-08-22

Participants:

- Connectivity matrix

    from vacation.

      |  +--rw schedules

- info-source: bgp-ls

- Clean up notifications

Thanks,

- Xufeng

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 25 Aug 2016 20:27:28 +0000

Hi Xian,

Such a notification example can be:

When TE Node “node-10” is created, the server sends the following on-change notification:

<notification
      xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2015-03-09T19:14:56Z</eventTime>
   <push-change-update xmlns=
       "urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
     <subscription-id>89</subscription-id>
     <time-of-update>2015-03-09T19:14:56Z</time-of-update>
     <datastore-changes-xml>

       <networks xmlns="urn:ietf:params:xml:ns:yang:ietf-network">
         <network>
                  <network-id>topo-1</network-id>
                 <node urn:ietf:params:xml:ns:netconf:base:1.0:operation="create">
                    <node-id>node-10</node-id>
                  </node>
         </network>
       </networks>

     </datastore-changes-xml>
   </push-change-update>
</notification>

Regards,

- Xufeng

From: Zhangxian (Xian) [mailto:[email-masked]]
Sent: Thursday, August 25, 2016 3:03 AM
To: Xufeng Liu <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; Igor Bryskin <[email-masked]>; Oscar Gonzalez De Dios <[email-masked]>; Tarek Saad <[email-masked]>; Himanshu Shah <[email-masked]>; Lou Berger <[email-masked]>; BRUNGARD, DEBORAH A (ATTLABS) <[email-masked]>; Susan Hares <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Khaddam, Mazen (CCI-Atlanta) <[email-masked]>; Tony Le <[email-masked]>; BELOTTI, SERGIO (SERGIO) <[email-masked]>; Beller, Dieter (Dieter) <[email-masked]>; Rajan Rao <[email-masked]>; [email-masked]; Belotti, Sergio (Nokia - IT) <[email-masked]>; Anurag Sharma <[email-masked]>
Cc: [email-masked]
Subject: Re: IETF TE Topology YANG Model Design Meeting Notes - 2016-08-22

Hi, Xufeng,

Regards,
Xian

发件人: Xufeng Liu [mailto:[email-masked]]
发送时间: 2016年8月25日 3:16
收件人: Vishnu Pavan Beeram; Igor Bryskin; Oscar Gonzalez De Dios; Tarek Saad; Himanshu Shah; Lou Berger; BRUNGARD, DEBORAH A (ATTLABS); Susan Hares; Zafar Ali (zali); Khaddam, Mazen (CCI-Atlanta); Tony Le; BELOTTI, SERGIO (SERGIO); Beller, Dieter (Dieter); Rajan Rao; Zhangxian (Xian); [email-masked]<mailto:[email-masked]>; Belotti, Sergio (Nokia - IT); Anurag Sharma
抄送: [email-masked]<mailto:[email-masked]>
主题: IETF TE Topology YANG Model Design Meeting Notes - 2016-08-22

Participants:

- Connectivity matrix

    from vacation.

      |  +--rw schedules

- info-source: bgp-ls

- Clean up notifications

Thanks,

- Xufeng

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 30 Aug 2016 13:41:37 +0000

Oscar and All,

There was a question in the Monday’s meeting: “What dynamic TE link attributes could be deduced from the Hierarchy TE tunnel supporting the link?”
Just to be on the same page:

Hierarchy TE tunnel (also known in GMPLS as H-LSP or FA-LSP) is a tunnel supporting a dynamic TE link.

Dynamic TE links show up in (and disappear from) a TE topology as a result of multi-layer traffic engineering. Dynamic TE link (supported by Hierarchy TE tunnel dynamically set up in a server layer network) is automatically (i.e. without explicit configuration request) added to a client layer network TE topology to augment the topology with additional flexibility to ensure successful completion of the path computation for and provisioning of a client layer network connection /LSP. For example, am ODUk hierarchy TE tunnel can support a dynamic Ethernet layer TE link to enable provisioning an Ethernet layer connection on a network that does not have sufficient static Ethernet layer connectivity.

Likewise, dynamic TE link is automatically removed from the TE topology (and supporting it hierarchy TE tunnel is released) as soon as the TE link stops being used by at least one client layer connection/LSP.

The following parameters/attributes of a dynamic TE link could be deduced from the supporting hierarchy TE tunnel:

1)      TE topology ID, local/remote node/link IDs – from the hierarchy TE tunnel’s configuration;

2)      Layer ID – from the tunnel’s TTPs inter-layer locks and adaptation capabilities;

3)      Maximum bandwidth, unreserved bandwidth – from the resources allocated for and on the tunnel;

4)      Protection capabilities and status – from the connections supporting the tunnel;

5)      Underlay TE paths – from actual paths (RROs) of the connections supporting the tunnel

6)      SRLGs – could be computed as overlaps with the tunnels/connections supporting other TE links

As of today some of the dynamic TE tunnel attributes cannot be deduced from the supporting hierarchy TE tunnels. Examples: TE metric, administrative colors. There is a couple of options we can consider to manage such attributes:

a)      Use locally configured on the topology provider defaults/templates to set initial values and allow for their subsequent modification via explicit configuration requests;

b)     Add such attributes to the hierarchy TE tunnel configuration (i.e. next to already provided TE topology local/remote node/link IDs)
Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 30 Aug 2016 15:45:23 +0000

Hi,
I suggest the following telemetry counters for the TE Topology model:

1.      TE Link level:

·        linkAdds

·        linkRemoves

·        linkModifys

·        linkUps

·        linkDowns

·        linkInMaintenanceSets

·        linkInMaintenanceClears

·        protectionSwitchs

·        protectionReverts

·        restorationSwitchs

·        restorationReverts

·        faultDetects

·        faultClears

2.      TE node level:

·        nodeAdds

·        nodeRemoves

·        connectivityMatrixEntryAdds

·        connectivityMatrixEntryRemoves

·        connectivityMatrixEntryModifys

3.      TE TTP level:

·        ttpAdds

·        ttpRemoves

·        ttpModifys

·        ttpUps

·        ttpDowns

·        ttpInServiceSets

·        ttpInServiceClears

·        ttpInMaintenanceSets

·        ttpInMaintenanceClears

·        llclEntryAdds

·        llclEntryRemoves

·        llclEntryModifys

Cheers,
Igor