Subject: Re: [Lime] WG Last Call

From: Huub van Helvoort <[email-masked]>
Date: Fri, 01 Jul 2016 16:58:59 +0200

All,

I agree with all the comments below.

Best regards, Huub.

On 28-06-16 00:55, Varma, Eve (Nokia - US) wrote:
> Dear all,
>
> As you may recall, last August some concerns were expressed regarding whether the LIME YANG OAM DM was truly generic.  While the original draft was subsequently split into two drafts - one for connection oriented technologies and one for connectionless - which helped - such validation was understood as still needed for the domain each was intending to represent.
>
> If I read the LIME charter correctly, while not chartered to work on information or data models specific to any data plane or forwarding plane technology developed outside of the IETF, it was intended that the resultant data model would be applicable to multiple layers and technologies in a technology agnostic fashion.  Thus, It had been my expectation that - prior to LC - the draft would be liaised to other SDO/forums to see if it satisfies their layer specific requirements given L0-L2 OAM/OAM mgmt is in the province of ITU-T, MEF, IEEE.  I was dismayed to see that a 2 week lime WG LC, closing July 7th, was issued without this having been done.
>
> In my view the LC should be terminated and the appropriate liaisons be generated to enable this review to take place.  Further, the liaison response window needs to be greater than 2 weeks to accommodate the response liaison approval process timeframes of the relevant SDOs/forums.
>
>
> With best regards,
> Eve
>
>
> -----Original Message-----
> From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
> Sent: Thursday, June 23, 2016 1:57 PM
> To: [email-masked]
> Subject: [Lime] WG Last Call
>
> Folks,
>
> This message begins a WG last call for draft-ietf-lime-yang-oam-model-06. Last call ends on July 7, 2016.
>
>                                    Ron
>

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 1 Jul 2016 17:18:14 +0000

Huub, Eva,

Thanks for reviewing this draft. We appreciate that may OAM experts are active in the ITU-T. For this reason, we notified ITU-T when LIME was chartered. 

The LIME YANG models provide a framework to be extended with technology-specific OAM information. The technologies that are expected to extend the LIME models are all IETF technologies. Therefore, this work is somewhat IETF specific and, IMO, should be worked inside the IETF. 

As always, anyone is welcome to participate in the WG last call. Interested parties should post substantive comments to the mailing list. In order to solicit this input, I am asking Benoit to send a non-blocking, non-normative liaison to ITU-T. We will let this last call run to completion, but as there are other substantive comments regarding the draft, we will require another draft version. When that is available, we will initiate another WG Last Call.

                                                                                                    Ron

> From: Huub van Helvoort [mailto:[email-masked]]
> Sent: Friday, July 1, 2016 10:59 AM
> To: Varma, Eve (Nokia - US) <[email-masked]>; Ronald Bonica
> <[email-masked]>; [email-masked]
> Subject: Re: [Lime] WG Last Call
> 
> All,
> 
> > As you may recall, last August some concerns were expressed regarding
> whether the LIME YANG OAM DM was truly generic.  While the original draft
> was subsequently split into two drafts - one for connection oriented
> technologies and one for connectionless - which helped - such validation was
> understood as still needed for the domain each was intending to represent.
> >
> > If I read the LIME charter correctly, while not chartered to work on
> information or data models specific to any data plane or forwarding plane
> technology developed outside of the IETF, it was intended that the resultant
> data model would be applicable to multiple layers and technologies in a
> technology agnostic fashion.  Thus, It had been my expectation that - prior to
> LC - the draft would be liaised to other SDO/forums to see if it satisfies their
> layer specific requirements given L0-L2 OAM/OAM mgmt is in the province of
> ITU-T, MEF, IEEE.  I was dismayed to see that a 2 week lime WG LC, closing
> July 7th, was issued without this having been done.
> >
> > In my view the LC should be terminated and the appropriate liaisons be
> generated to enable this review to take place.  Further, the liaison response
> window needs to be greater than 2 weeks to accommodate the response
> liaison approval process timeframes of the relevant SDOs/forums.
> >
> >
> > With best regards,
> > Eve
> >
> >

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 1 Jul 2016 18:57:49 +0000

Dear Authors, WG chairs, et. al,

please find my comments to the latest version of the document below.

*         I think that the section 7.2 that discusses MPLS-TP OAM YANG  module must reference YANG data model for MPLS-TP draft-zhang-mpls-tp-yang-oam at least as Informational reference (to avoid dependency if it is Normative one);

