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

From: "Zhangxian (Xian)" <[email-masked]>
Date: Sat, 8 Oct 2016 07:12:26 +0000

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; [email-masked]; Belotti, Sergio (Nokia - IT); Anurag Sharma
抄送: [email-masked]
主题: 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; [email-masked]<mailto:[email-masked]>; Belotti, Sergio (Nokia - IT); Anurag Sharma
Cc: [email-masked]<mailto:[email-masked]>
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:[email-masked]]
发送时间: 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); [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-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.

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 10 Oct 2016 12:41:57 +0000

Hi Xian,

In TE Topology model we define bandwidth on per priority level. TE tunnel model also allows for a tunnel to be configured on a given priority level. All path computations could be constrained to a priority level.
Furthermore, I am aware of implementations which use particular priority levels to identify bandwidth available for a particular use ( e.g. for restoration only purposes).
I don’t think we should retire the concept of priority now. I believe that in the T-SDN architecture it will be easier to support resource preemption.

Igor

From: Teas [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Saturday, October 08, 2016 3:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )

Hi, Igor,

To answer your question:

Regards,
Xian

发件人: Igor Bryskin
发送时间: 2016年9月19日 20:18

Hi Xian,

Igor

From: Zhangxian (Xian)

Hi, Xufeng, All,

   Thanks for the minutes.

   For the following point:

Regards,
Xian

Participants:

Thanks,

- Xufeng

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 10 Oct 2016 12:48:33 +0000

Hi Xian, Igor,

I think Igor’s point is valuable, in the sense that up to now preemption was not widely deployed because of the distributed nature of the path computation, but in a centralized world like the SDN one it should be easier to support that.
Moreover if a functionality is already supported by existing protocols (even if used by a small % of field deployments) I don’t see why a different way of controlling the same network should not support the same capabilities.

Cheers
Daniele

From: Teas [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: lunedì 10 ottobre 2016 14:42
To: Zhangxian (Xian) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )

Hi Xian,

Igor

To: [email-masked]<mailto:[email-masked]>

Hi, Igor,

To answer your question:

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; [email-masked]<mailto:[email-masked]>; Belotti, Sergio (Nokia - IT); Anurag Sharma
抄送: [email-masked]<mailto:[email-masked]>
主题: RE: IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12

Hi Xian,

Igor

From: Zhangxian (Xian)

Hi, Xufeng, All,

   Thanks for the minutes.

   For the following point:

Regards,
Xian

Participants:

Thanks,

- Xufeng

---

From: Dieter Beller <[email-masked]>
Date: Mon, 10 Oct 2016 15:15:20 +0200

Hi Xian, all,

I concur with Igor and Daniele - priority levels shall be supported
in the same way as for GMPLS!

Thanks,

Dieter

On 10.10.2016 14:48, Daniele Ceccarelli
wrote:

Hi Xian, Igor,

I think Igor’s point is valuable, in the sense
that up to now preemption was not widely deployed because of
the distributed nature of the path computation, but in a
centralized world like the SDN one it should be easier to
support that.

Moreover if a functionality is already
supported by existing protocols (even if used by a small %
of field deployments) I don’t see why a different way of
controlling the same network should not support the same
capabilities.

Cheers

Daniele

From: Teas [mailto:[email-masked]]
On Behalf Of Igor Bryskin

To: Zhangxian (Xian)
<[email-masked]>; [email-masked]

Cc: [email-masked]

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

Hi
Xian,

In
TE Topology model we define bandwidth on per priority
level. TE tunnel model also allows for a tunnel to be
configured on a given priority level. All path
computations could be constrained to a priority level.

Furthermore,
I am aware of implementations which use particular
priority levels to identify bandwidth available for a
particular use ( e.g. for restoration only purposes).

I
don’t think we should retire the concept of priority now.
I believe that in the T-SDN architecture it will be easier
to support resource preemption.

Igor

From: Teas [mailto:[email-masked]]
On Behalf Of Zhangxian (Xian)

To: [email-masked]

Cc: [email-masked]

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

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;
[email-masked];
Belotti, Sergio (Nokia - IT); Anurag Sharma

抄送:
[email-masked]

主题: 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)

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; [email-masked];
Belotti, Sergio (Nokia - IT); Anurag Sharma

