Subject: Re: [Lime] Progress on LIME Connectionless documents

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 3 Jul 2017 19:42:43 +0000

Hello, Greg,

The WG held real-time editathon interims in which we went comment by comment, many of those from you: https://datatracker.ietf.org/meeting/past#lime

After that, the editors have been diligently working through all the comments received, including all of yours (from WGLC and from before). There have been several iterations of document revision as all those comments were addressed and edits incorporated. As I had mentioned, addressing a comment does not necessarily imply changing the document — it can mean reply explaining why not.

I think that when you say “I've learned that my comments not taken into consideration” you are mischaracterizing the story. I witnessed the authors considering and discussing your comments, time and again. And when you further add “no one asked my opinion about the changes that went into the current version”, the editors asked the WG as a whole about the changes, we discussed them in person and in interims, and the process announces new revisions on list for interested parties to comment.

That said, and most importantly, if you feel you still have technical comments or unaddressed concerns on the current versions, I’d urge you to share those with clarity on the list. The editors and WG as a whole can review them and reply. There is no need to wait, the sooner things are addressed the better.

The goal of the WG is to produce quality and timely documents.

Thanks,

— Carlos.

On Jun 29, 2017, at 1:28 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
WGLC from January 2017? Considering that last time I've shared comments with authors at the meeting in Chicago, I'd consider that that WGLC had failed to clear the bar. But if WG chairs and AD believe differently, then the drafts were in the WG LC for five months.

As I've mentioned, I've shared my comments at the meetings, on the list and conference calls. Regrettably, I've learned that my comments not taken into consideration and too many misconceptions stayed in the documents from one version to another after I've pointed them out. I consider it professional courtesy to reach directly to reviewers to confirm that proposed changes address their concerns. Sadly, no one asked my opinion about the changes that went into the current version.

As I was not given time to review the latest version I took rather quick look at the connectionless OAM document and found the following:

   The level in 'oam-layers' indicate whether related OAM test point is
   The level in oam-layers indicate whether related oam test point is in
   client layer(lower layer described in section 3.3<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-07#section-3.3>), server layer
   (upper layer described in section 3.3<https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-07#section-3.3>) or the same layer as the
   current test point under Test point Locations.

I'm having hard time parsing this text and hope you can explain as you seem to be fine with it. And when I've followed on the reference to section 3.3

I've found that what I've commented on, suggested to change and authors verbally agreed to do still in place - {-1, 0, 1} model to indicate server-client layers.

But, as I've pointed many times, relationships between Test Points on different layers may be more complex and may skip some layers (Ethernet OAM with its 8 layers

in MEG may be one example). For the Test Points on the given OAM layer, notifications may be coming from different OAM layers down below. Current model,

as I read the text, does not allow such scenario.

But since I'm the only one who is, and frankly, has been commenting on these drafts throughout the time of the WG, I'll prepare thorough comments for the IETF LC.

I had privilege working and observing work of all authors and learned from them a lot, got to respect their professionalism. Cannot understand what happened this time.

Regards,

Greg

On Wed, Jun 28, 2017 at 3:02 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

I am astonished at your statement.

WGLCs:
https://mailarchive.ietf.org/arch/msg/lime/hcOi85Eu3dquUJZwWvx3BW_ZGbE
https://mailarchive.ietf.org/arch/msg/lime/4fRb9w-S9Z01x3CCRty7x8uhdmw

Your comments to the WGLCs:
https://mailarchive.ietf.org/arch/msg/lime/Bx6A0eqPRT4qXU8e_caXm4EElQA
https://mailarchive.ietf.org/arch/msg/lime/8_O41P0U4yy2zNfeX4jwxSZk6oU

After that the authors worked with you to incorporate your comments. Subsequent revisions prompted more comments from you, all of which were appropriately disposed of:
https://mailarchive.ietf.org/arch/msg/lime/x_ljuI0fvvNn2TSwj1BqXO6vgVo
https://mailarchive.ietf.org/arch/msg/lime/nQGL4cgWSaCWpNXiLnvgt_OqbSk

After that, the chairs gave you additional time and provided specific review to subsequent comments:
https://mailarchive.ietf.org/arch/msg/lime/oY44xRj9wm6aiqALdyRLuQ3j1BQ

A disposition to a comment means that they could have resulted in a change, or not.

IPR call coincinging with Adoption call:
https://mailarchive.ietf.org/arch/msg/lime/1ojMMWgjloC3FsE3Hp9E2JN2u00

I hope that clarifies?

Thanks,

— Carlos.

On Jun 28, 2017, at 4:47 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos and Ron,
thank you for the update on these drafts. I haven't seen IPR poll, WGLC on any of these. Have I missed them? I do have comments I'd like to share. Or should I wait for the IETF LC?

Regards, Greg

On Jun 28, 2017 1:27 PM, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG,

We will be progressing the LIME Connectionless documents, submitting them to our AD.

Please see the respective write-ups at:
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/shepherdwriteup/
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods/shepherdwriteup/

Thanks,

Carlos & Ron.

_______________________________________________
Lime mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: Qin Wu <[email-masked]>
Date: Tue, 4 Jul 2017 03:33:14 +0000

I think what Greg commented earlier is to make clarity on the definition of server layer, client layer, he didn’t point out the limitation of using level under oam-layer.
Maybe the train has leave the station. ☺

I think the debate is whether we use absolute relationship between tests points at different layer or use relative relationship between test points at different layer.
If we describe the relative relationship between test points using server layer, client layer and the same layer, I think we should make assumption that we know the order of the test points from source to destination, otherwise how to set level if we have more than 3 testpoints at different layer or level. I think index may implicitly indicate the order of these test points.
If we describe the absolute relationship between test points using (-8,8), or (-7,7), we also make assumption for the same protocol layer, we can not breakdown into several sub-layers. It is the downside of using absolute relationship.
Looks like both proposals have limitation, if we really want to tweak proposal, we may consider

a)       we add a protocol layer under oam-layer to stand for absolute stack layer. But technology under test-point-locations may have already indicated this.