*         I think that since MPLS-TP OAM uses different terminology if compared with the draft-ietf-lime-yang-oam-model, mapping must be established in the document under review. For example, Maintenance Domain is analogous to Maintenance Entity Group, and Maintenance Association is analogous to Maintenance Entity.

*         section 7.2.2

o   "Meg-Id parameter under MA data node will be selected for MPLT-TP OAM model." I think that you've chosen the wrong ID. MA is analogous to ME, not MEG. Please check with draft-zhang-mpls-tp-yang-oam.

o   s/ MPLT-TP/MPLS-TP/

*         section 7.2.2.1

o   "In MPLS-TP, one example of connectivity-context is a 20 bit MPLS  label." Labels in MPLS-TP don't have context as these are transport, not application labels and are unique only for allocating LSR.

*         section 7.2.4 "...are extended with MPLS-TP specific such as exp ..." I assume you were referring to Traffic Class (TC) field. Again, please refer to draft-zhang-mpls-tp-yang-oam for RPC definitions.

In conclusion, I'm glad that most of my earlier comments been addressed and thank you authors for thorough consideration. But I think that this document needs another version.

                Regards,

                                Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Thursday, June 23, 2016 10:57 AM
To: [email-masked]
Subject: [Lime] WG Last Call

Folks,

                                  Ron

_______________________________________________

Lime mailing list

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

https://www.ietf.org/mailman/listinfo/lime

---

From: Yuji Tochio <[email-masked]>
Date: Mon, 4 Jul 2016 14:24:10 +0900

All,

I also agree all the comments below.
My comments to the draft will be sent by another mail.

Regards, Yuji

On 2016/07/01 23:58, Huub van Helvoort wrote:
>> As you may recall, last August some concerns were expressed regarding whether the LIME YANG OAM DM was truly generic.  While the original draft was 
>> subsequently split into two drafts - one for connection oriented technologies and one for connectionless - which helped - such validation was understood as 
>> still needed for the domain each was intending to represent.
>>
>> If I read the LIME charter correctly, while not chartered to work on information or data models specific to any data plane or forwarding plane technology 
>> developed outside of the IETF, it was intended that the resultant data model would be applicable to multiple layers and technologies in a technology agnostic 
>> fashion.  Thus, It had been my expectation that - prior to LC - the draft would be liaised to other SDO/forums to see if it satisfies their layer specific 
>> requirements given L0-L2 OAM/OAM mgmt is in the province of ITU-T, MEF, IEEE.  I was dismayed to see that a 2 week lime WG LC, closing July 7th, was issued 
>> without this having been done.
>>
>> In my view the LC should be terminated and the appropriate liaisons be generated to enable this review to take place. Further, the liaison response window 
>> needs to be greater than 2 weeks to accommodate the response liaison approval process timeframes of the relevant SDOs/forums.
>>
>>
>> With best regards,
>> Eve
>>
>>

---

From: Yuji Tochio <[email-masked]>
Date: Mon, 4 Jul 2016 14:37:06 +0900

Dear authors of the draft,

Here are my comments/questions to draft-ietf-lime-yang-oam-model-06.
I am glad these comments are considered.

Regards, Yuji

---------------------------------------------------------------
1) Base mode [section 4]

The text says:
"Base mode for other technologies such as MPLS-TP
and future extensions will be defined in their
corresponding documents."

I am worrying what other technologies except MPLS-TP mean.

Is Base Mode for Ethernet CFM (802.1Q or G.8013) out of
the scope (or N/A)?  If Yes, need to clarify in section 4
like replacing

other technologies such as MPLS-TP and future extensions

by

other technologies and future extensions developed in IETF

2) PM (Performance Monitoring)

PM aspects are missing.
In my understanding, draft-wang-lime-yang-pm will be
incorporated but the current draft (lime-yang-oam) is not.
I would like to address this draft should be completed
after PM parts are completed.

3) MP and MEP [section 4.3]

In general, it seems that the this YANG module is mixing
MEP for Ethernet/MPLS-TP and MP for TRILL and make it MEP
for LIME.

In TRILL OAM, mp-address is defined for/within source-MEP
and destination-MEP, but the idea of source-MEP and
destination-MEP does not entirely suit to Ethernet.