Cc: [email-masked]

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

Regards,

Xian

发送时间: 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);
[email-masked];
Belotti, Sergio (Nokia - IT); Anurag Sharma

抄送:
[email-masked]

主题: 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.

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

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

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

--

Dieter Beller

ASON/GMPLS Project Manager

IP/Optical Networks, Optics, Nokia

t: +49 711 821 43125 | m : +49 175 7266874 | OnNet: 259 43125

[email-masked]

Alcatel-Lucent
Deutschland AG | Lorenzstr. 10 | 70435 Stuttgart

Sitz
der Gesellschaft | Domicile of the Company: Stuttgart ·
Amtsgericht Stuttgart HRB 4026

Vorsitzender des Aufsichtsrates | Chairman of the Supervisory
Board: Prof. J. Menno Harms

Vorstand | Board of Management: Wilhelm Dresselhaus
(Vorsitzender | Chairman) · Hans-Jörg Daub · Ralf Niederberger

This e-mail and its attachments, if any, may contain
confidential information.

If you have received this e-mail in error, please notify us and
delete or destroy the e-mail and its attachments, if any,
immediately.

If you have received this e-mail in error, you must not forward
or make use of the e-mail and its attachments, if any.

---

From: "Belotti, Sergio (Nokia - IT)" <[email-masked]>
Date: Mon, 10 Oct 2016 13:19:16 +0000

+1. Yes Xian, I think we need to support that.

Thanks
Sergio

From: CCAMP [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: Monday, October 10, 2016 3:15 PM
To: Daniele Ceccarelli <[email-masked]>; Igor Bryskin <[email-masked]>; Zhangxian (Xian) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [CCAMP] [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )

Hi Xian, all,

I concur with Igor and Daniele - priority levels shall be supported in the same way as for GMPLS!

Thanks,
Dieter
On 10.10.2016 14:48, Daniele Ceccarelli wrote:
Hi Xian, Igor,

Cheers
Daniele

To: Zhangxian (Xian) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Xian,

Igor

Hi, Igor,

To answer your question:

Regards,
Xian

发件人: Igor Bryskin
发送时间: 2016年9月19日 20:18

Hi Xian,

Igor

From: Zhangxian (Xian)

Hi, Xufeng, All,

   Thanks for the minutes.

   For the following point:

Regards,
Xian

Participants:

Thanks,

- Xufeng

Teas mailing list

[email-masked]<mailto:[email-masked]>

--

Dieter Beller

t: +49 711 821 43125 | m : +49 175 7266874 | OnNet: 259 43125
[email-masked]<mailto:[email-masked]>
Alcatel-Lucent Deutschland AG | Lorenzstr. 10 | 70435 Stuttgart
Sitz der Gesellschaft | Domicile of the Company: Stuttgart · Amtsgericht Stuttgart HRB 4026
Vorsitzender des Aufsichtsrates | Chairman of the Supervisory Board: Prof. J. Menno Harms
Vorstand | Board of Management: Wilhelm Dresselhaus (Vorsitzender | Chairman) · Hans-Jörg Daub · Ralf Niederberger

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 11 Oct 2016 01:22:08 +0000

Great; Thank you all for the feedbacks.

I see a good support of it. I will update the ODU topology YANG model in the following manner to support per priority ODU availability:

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

Regards,
Xian

发件人: Belotti, Sergio (Nokia - IT) [mailto:[email-masked]]
发送时间: 2016年10月10日 21:19
收件人: Beller, Dieter (Nokia - DE); Zhangxian (Xian); Daniele Ceccarelli; Igor Bryskin; [email-masked]
抄送: [email-masked]
主题: RE: [CCAMP] [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )

Thanks
Sergio

To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Zhangxian (Xian) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Xian, all,

Thanks,
Dieter

Cheers
Daniele

Hi Xian,

Igor

Hi, Igor,

To answer your question:

Regards,
Xian

发件人: Igor Bryskin
发送时间: 2016年9月19日 20:18

Hi Xian,

Igor

From: Zhangxian (Xian)

Hi, Xufeng, All,

   Thanks for the minutes.

   For the following point:

Regards,
Xian

Participants:

Thanks,

- Xufeng

Teas mailing list

--

Dieter Beller

---

From: "Belotti, Sergio (Nokia - IT)" <[email-masked]>
Date: Tue, 11 Oct 2016 07:48:38 +0000

Thanks Xian.
Fine with the update .

Regards
Sergio

From: Teas [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Tuesday, October 11, 2016 3:22 AM
To: Belotti, Sergio (Nokia - IT) <[email-masked]>; Beller, Dieter (Nokia - DE) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Igor Bryskin <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] [CCAMP] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )

