Subject: Re: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 1 Mar 2016 21:04:33 +0000

Thank you authors for updating this LIME draft based on the discussion at IETF94.

WG,

I would encourage open discussion on the list about the updates.

We would also like to request a couple volunteers to provide a targeted review of the document. If you can invest some time reviewing, please let us know.

Thank you!

Carlos & Ron.

> On Feb 29, 2016, at 10:47 PM, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Layer Independent OAM Management in the Multi-Layer Environment of the IETF.
> 
>        Title           : Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols
>        Authors         : Tissa Senevirathne
>                          Norman Finn
>                          Deepak Kumar
>                          Samer Salam
>                          Qin Wu
>                          Michael Wang
> 	Filename        : draft-ietf-lime-yang-oam-model-02.txt
> 	Pages           : 47
> 	Date            : 2016-02-29
> 
> Abstract:
>   This document presents a base YANG Data model for connection oriented
>   OAM protocols.  It provides a technology-independent abstraction of
>   key OAM constructs for connection oriented protocols.  Based model
>   presented here can be extended to include technology specific
>   details.  This is leading to uniformity between OAM protocols and
>   support nested OAM workflows (i.e., performing OAM functions at
>   different levels through a unified interface).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-oam-model/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-lime-yang-oam-model-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lime-yang-oam-model-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 5 Mar 2016 04:51:00 +0000

Dear Authors, et. al,

thank you for updating the model and clarifying its applicability. Below are my notes on the new version that we can discuss on the list and/or at the meeting:

*         I think that the list in the description includes technologies, i.e. mpls, that are not connection-oriented:

"this is the base identy of technology types which are TRILL,mpls,vpls etc";

perhaps mpls-tp would be better.

and s/indent/identity/

*         I think that Interval must have been set of values, not int32 without a range. I believe that anything less than 3.3 millisecond would not be supported by any OAM protocol. But 3.3 msec cannot be configured through current definition of the Interval. That can be done if Interval being expressed in microseconds. But we still don't need range, we need set 3.3 msec, 10 msec, 100msec, 1 sec, 10 sec. 1 minute and 10 minutes are questionable. These are intervals from Ethernet OAM. RFC 7419 recommends somewhat different set of intervals for HW-based implementation of BFD - 3.3 msec, 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec.

I've noticed some Nits and nits in the text. The former

Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).

you can fix and check with idnits in verbose mode on Community Tools page. I can help with the latter if you kindly can share MS format of the document.

                Regards,

                                Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 29, 2016 7:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

                          Norman Finn

                          Deepak Kumar

                          Samer Salam

                          Qin Wu

                          Michael Wang

                Pages           : 47

                Date            : 2016-02-29

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Lime mailing list

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

---

From: wangzitao <[email-masked]>
Date: Mon, 7 Mar 2016 06:04:46 +0000

Hi Greg,

Thank you for these good comments!
Please see Inline.

Best Regards!
Michael
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2016年3月5日 12:51
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

Dear Authors, et. al,

・         I think that the list in the description includes technologies, i.e. mpls, that are not connection-oriented:

and s/indent/identity/

[zitao]: agree

・         I think that Interval must have been set of values, not int32 without a range. I believe that anything less than 3.3 millisecond would not be supported by any OAM protocol. But 3.3 msec cannot be configured through current definition of the Interval. That can be done if Interval being expressed in microseconds. But we still don’t need range, we need set 3.3 msec, 10 msec, 100msec, 1 sec, 10 sec. 1 minute and 10 minutes are questionable. These are intervals from Ethernet OAM. RFC 7419 recommends somewhat different set of intervals for HW-based implementation of BFD - 3.3 msec, 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec.

[zitao]: I think an enumeration type can address this issue like:

leaf interval {

type enumeration {

enum 3.3ms;

enum 10ms;

enum 20ms;

enum 50ms;

enum 100ms;

enum 1s;

enum 10s;

}

}

I’ve noticed some Nits and nits in the text. The former

[zitao]: Thank you to point out these nits, I’d like to fix it.

                Regards,

                                Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, February 29, 2016 7:48 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

                          Norman Finn

                          Deepak Kumar

                          Samer Salam

                          Qin Wu

                          Michael Wang

                Pages           : 47

                Date            : 2016-02-29

Abstract:

