Re: [CCAMP] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )

["Zhangxian (Xian)" <[e-mail]>]

Hi, Igor,

I  changed the recipient to ccamp mailing list since this discussion should be of interest to the CCAMPers.

To answer your question:

No; not at the moment.  I am aware that GMPLS OSPF-TE extensions usually follow the 8-level priority info., but they are not used that much.  Do you and others see the need when reporting ODU resource information via controller northbound interface as well?  I am open to suggestions.

Regards,
Xian

发件人: Igor Bryskin
发送时间: 2016年9月19日 20:18
收件人: Zhangxian (Xian); Xufeng Liu; Vishnu Pavan Beeram; 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; [e-mail]; Belotti, Sergio (Nokia - IT); Anurag Sharma
抄送: [e-mail]
主题: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12

Hi Xian,

The ODUk counters will be on per priority level, correct?

Igor

From: Zhangxian (Xian)
Sent: Saturday, September 17, 2016 11:53 PM
To: Xufeng Liu; 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; [e-mail]<mailto:[e-mail]>; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12

Hi, Xufeng, All,

   Thanks for the minutes.

   For the following point:
“  > The data type "decimal64" is not convenient for OTN because the
    bandwidth is desired to be expressed as the number of channels,
    like 2 ODU1's.
    Participants agreed to suggest an augmentation in the OTN model,
    and not to change this model.
“
  We do plan to update the OTN topology model to include this information:

augment /nd:networks/nd:network/lnk:link/tet:te/tet:config:
   +--rw available-odu-info* [odu-type]
   |  +--rw odu-type    identityref
   |  +--rw number?     uint16

Any comments are welcome.

Another point related to this discussion: I notice the following attributes in TE-topology model: should they be removed?

|   +--rw time-division-multiplex-capable
                  |     +--rw minimum-lsp-bandwidth?   decimal64
                  |     +--rw indication?              enumeration


Regards,
Xian

发件人: Xufeng Liu [mailto:[e-mail]]
发送时间: 2016年9月16日 5:14
收件人: 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); [e-mail]<mailto:[e-mail]>; Belotti, Sergio (Nokia - IT); Anurag Sharma
抄送: [e-mail]<mailto:[e-mail]>
主题: IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12

Participants:
Igor, Xufeng, Anurag, Dieter, Sergio

- Discussed attributes that are potentially technology specific.
  > Dieter has sent an email describing a list of such attributes.
  > Participants discussed the list.
  > The following section is not applicable to non-packet networks
   such as OCH and OTN, because the delay and bandwidth variations do
    not exist.
    We will move the section to packet augmentation:
      |     +-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

      To retain the delay information, add the following:
      delay-metric?                 uint32

  > The data type "decimal64" is not convenient for OTN because the
    bandwidth is desired to be expressed as the number of channels,
    like 2 ODU1's.
    Participants agreed to suggest an augmentation in the OTN model,
    and not to change this model.

      |     +-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

  > Discussed the deficiency of the above data type "decimal64", because it cannot represent very large number.
    Agreed to change the data type to a type representing IEEE 32 bit floating point number.

- Discussed the operator requirement to have the geo-location on node and
  link-tp (3 GPS values)
  > Following is the proposal.
  > Add the section on node, link-tp, and tunnel-tp.
  > Discussed whether to use rw or ro?
    Most agreed to use ro since user requested update does not make sense.
    If the attribute needs to be updated by provider operator, some
    other mechanism is needed.
  > precision:
    8th decimal place will have the precision 1.1mm.
    Oscar to check with the operator use cases.

augment /nw:networks/nw:network/nw:node:
   +--rw te-node-id?   te-types:te-node-id
   +--rw te!
      +--rw config
      +--ro state
      |  +--ro te-node-attributes
      |  |  +--ro schedules
      |  |  +--ro admin-status?          te-types:te-admin-status
      |  |  +--ro connectivity-matrix* [id]
      |  |  +--ro domain-id?             uint32
+      |  |  +--ro geolocation
+      |  |  |  +--ro altitude?    int64
+      |  |  |  +--ro latitude?    geographic-coordinate-degree
+      |  |  |  +--ro longitude?   geographic-coordinate-degree

  typedef geographic-coordinate-degree {
      type decimal64 {
        fraction-digits 8;
      }
      description
        "Decimal degree (DD) used to express latitude and longitude
         geographic coordinates.";
  }

Thanks,

- Xufeng

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

P.S. We are planning to change the weekly meeting time. Please send your preference.