Regards,
Xian

发件人: Belotti, Sergio (Nokia - IT) [mailto:[email-masked]]
发送时间: 2016年10月10日 21:19
收件人: Beller, Dieter (Nokia - DE); Zhangxian (Xian); Daniele Ceccarelli; Igor Bryskin; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: RE: [CCAMP] [Teas] OTN topology YANG model (draft-zhang-ccamp-l1-topo-yang )

Thanks
Sergio

Hi Xian, all,

Thanks,
Dieter

Cheers
Daniele

Hi Xian,

Igor

Hi, Igor,

To answer your question:

Regards,
Xian

发件人: Igor Bryskin
发送时间: 2016年9月19日 20:18

Hi Xian,

Igor

From: Zhangxian (Xian)

Hi, Xufeng, All,

   Thanks for the minutes.

   For the following point:

Regards,
Xian

Participants:

Thanks,

- Xufeng

Teas mailing list

--

Dieter Beller

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 19 Oct 2016 01:20:56 +0000

Hi, Xufeng,

  Great; thank you for the feedback.

I think the attributes specified within the time-division-multiplex-capable container, as defined in RFC4203 is for SONET/SDH technology. OTN topology has a separate set of attributes as specified in RFC7138.  So, we should add them in SONET/SDH related topology augmentation if there is any.

Regards,
Xian

发件人: Xufeng Liu [mailto:[email-masked]]
发送时间: 2016年10月18日 2:48
收件人: Dieter Beller; Zhangxian (Xian); 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); Rajan Rao; [email-masked]; Belotti, Sergio (Nokia - IT); Anurag Sharma
抄送: [email-masked]
主题: RE: [Teas] IETF TE Topology YANG Model Design Meeting Notes - 2016-09-12

Hi Xian,

During this week’s meeting, we discussed the section of time-division-multiplex-capable
It was agreed to remove it from the generic te-topology model. Do you want to put it into the proper augmentation?

Thanks,

- Xufeng

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

Hi Xian, all,

see inline below.

Thanks,
Dieter
On 18.09.2016 05:53, Zhangxian (Xian) wrote:
Hi, Xufeng, All,

   Thanks for the minutes.

   For the following point:

Any comments are welcome.
[DB>] This is exactly what is needed for the OTN at layer 1: available ODUk containers where k indicates the odu-type!

|   +--rw time-division-multiplex-capable
                  |     +--rw minimum-lsp-bandwidth?   decimal64
                  |     +--rw indication?              enumeration
[DB>] I concur - the discussion regarding bandwidth in the technology agnostic TE topology Yang model is still ongoing.
[DB>] For the WDM layer (WSON) of the OTN it even makes less sense as the link resources are optical spectrum in terms (GHz)
[DB>] and this does not directly relate to bandwidth in terms of bitrate.

Thanks,
Dieter

Regards,
Xian

Participants:

Thanks,

- Xufeng

Teas mailing list