It is noted that source-MEP and destination-MEP is local
terminologies of MEP found only in TRILL.
Please see [IEEE802.1Q] and [ITU-T G.8013/Y.1731] or [G.8001]
how xxx MEP(s) is(are) defined.

And MP Addressing in RFC 7147 is somehow different from [802.1Q].

So far modeling for MEP and MP (including rpc) should be
considered on this point, i.e. not mixing MEP for Ethernet
and MP for TRILL.

4) MEP ID/MEP name [section 4.3]

In section 4.3, MEPs are represented as mep-name, MEP-ID, and
mp-address (mep address).
I am still confused why these 3 attributes are considered.

Per [802.1Q] and [G.8013/Y.1731], it is true for MEP ID defined as:
- MEP ID is a 2-octet field where the 13 least significant bits
are used to identify the MEP transmitting the CCM frame. MEP ID
is unique within the MEG. (ITU-T G.8013 9.2.1)
- Each individual MEP is configured with a MEPID that is unique
within that MA. (IEEE802.1Q 19.2.1)
It is noted that the type for mep-id is int32.

And I am not sure  why MEP-ID-format is also required as well.

Mep-name defines "Generic administrative name of the MEP" in the
YANG module and section 4.3 says it is used for indexing MEP.
I understand the usage, but is it really required to use
mep-name for configuration MEP?

5) Configuration data structure for MEP

Reading MEP in ietf-conn-oam, the MEP is regarded as bidirectional
end point that includes both generation process and reception process.
[G.8052] defines MEP that includes generation process and reception
process (i.e. Source and Sink).

In fact, Ethernet CCM works as one-way (called Dual-ended) so
that the clear distinction for MEP source and sink is defined in
[G.8052].

A good example is period (transmit-interval in this draft).
To works the CC mechanism, the configuration both for transmit and
reception. The configuration of reception is used for defect for
LoC and unexpected Period.

This draft should consider MEP source and sink.
An impact of this issue leads to the support of dual-ended OAM tools
and/or OAM tools for performance monitoring.

6) Default MD-LEVEL

Section 6.3 of the draft says "Default MD-LEVEL is set to 3".
This seems come from [802.1Q] but the value depends on the
architecture of network service.

Actually, but the has some inconsistency with MEL modeling
in ITU-T G.8052 that provides IM for Ethernet OAM.
G.8052 defines the management of MEP based on G.8013/Y.1731,
that a MEP with MEL = 7 corresponds to the NCM MEP and a
MEP with other MEL values are considered as TCM MEP.
(NCM/TCM: Network/Tandem Connection Monitoring)

So the proposed is remove the sentence in 6.3.

7) TTL usage for CV (connectivity verification)

How about the default value for mpls-ttl?

RFC 6426 says:
In order for the on-demand CV packet to be processed
at the desired MIP, the TTL of the MPLS label MUST be set such
that it expires at the MIP to be probed.

It is also applicable to use 255, same as IP, so it looks hard
to define the default value.

But it is better to describe how to set the TTL. The description
may help this.

8) defect-types

Some defect-types are defined. I am confused by these errors.
Following comments are some examples:

- remote-mep-error

It says:
"Indicates that one or more of the remote MEPs is reporting a failure"

Do(es) MEP(s) report the failure to peer MEP for the MEP(s) or to EMF?
Given that it is the latter case, why does it differentiated from the
peer MEP to the MEP(s).
Or is it an error related to validation fail? (RFC 6426)

- invalue-oam-error

It says:
  "Indicates that one or more invalid OAM messages has been
received and that 3.5 times that OAM message transmission
interval has not yet expired."

First, this will be equivalent to  5.1.1.2 to 5.1.1.4 in RFC 6371,
and 5.1.1.1 (dLOC) is missing.
Is it (not including LOC) intentional?

And invalue looks typo, it should be invalid.

- cross-connect-error

It says:
"Indicates that one or more cross-connect oam messages has been
received and that 3.5 times that OAM message transmission
interval has not yet expired.

Please clarify what "one or more cross-connect oam messages" means

9) MIP modeling

I am not sure why and how MIP is modeled as:

   grouping MIP {
     description
       "defines MIP";
     leaf interface {
       type if:interface-ref;
       description
          "Interface";
     }
   }

At least, MIP address and ID (and name?) may be required for CV
(Loopback) functions. I would like to ask for clarification.