Lime mailing list

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 8 Mar 2016 00:20:18 +0000

Hi Michael,
thank you for your consideration. I think that set may be better option.
Another, rather general observation. The Abstract states:
“It provides a technology-independent abstraction of key OAM constructs for connection oriented protocols.”
but we can find many examples, e.g. definition of CC intervals, of technology specific. It could be that augmenting TRILL OAM and MPLS-TP OAM YANG models (draft-zhang-mpls-tp-yang-oam-02 for MPLS-TP) would be path to truly technology-independent abstraction. What do you think? What others think?

                Regards,
                                Greg

From: wangzitao [mailto:[email-masked]]
Sent: Sunday, March 06, 2016 10:05 PM
To: Gregory Mirsky; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

Hi Greg,

Best Regards!
Michael
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2016年3月5日 12:51
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

Dear Authors, et. al,

and s/indent/identity/

[zitao]: agree

leaf interval {

type enumeration {

enum 3.3ms;

enum 10ms;

enum 20ms;

enum 50ms;

enum 100ms;

enum 1s;

enum 10s;

}

}

                Regards,

                                Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, February 29, 2016 7:48 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

                          Norman Finn

                          Deepak Kumar

                          Samer Salam

                          Qin Wu

                          Michael Wang

                Pages           : 47

                Date            : 2016-02-29

Abstract:

Lime mailing list

---

From: wangzitao <[email-masked]>
Date: Tue, 8 Mar 2016 06:11:53 +0000

Hi Greg,

Our initial consideration is to present these common parameters. But there is a little of difference on same terminology when it be extended to some technology specific oam(such as mpls-tp). For example:

for trill, there is cc-interval;

for mpls-tp, there are cc-transmit-interval and cc-receive-interval.

Therefore, I agree with you and I think we can remove these parameters in the next version.

Best Regards！

Michael

发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2016年3月8日 8:20
收件人: wangzitao; [email-masked]; [email-masked]
抄送: [email-masked]
主题: RE: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

Hi Michael,

                Regards,
                                Greg

To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Greg,

Best Regards!
Michael

Dear Authors, et. al,

and s/indent/identity/

[zitao]: agree

leaf interval {

type enumeration {

enum 3.3ms;

enum 10ms;

enum 20ms;

enum 50ms;

enum 100ms;

enum 1s;

enum 10s;

}

}

                Regards,

                                Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, February 29, 2016 7:48 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

                          Norman Finn

                          Deepak Kumar

                          Samer Salam

                          Qin Wu

                          Michael Wang

                Pages           : 47

                Date            : 2016-02-29

Abstract:

Lime mailing list

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Thu, 10 Mar 2016 02:51:00 +0000

Hi Greg,

Some thoughts…

I believe the cc-interval defined in draft-ietf-lime-yang-oam-model-02 is cc-transmit-interval. The same as cc-interval in TRILL which is also referred to cc-transmit-interval.
Therefore cc-interval is technology independent parameter and could be changed into cc-transmit-interval to make this more clear.

To support 3.3ms,we can consider the following two approaches:
1.Change unit from milliseconds into microseconds
“
  typedef transmit-Interval {
    type uint32;
    units "milliseconds";
    default "1000";
    description
      "Interval between packets in milliseconds.
       0 means no packets are sent.";
  }
”
2. Change type uint32 into decimal64
typedef transmit-Interval{
type decimal64{
  fraction-digits 2;
 units "milliseconds";
 description
 “Interval between packets in milliseconds.
   0 means no packets are sent.";
}
}

Hope it helps. Thanks again for your review and comments.

Best Regards,

Yan

Hi Michael,

                Regards,
                                Greg

Hi Greg,

Best Regards!
Michael

Dear Authors, et. al,

and s/indent/identity/

[zitao]: agree

leaf interval {

type enumeration {

enum 3.3ms;

enum 10ms;

enum 20ms;

enum 50ms;

enum 100ms;

enum 1s;

enum 10s;

}

}

                Regards,

                                Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, February 29, 2016 7:48 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lime] I-D Action: draft-ietf-lime-yang-oam-model-02.txt

                          Norman Finn

                          Deepak Kumar

                          Samer Salam

                          Qin Wu

                          Michael Wang

                Pages           : 47

                Date            : 2016-02-29

Abstract:

Lime mailing list