b)       We expand the number of levels more than 8, e.g.,let’s say 16

-Qin
发件人: Lime [mailto:[email-masked]] 代表 Carlos Pignataro (cpignata)
发送时间: 2017年7月4日 3:43
收件人: Greg Mirsky
抄送: Benoit Claise (bclaise); [email-masked]
主题: Re: [Lime] Progress on LIME Connectionless documents

Hello, Greg,

Thanks,

— Carlos.

Hi Carlos,

Regards,

Greg

WGLCs:

I hope that clarifies?

Thanks,

— Carlos.

Hi Carlos and Ron,

Regards, Greg

Thanks,

Carlos & Ron.

—

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jul 2017 08:35:16 -0700

Hi Qin,
thank you for your consideration of my comment and sharing your arguments.
Indeed, I don't think that model that have only Self, Server and Client
layers can present some scenarios of multi-layer OAM application in
networks. And merely increasing that number to 8 or 16 layers, in my
opinion, would not be much better. In YANG terms I view OAM layers, as well
as their corresponding network layers, as entries on a list. The entries
are indexed and the index provides the key. Entries of the OAM list,
obviously, can represent connection-oriented or connectionless OAM.
Perhaps we can have side discussion in Prague. I'll try to prepare mode
detailed comments to both documents before then (the last two weeks before
the meeting are super-busy as always).

Regards,
Greg

On Mon, Jul 3, 2017 at 8:33 PM, Qin Wu <[email-masked]> wrote:

> I think what Greg commented earlier is to make clarity on the definition
> of server layer, client layer, he didn’t point out the limitation of using
> level under oam-layer.
>
> Maybe the train has leave the station. J
>
>
>
> I think the debate is whether we use absolute relationship between tests
> points at different layer or use relative relationship between test points
> at different layer.
>
> If we describe the relative relationship between test points using server
> layer, client layer and the same layer, I think we should make assumption
> that we know the order of the test points from source to destination,
> otherwise how to set level if we have more than 3 testpoints at different
> layer or level. I think index may implicitly indicate the order of these
> test points.
>
> If we describe the absolute relationship between test points using (-8,8),
> or (-7,7), we also make assumption for the same protocol layer, we can not
> breakdown into several sub-layers. It is the downside of using absolute
> relationship.
>
> a)       we add a protocol layer under oam-layer to stand for absolute
> stack layer. But technology under test-point-locations may have already
> indicated this.
>
> *发件人:* Lime [mailto:[email-masked]] *代表 *Carlos Pignataro
> (cpignata)
> *发送时间:* 2017年7月4日 3:43
> *收件人:* Greg Mirsky
> *抄送:* Benoit Claise (bclaise); [email-masked]
> *主题:* Re: [Lime] Progress on LIME Connectionless documents
>
>
>
> Hello, Greg,
>
>
>
> The WG held real-time editathon interims in which we went comment by
> comment, many of those from you: https://datatracker.ietf.
> org/meeting/past#lime
>
>
>
> After that, the editors have been diligently working through all the
> comments received, including all of yours (from WGLC and from before).
> There have been several iterations of document revision as all those
> comments were addressed and edits incorporated. As I had mentioned,
> addressing a comment does not necessarily imply changing the document — it
> can mean reply explaining why not.
>
>
>
> I think that when you say “I've learned that my comments not taken into
> consideration” you are mischaracterizing the story. I witnessed the authors
> considering and discussing your comments, time and again. And when you
> further add “no one asked my opinion about the changes that went into the
> current version”, the editors asked the WG as a whole about the changes, we
> discussed them in person and in interims, and the process announces new
> revisions on list for interested parties to comment.
>
>
>
> That said, and most importantly, if you feel you still have technical
> comments or unaddressed concerns on the current versions, I’d urge you to
> share those with clarity on the list. The editors and WG as a whole can
> review them and reply. There is no need to wait, the sooner things are
> addressed the better.
>
>
>
> On Jun 29, 2017, at 1:28 PM, Greg Mirsky <[email-masked]> wrote:
>
>
>
> Hi Carlos,
>
> WGLC from January 2017? Considering that last time I've shared comments
> with authors at the meeting in Chicago, I'd consider that that WGLC had
> failed to clear the bar. But if WG chairs and AD believe differently, then
> the drafts were in the WG LC for five months.
>
>
>
> As I've mentioned, I've shared my comments at the meetings, on the list
> and conference calls. Regrettably, I've learned that my comments not taken
> into consideration and too many misconceptions stayed in the documents from
> one version to another after I've pointed them out. I consider it
> professional courtesy to reach directly to reviewers to confirm that
> proposed changes address their concerns. Sadly, no one asked my opinion
> about the changes that went into the current version.
>
>
>
> As I was not given time to review the latest version I took rather quick
> look at the connectionless OAM document and found the following:
>
>    client layer(lower layer described in section 3.3 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-07#section-3.3>), server layer
>
>    (upper layer described in section 3.3 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-07#section-3.3>) or the same layer as the
>
> On Wed, Jun 28, 2017 at 3:02 PM, Carlos Pignataro (cpignata) <
> [email-masked]> wrote:
>
> Greg,
>
>
>
> After that the authors worked with you to incorporate your comments.
> Subsequent revisions prompted more comments from you, all of which were
> appropriately disposed of:
>
> On Jun 28, 2017, at 4:47 PM, Greg Mirsky <[email-masked]> wrote:
>
>
>
> Hi Carlos and Ron,
>
> thank you for the update on these drafts. I haven't seen IPR poll, WGLC on
> any of these. Have I missed them? I do have comments I'd like to share. Or
> should I wait for the IETF LC?
>
>
>
> Regards, Greg
>
>
>
> On Jun 28, 2017 1:27 PM, "Carlos Pignataro (cpignata)" <[email-masked]>
> wrote:
>
> Dear WG,
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-
> connectionless-oam-methods/shepherdwriteup/
>
>
>
> Thanks,
>
>
>
> Carlos & Ron.
>
>
> [email-masked]
> Carlos Pignataro, [email-masked]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 7 Jul 2017 03:58:45 +0000

I am not criticizing the limitation of two proposals discussed below. My augment is two proposals have been well investigated and compared, the current proposal we took in this draft is good enough based on the below analysis.

If you have better proposal, I am happy to hear. But I am surprised you again have your late comment since the draft has been shipped.

-Qin
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2017年7月6日 23:35
收件人: Qin Wu
抄送: Carlos Pignataro (cpignata); Benoit Claise (bclaise); [email-masked]
主题: Re: [Lime] Progress on LIME Connectionless documents

Hi Qin,
thank you for your consideration of my comment and sharing your arguments. Indeed, I don't think that model that have only Self, Server and Client layers can present some scenarios of multi-layer OAM application in networks. And merely increasing that number to 8 or 16 layers, in my opinion, would not be much better. In YANG terms I view OAM layers, as well as their corresponding network layers, as entries on a list. The entries are indexed and the index provides the key. Entries of the OAM list, obviously, can represent connection-oriented or connectionless OAM.
Perhaps we can have side discussion in Prague. I'll try to prepare mode detailed comments to both documents before then (the last two weeks before the meeting are super-busy as always).

Regards,
Greg

On Mon, Jul 3, 2017 at 8:33 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
I think what Greg commented earlier is to make clarity on the definition of server layer, client layer, he didn’t point out the limitation of using level under oam-layer.
Maybe the train has leave the station. ☺

-Qin
发件人: Lime [mailto:[email-masked]<mailto:[email-masked]>] 代表 Carlos Pignataro (cpignata)
发送时间: 2017年7月4日 3:43
收件人: Greg Mirsky
抄送: Benoit Claise (bclaise); [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] Progress on LIME Connectionless documents

Hello, Greg,

Thanks,

— Carlos.

Hi Carlos,

Regards,

Greg

WGLCs:

I hope that clarifies?

Thanks,

— Carlos.

Hi Carlos and Ron,

Regards, Greg

Thanks,

Carlos & Ron.

—

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jul 2017 21:01:43 -0700

Hi Qin,
I've to point that this is not "new" proposal but rather proposal editors
of the document, apparently, disregarded.

Regards,
Greg

On Thu, Jul 6, 2017 at 8:58 PM, Qin Wu <[email-masked]> wrote:

> I am not criticizing the limitation of two proposals discussed below. My
> augment is two proposals have been well investigated and compared, the
> current proposal we took in this draft is good enough based on the below
> analysis.
>
>
>
> If you have better proposal, I am happy to hear. But I am surprised you
> again have your late comment since the draft has been shipped.
>
>
>
> -Qin
>
> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2017年7月6日 23:35
> *收件人:* Qin Wu
> *抄送:* Carlos Pignataro (cpignata); Benoit Claise (bclaise); [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Fri, 7 Jul 2017 04:09:37 +0000

Which one is your proposal,  you just raise the question, we have discussed two possible proposals we authors discussed before,
We compared these proposals and have selected the best proposal.

As I said, if you have better proposal ,please share to the list. Sure, we can discuss in Prague if you have concrete proposal, thanks.

-Qin
发件人: Lime [mailto:[email-masked]] 代表 Greg Mirsky
发送时间: 2017年7月7日 12:02
收件人: Qin Wu
抄送: Benoit Claise (bclaise); Carlos Pignataro (cpignata); [email-masked]
主题: Re: [Lime] Progress on LIME Connectionless documents

Hi Qin,
I've to point that this is not "new" proposal but rather proposal editors of the document, apparently, disregarded.

Regards,
Greg

On Thu, Jul 6, 2017 at 8:58 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
I am not criticizing the limitation of two proposals discussed below. My augment is two proposals have been well investigated and compared, the current proposal we took in this draft is good enough based on the below analysis.

-Qin
发件人: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2017年7月6日 23:35
收件人: Qin Wu
抄送: Carlos Pignataro (cpignata); Benoit Claise (bclaise); [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] Progress on LIME Connectionless documents

Hi Qin,

Regards,
Greg

-Qin

Hello, Greg,

Thanks,

— Carlos.

Hi Carlos,

Regards,

Greg

WGLCs:

I hope that clarifies?

Thanks,

— Carlos.

Hi Carlos and Ron,

Regards, Greg

Thanks,

Carlos & Ron.

—

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jul 2017 21:22:11 -0700

Qin,
the two proposals you've argued  are all yours, not mine. When I've
commented on this issue (it was either in mail before or during the meeting
in Chicago) I've pointed that OAM layers are not relative but OAM is of
specific layer of the network.  Thus the reference should be to the layer
as it presented in the multi-layer network's model.

Regards,
Greg

On Thu, Jul 6, 2017 at 9:09 PM, Qin Wu <[email-masked]> wrote:

> Which one is your proposal,  you just raise the question, we have
> discussed two possible proposals we authors discussed before,
>
> As I said, if you have better proposal ,please share to the list. Sure, we
> can discuss in Prague if you have concrete proposal, thanks.
>
>
>
> -Qin
>
> *发件人:* Lime [mailto:[email-masked]] *代表 *Greg Mirsky
> *发送时间:* 2017年7月7日 12:02
> *收件人:* Qin Wu
> *抄送:* Benoit Claise (bclaise); Carlos Pignataro (cpignata); [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Fri, 7 Jul 2017 04:49:11 +0000

Why distinct yours from ours?:-)
The below proposals we have discussed, one is about relative relationship/layer (implemented in the current draft), the other is about absolute relationship/layer.
It is obvious that you favor the second proposal, i.e., go with absolute layer approach, which we revisited recently again and compare with our current proposal in the draft.
Let us know if you want to go with absolute layer approach.

-Qin
发送时间: 2017年7月7日 12:22

Qin,
the two proposals you've argued  are all yours, not mine. When I've commented on this issue (it was either in mail before or during the meeting in Chicago) I've pointed that OAM layers are not relative but OAM is of specific layer of the network.  Thus the reference should be to the layer as it presented in the multi-layer network's model.

Regards,
Greg

On Thu, Jul 6, 2017 at 9:09 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Which one is your proposal,  you just raise the question, we have discussed two possible proposals we authors discussed before,
We compared these proposals and have selected the best proposal.

-Qin
发件人: Lime [mailto:[email-masked]<mailto:[email-masked]>] 代表 Greg Mirsky
发送时间: 2017年7月7日 12:02
收件人: Qin Wu
抄送: Benoit Claise (bclaise); Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] Progress on LIME Connectionless documents

Hi Qin,

Regards,
Greg

-Qin

Hi Qin,

Regards,
Greg

-Qin

Hello, Greg,

Thanks,

— Carlos.

Hi Carlos,

Regards,

Greg

WGLCs:

I hope that clarifies?

Thanks,

— Carlos.

Hi Carlos and Ron,

Regards, Greg

Thanks,

Carlos & Ron.

—

---

From: Ron Bonica <[email-masked]>
Date: Fri, 7 Jul 2017 13:26:52 +0000

Greg,

My recollection is identical to Carlos’

                         Ron

From: Lime [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, July 3, 2017 3:43 PM
To: Greg Mirsky <[email-masked]>
Cc: Benoit Claise (bclaise) <[email-masked]>; [email-masked]
Subject: Re: [Lime] Progress on LIME Connectionless documents

Hello, Greg,

Thanks,

— Carlos.

Hi Carlos,

Regards,

Greg

WGLCs:

I hope that clarifies?

Thanks,

— Carlos.

Hi Carlos and Ron,

Regards, Greg

Thanks,

Carlos & Ron.

—

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 Jul 2017 14:57:15 +0200

rentiate Dear WG Chairs, WG Responsible AD and members if LIME WG expert
community,
please find my comments to both documents below.

Major:

   - OAM protocols address 'F' and 'P' of the FCAPS, i.e. Fault Management
   and Performance Monitoring. The defined models address only Fault
   Management part leaving the performance measurement protocols, e.g. RFC
   6374, RFC 6375 out side their scope. I suggest to clarify and update titles
   by including "Fault Management OAM" in.

draft-ietf-lime-yang-connectionless-oam:

   - Introduction:
      - I cannot agree with the explanation of what differentiates
      connection-oriented network domain from connectionless, as difference of
      arranging network vs. without the prior arrangement. I'll point that
      signalling IP/MPLS LSP is the prerequisite of availability of
the path even
      though IP/MPLS LSP is, in general, an example of connectionless domain.
   - Section 3:
      - the section is the first reference to the grouping tp-address-vrf.
      Though local test point (TP) may be associated with the particular vrf
      identity, none of OAM protocols, e.g. IP ping, LSP ping or BFD carry VRF
      identity. Thus using vrf as part of tp-address-vrf grouping in container
      dest-test-point of path-discovery-data grouping and of
      continuity-check-data, or path-trace-info-list is problematic at the very
      minimum;
      - the connectionless-oam-layers grouping does present serious
      problem, in my opinion. Obviously, there may be more than three layers in
      the network and lower layer(s) well could be not connectionless but
      connection-oriented OAM domain. Additionally, source and destination TPs
      will always be on the same network layer, so that use of the
      connectionless-oam-layers in test-point-location-info is not warranted in
      my view.
   - Section 3.3
      - the section attempts to give extended example of how the
      connectionless-oam-layers may have value other than the default
0. I think
      that it is more confusing than without it. Administrative domains on the
      same layer interact as peers and thus cannot and should not be
referring to
      each other as server-client. If the network tunneled through the
particular
      domain, then the tunnel, on that layer, is presented as single hop. True,
      the tunnel in that domain may have transport OAM with notification to the
      edge TPs of the network OAM. But that transport OAM would not be part of
      the network OAM and access to it, in my view, could be only through state
      of multi-layer OAM where each layer is indexed and relationships between
      TPs identified by these indexes.
   - Section 4
      - I have many questions to the choice of TP types:
         - what is the difference, from OAM point, between unicast IP
         address and multicast/group IP address, whether IPv4 or IPv6.
         - I think that inclusion of MAC as MP address type in
         connectionless OAM would benefit from more explanation, use
case. TRILL?
         AFAIK, in TRILL ping is used to ping RBridge, not MAC. What is/are use
         case(s) for MAC as MP address in connectionless OAM model?
         -

         ip-prefix-address-type referenced only once as identity and
doesn't appear anywhere as use case. Is it stale type of MP address?

         -

         tunnel-address-type, as above, referenced only once as
identity  and does look as stale MP address type;

         -

         I think that there's disconnect between type definition of
leaf route-distinguisher as unit32 and the description that states:

Route Distinguisher is an 8 octets identifier

used to distinguish information about variousL2VPN advertised by a node.

   - type definition of sender-ve-id and receiver-ve-id may be changed
from uint32 to uint16 since both parameters are, as noted in
respective descriptions, two octets long;
         - what is the source of queue-depth, Length of the egress
interface queue of the interface", as explained in the description.
Firstly, not sure what "egress interface" of the interface is.
Secondly, is this static or dynamic information? If the former, then
there's no need to include it in path-trace-info;
         - the transit-delay, as explained in the description,
reflects residence time. What OAM protocols, e.g. traceroute, LSP
Ping, provide residence time?
         - what is the purpose of app-meta-data in path-trace-info container?
         - what is the reason to differentiate between IPv4 and IPv6
continuity check session statistics if both cases end up using
cc-session-statistics.

Summarizing, I believe that draft-ietf-lime-yang-connectionless-oam is
not ready for publication.

I'll work on reviewing draft-ietf-lime-yang-connectionless-oam-methods
and will share my comments with you all.

Regards,

Greg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 20 Jul 2017 14:31:46 +0200

Dear All,
below please find my comments to the current version
of draft-ietf-lime-yang-connectionless-oam-methods draft:

   - Abstract
      - "... interactive OAM workflows ( i.e., performing OAM functions at
      same levels through a unified interface)." I think that
"interactive" does
      not accurately characterizes the relationship between domains on the same
      network layer. "Interworking" would be more accurate or, at the minimum,
      "interacting".
   -

   OAM Retrieval Methods Hierarchy

   - as noted in comments to draft-ietf-lime-yang-connectionless-oam, need
      use case for Test Point of mac-address type;
      - src-dst-address is not part of draft-ietf-lime-yang-connectionless-oam
      tp-address grouping. Stale hierarchy?
      - fec-type is not listed in tp-address grouping either. Another stale
      element?
      - tlv-address - same story, stale.
   -

   OAM Retrieval Methods YANG Module

   - leaf count (number of packets that will be sent) has type uint32 and
      thus cannot support "forever" mode. I believe support of
"forever" mode is
      important and should be provided;

Summarizing, in my opinion the current version of
draft-ietf-lime-yang-connectionless-oam-methods is not ready for
publication.

Regards,
Greg