10) Terminology

    MEP   - Maintenance End Point [RFC7174] [IEEE802.1Q] [RFC6371].

    MIP   - Maintenance Intermediate Point [RFC7174] [IEEE802.1Q]
          [RFC6371].

These 3 references above define different abbreviation for MEP and MIP.

---------------------------------------------------------------

On 2016/06/24 2:56, Ronald Bonica wrote:
> [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Tue, 5 Jul 2016 03:55:37 +0000

Greg:
Thank for your comments. I am confusing with the analogue given below.
RFC6371 define ME as follows:
“
   Maintenance Entity (ME): Some portion of a transport path that
   requires management bounded by two points (called MEPs), and the
   relationship between those points to which maintenance and monitoring
   operations apply (details in Section 3.1<https://tools.ietf.org/html/rfc6371#section-3.1>).

”
ME is actually referred to a subpath between two measurement points, one example of ME is LSP or PW or a tunnel.

RFC 6371 further define MEG as:
“

   Maintenance Entity Group (MEG): The set of one or more maintenance

   entities that maintain and monitor a section or a transport path in

   an OAM domain.

”
Which align with MA definition give in the IEEE802.1q amendment
https://en.wikipedia.org/wiki/IEEE_802.1ag
as follows:
“
Maintenance Association (MA)
Defined as a "set of MEPs, all of which are configured with the same MAID (Maintenance Association Identifier)
”
It looks it is apparent that MA is equivalent to MEG since two measurement points constitute ME, therefore a set of maintenance entities can be interpreted as
as a set of measurement points as well.
Therefore MA+MD is equivalent to MEG, both measurement point and measurement segment/ME should be under MA or MEG.

-Qin
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2016年7月2日 2:58
收件人: Ronald Bonica; [email-masked]
主题: Re: [Lime] WG Last Call

・         I think that the section 7.2 that discusses MPLS-TP OAM YANG  module must reference YANG data model for MPLS-TP draft-zhang-mpls-tp-yang-oam at least as Informational reference (to avoid dependency if it is Normative one);

・         I think that since MPLS-TP OAM uses different terminology if compared with the draft-ietf-lime-yang-oam-model, mapping must be established in the document under review. For example, Maintenance Domain is analogous to Maintenance Entity Group, and Maintenance Association is analogous to Maintenance Entity.

・         section 7.2.2

o   “Meg-Id parameter under MA data node will be selected for MPLT-TP OAM model.” I think that you’ve chosen the wrong ID. MA is analogous to ME, not MEG. Please check with draft-zhang-mpls-tp-yang-oam.

o   s/ MPLT-TP/MPLS-TP/

・         section 7.2.2.1

o   “In MPLS-TP, one example of connectivity-context is a 20 bit MPLS  label.” Labels in MPLS-TP don’t have context as these are transport, not application labels and are unique only for allocating LSR.

・         section 7.2.4 “…are extended with MPLS-TP specific such as exp …” I assume you were referring to Traffic Class (TC) field. Again, please refer to draft-zhang-mpls-tp-yang-oam for RPC definitions.

In conclusion, I’m glad that most of my earlier comments been addressed and thank you authors for thorough consideration. But I think that this document needs another version.

                Regards,

                                Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Thursday, June 23, 2016 10:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lime] WG Last Call

Folks,

                                  Ron

Lime mailing list

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 5 Jul 2016 17:39:42 +0000

Hi Qin,
thank you for your thoroughness and pointing to misattribution on my part. I think it would be even clearer if the document refers to the table in Appendix V of G.8013 that establishes mapping between CFM and G.8013/Y.1731:
Note, that MPLS-TP OAM terminology uses terminology of ITU-T G.8013/Y.1731.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Monday, July 04, 2016 8:56 PM
To: Gregory Mirsky; Ronald Bonica; [email-masked]
Subject: RE: WG Last Call

Greg:

”

   an OAM domain.

”

-Qin
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2016年7月2日 2:58
收件人: Ronald Bonica; [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] WG Last Call

・         section 7.2.2

o   s/ MPLT-TP/MPLS-TP/

・         section 7.2.2.1

                Regards,

                                Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Thursday, June 23, 2016 10:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lime] WG Last Call

Folks,

                                  Ron

Lime mailing list

---

From: "Varma, Eve (Nokia - US)" <[email-masked]>
Date: Wed, 6 Jul 2016 15:58:09 +0000

Hi Ron,

Thanks for your response - please see below for some further observations.

Best regards,

Eve

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Friday, July 01, 2016 1:18 PM
To: [email-masked]; Varma, Eve (Nokia - US); [email-masked]; Benoit Claise (bclaise)
Subject: Re: [Lime] WG Last Call

Huub, Eva,

<ELV>  I was looking through the liaison files, but had some difficulty finding the one you're citing.  Could you point it out to me? In any case, it would be a typical expectation that subsequent work would have been liaised for review/feedback to ITU-T SG 15/IEEE/MEF prior to LC, given their relevant specification development (e.g., ITU-T SG 15 Recommendations regarding transport technology-specific and generic OAM).

<ELV> If the intention is that the only technologies expected to extend the LIME models are from IETF (i.e., not L0-L2 as described in https://datatracker.ietf.org/doc/draft-lam-lime-summary-l0-l2-layer-independent/), then the title of the draft is misleading.  It should be modified, as well as the introduction, to make explicit that the YANG DM is only generic across IETF technologies (and not L0-L2).

<ELV> Could you clarify whether you are planning to request a review of the document to gather additional input, or just share FYI?  In either case, the draft's title and introduction should first be amended to clearly reflect its actual scope.

                                                                                                Ron

> To: Varma, Eve (Nokia - US) <[email-masked]<mailto:[email-masked]>>; Ronald Bonica

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

> > As you may recall, last August some concerns were expressed

> > regarding

> whether the LIME YANG OAM DM was truly generic.  While the original

> draft was subsequently split into two drafts - one for connection

> oriented technologies and one for connectionless - which helped - such

> validation was understood as still needed for the domain each was intending to represent.

> information or data models specific to any data plane or forwarding

> plane technology developed outside of the IETF, it was intended that

> the resultant data model would be applicable to multiple layers and

> technologies in a technology agnostic fashion.  Thus, It had been my

> expectation that - prior to LC - the draft would be liaised to other

> SDO/forums to see if it satisfies their layer specific requirements

> given L0-L2 OAM/OAM mgmt is in the province of ITU-T, MEF, IEEE.  I

> was dismayed to see that a 2 week lime WG LC, closing July 7th, was issued without this having been done.

> > In my view the LC should be terminated and the appropriate liaisons

> > be

> generated to enable this review to take place.  Further, the liaison

> response window needs to be greater than 2 weeks to accommodate the

> response liaison approval process timeframes of the relevant SDOs/forums.

> > This message begins a WG last call for draft-ietf-lime-yang-oam-model-06.

> Last call ends on July 7, 2016.

> ==========================================================

> ======

Lime mailing list

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 7 Jul 2016 11:18:36 +0000

Dear Eve,

Please find one additional comment:

While we are working on the liaison statements, the WG and you should not wait for the official liaison to send feedback on the LIME mailing list. In other words, these are not serialized sequential dependent activities.

Thanks!

— Carlos.

On Jul 6, 2016, at 11:58 AM, Varma, Eve (Nokia - US) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ron,

Best regards,
Eve

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Friday, July 01, 2016 1:18 PM
To: [email-masked]<mailto:[email-masked]>; Varma, Eve (Nokia - US); [email-masked]<mailto:[email-masked]>; Benoit Claise (bclaise)
Subject: Re: [Lime] WG Last Call

Huub, Eva,

<ELV> Could you clarify whether you are planning to request a review of the document to gather additional input, or just share FYI?  In either case, the draft’s title and introduction should first be amended to clearly reflect its actual scope.
                                                                                                Ron

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 Jul 2016 14:28:48 +0000

Hi Eva,

Inline........

                 Ron

From: Varma, Eve (Nokia - US) [mailto:[email-masked]]
Sent: Wednesday, July 6, 2016 11:58 AM
To: Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; Benoit Claise (bclaise) <[email-masked]>
Subject: RE: [Lime] WG Last Call

Hi Ron,

Best regards,

Eve

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Friday, July 01, 2016 1:18 PM
To: [email-masked]<mailto:[email-masked]>; Varma, Eve (Nokia - US); [email-masked]<mailto:[email-masked]>; Benoit Claise (bclaise)
Subject: Re: [Lime] WG Last Call

Huub, Eva,

[RB ]

It would be a NEWWORK announcement.

[RB ]

Please redirect this comment to the authors so that they can take it into consideration.

[RB ]

Just share FYI

                                                                                                Ron

Lime mailing list