Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 2 Jul 2015 02:13:15 +0000

Hi Yuji,

Inline +++DK:

On 6/23/15, 11:54 PM, "Yuji Tochio" <[email-masked]> wrote:

>Hi all,
>
>The authors of draft-tissa-lime-yang-oam-model asked for comments to the
>authors of draft-lam-lime-summary-l0-l2-layer-independent.
>So far, I, as a co-author of draft-lam..., have collected comments among
>us and here are attached the comments as below.
>
>I hope the comments will contribute the progress of
>draft-tissa-lime-yang-oam-model.
>
>
>Regards,
>Yuji
>
>------
>Comments
>
>1. Common OAM architecture
>
>This document defines the relationship of different OAM YANG model that
>covers MPLS, IP, NVO3, TRILL and so on. But there seems to be no Common
>OAM architecture 
>for them, but the common OAM architecture in this draft adapts those for
>Ethernet (IEEE802.1Q and ITU-T G.8013/Y.1731) or MPLS-TP (RFC 6371).
>Given that this draft covers only Ethernet and MPLS-TP OAM, it would not
>have any issues. But how about other technologies like IP or (IP/)MPLS?
>Do they use the 
>architecture same as Ethernet or MPLS-TP?

+++DK: 

We discussed in the LIME Design team meeting, Testing point, fault domain,
technology type, addressing, etc are common elements. MEP is implicit in
IP.
In various architectures for different OAM technologies. In addition,
RFC7276 also gives a summary of common OAM functions used in OAM-related
standards.
Here what we are doing is to adopt OAM concepts defined for Ethernet or
MPLS-TP architecture
and represent these common elements using some kind of technology
independent template.
CFM model is a good basis to define such template, we extend it to a
technology independent framework.
That is to say, different OAM technologies share the same OAM concept and
can therefore be consolidated into technology independent framework.
"

>
>
>2. Common tools for OAM
>
>The current draft only describes based on Ethernet CCM so that all the
>parameters in the draft come basically from those for configuring MEPs of
>Ethernet (and 
>some for IPv4 and IPv6).
>For the definition of Generic OAM, it is required to describe what kind
>of the tool sets are considered in this draft.
>The good example is in Table 7-1 of ITU-T G.8113.2.

+++DK:
Good point, we will add table from RFC7276 and model it like Table 7-1.

>
>
>3. Configuration data structure for MEP (section 4.3)
>
>Reading MEP in ietf-gen-oam, the MEP is regarded as bidirectional end
>point that includes both generation process and reception process.
>ITU-T G.8052 (or ONF work for OAM) 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.
>This draft should be consider MEP source and sink.
>Also co-located sink MEP in case of a bi-directional connection should be
>considered.

+++DK:We can update it with source and sink information.
>
>
>4. Output in rpcs
>Output in rpcs includes performance monitoring (i.e Delay measurement,
>Loss measurement)related configuration data, But it looks as a part of CC
>and CV 
>functionalities.
>As seen in ITU-T G.8013 (DM, LM, and Synthetic LM) and PM for Trill OAM,
>the output (PM related configuration data) should be regarded in more
>generic way.
>BTW, the YANG for the output says:
>
>     output {
>       uses monitor-stats {
>         description
>           "Stats of continuity check is same as that of
>            monitor sessions";
>       }
>     }
>   }
>
>
>What does mean by "Stats of continuity check is same as that of monitor
>sessions"?

+++DK: We can fix this description with better wording.

>
>
>5. Defect type
>
>It describes as:
>    notifications:
>       +---n defect-condition-notification
>          +--ro technology          identityref
>:
>          +--ro defect-type?        identityref
>
>The authors are interested in what kind of types are in for defect-type.
>In general, like section 4.4 (rpc), it is expected that the
>detailed/clarified section for notification is added.

+++DK: Okay we will do the changes in next revision.

>
>
>6. Comments on Introduction (Section 1)
>
>Three comments:
>
>(1) Three bullets should be updated as:
>1.  monitor networks --> 1. monitor connections
>2. isolation --> localization
>3. measure performance --> 3. monitor performance (loss, delay).
>
>(2) "The YANG data model presented in this document occurs at the
>management layer."
>should this be:
>"The YANG data model presented in this document exists at themanagement
>layer."
>
>(3) The sentence in the last paragraph "This ability to go up and down to
>different layers" is not a good description for "nesting".

+++DK: Ok.

>
>
>7. Comment on Terminology (Section 2.1)
>
>Since the model is based on IEEE802.1Q, the expansion for MEP and MIP
>should follow IEEE802.1Q.

+++DK: Ok.
>
>
>8. Comments on Overview of the OAM Model (Section 4)
>
>Three comments:
>
>(1) What is a "parallel vertical"?
>(2) What is "rpc"? (expansion is missing) And note that both rpc and RPC
>is used throughout the draft.
>(3) The sentence "Under each MA, there can be two or more MEPs "implies
>that the two MEPs are the source and sink of a connection, Does this mean
>that for a 
>bi-directional (transport) connection there are two MAs?

+++DK: Okay.
>
>
>9. Comment on OAM data hierarchy (Section 4.5)
>
>It is suggested to move the first part (from:  The following notations"
>until "leafs and leaf-lists ") to the front of section 4, because the
>notation is also 
>used in sections 4.1... 4.4.

+++DK: Ok.

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 2 Jul 2015 09:04:45 +0000

Huub:
Thanks for your valuable comments.

发件人: Lime [mailto:[email-masked]] 代表 Huub van Helvoort
发送时间: 2015年6月27日 16:24
收件人: [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

All,

Some additional remarks on draft-tissa-lime-yang-oam-model-05

In the introduction section:
1.  monitor networks --> 1. monitor connections
this because actually the connections in the network are monitored.

[Qin]:My understanding is besides monitoring connections, we also need to keep track of connectionless network to provide consistent reporting, representation when
We deal with both connection oriented network and connectionless network for the end to end path.

2. isolation --> localisation
it is not always possible to isolate a fault, but if one can locate it
one can take proper consequent actions (like isolation)

[Qin]: Yes, that is true when we don’t respect layer boundary for different OAM technologies.
Your proposed changes sounds good to me.

3. measure performance --> 3. monitor performance (loss, delay).
monitor implies that consequent actions may/will be taken/

[Qin]: Good point and agree.

Proper expansion of MEP (from 802.1):

3.93 Maintenance association End Point (MEP)
Proper expansion of MIP (from 802.1Q):

3.98 Maintenance domain Intermediate Point (MIP)

[Qin]:Correct, IEEE802.1 Q uses these expansion for MEP and MIP, but RFC7174 uses other simplified expansion.

I think we should choose either one to make consistent.
Best regards, Huub.

BTW: the latter two remarks are also applicable to
draft-tissa-nvo3-oam-fm-02

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 02 Jul 2015 17:16:07 +0200

Hello Qin,

Please see my response in-line [Huub]

you wrote:

Huub:

发件人:
Lime [mailto:[email-masked]]
代
表 Huub
van Helvoort

发
送时间:
2015年6月27日 16:24

收件人: [email-masked]

主题: Re: [Lime] Comments on
draft-tissa-lime-yang-oam-model-05

All,

Some additional remarks on
draft-tissa-lime-yang-oam-model-05

this because actually the connections in the network are
monitored.

[Qin]:My understanding is besides monitoring
connections, we also need to keep track of connectionless
network to provide consistent reporting, representation
when

We deal with both connection oriented network
and connectionless network for the end to end path.

[Huub] IMHO it will be extremely difficult to monitor a whole
network

using OAM.

AFAIK there does not exist OAM for connectionless technologies.

The only thing that can be done in a connectionless network is

monitor the links/sections between the network nodes.

However, that you are monitoring connections again, not the network.

Best regards, Huub.

--
*****************************************************************
请记住，你是独一无二的，就像其他每一个人一样

---

From: Tom Taylor <[email-masked]>
Date: Thu, 2 Jul 2015 14:53:51 -0400

Below with [PTT].

Tom Taylor

On 02/07/2015 11:16 AM, Huub van Helvoort wrote:
>> IEEE Std 802.1Q™-2011, IEEE Standard for Local and metropolitan area
>> networks—Media Access Control (MAC) Bridges and Virtual Bridged Local
>> Area Networks
>>
>> Huub:
>>
>> *发件人:*Lime [mailto:[email-masked]] *代 表 *Huub van Helvoort
>> *发 送时间:*2015年6月27日16:24
>> *收件人:[email-masked]
>> *主题:*Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05
>>
>> All,
>>
>> [Qin]:My understanding is besides monitoring connections, we also need
>> to keep track of connectionless network to provide consistent
>> reporting, representation when
>>
> [Huub] IMHO it will be extremely difficult to monitor a whole network
> using OAM.
...
[PTT] This is a matter of words, not substance, I think. Huub, you 
accept, I'm sure, that traceroute and ping test end-to-end reachability. 
Performance monitoring tools do the same in a connectionless network as 
well as a connected one.

[PTT] So what we have is reachability monitoring rather than 
connectivity monitoring, since there is no connection in a 
connectionless network.

---

From: Qin Wu <[email-masked]>
Date: Fri, 3 Jul 2015 04:34:40 +0000

Hi, Huub:
发件人: Huub van Helvoort [mailto:[email-masked]]
发送时间: 2015年7月2日 23:16
收件人: Qin Wu; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hello Qin,

you wrote:
Huub:

发件人: Lime [mailto:[email-masked]] 代 表 Huub van Helvoort
发 送时间: 2015年6月27日 16:24
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

All,

[Qin]: suppose end to end path spans across multiple layer with each layer corresponding to each segment of the whole network
by respecting OAM layer boundary, we can gather OAM information including fault, performance info, trouble shooting result from each layer,
Stitching together in the management plane layer and form end to end view of OAM visibility for the whole network. Since each layer OAM is using
Similar template for consistent reporting the OAM data, stitching them to form end to end view will be more easy.

[Qin]: I believe we are probably talking about the same thing but use the different terminologies.:-)
Let’s see how to fix this.

Best regards, Huub.

--

              请记住，你是独一无二的，就像其他每一个人一样

---

From: Tom Taylor <[email-masked]>
Date: Fri, 3 Jul 2015 04:07:49 -0400

This thread is bringing out some good issues. The first is a language 
issue, the second an architectural one.

Regarding language: I'm wondering if we could take a pragmatic 
functional approach to our use of terminology. The general principle 
would be to define the functions invoked by CC, CV, etc. without 
actually spelling those acronyms out. Then create a table mapping the 
functions to technology-specific functions. The table would be part of 
the applicability document.

The architectural issue is how to invoke the functions for each 
technology-specific segment making up a complete path. One way is for 
the management system to do a separate invocation at each MEP along the 
path. The other way, possibly a violation of principle but possibly not, 
is for each MEP to relay the abstract (LIME) request to its successor 
along the path, protocol TBD.

Comments?

Tom Taylor

---

From: Qin Wu <[email-masked]>
Date: Fri, 3 Jul 2015 08:28:25 +0000

-----邮件原件-----
发件人: Tom Taylor [mailto:[email-masked]] 
发送时间: 2015年7月3日 16:08
收件人: Qin Wu; [email-masked]; [email-masked]
主题: Language and architectural issues (was Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05)

This thread is bringing out some good issues. The first is a language issue, the second an architectural one.

Regarding language: I'm wondering if we could take a pragmatic functional approach to our use of terminology. The general principle would be to define the functions invoked by CC, CV, etc. without actually spelling those acronyms out. 

[Qin]: I get a little bit confused when you are saying define the function invoked by CC,CV.
CC,CV are also functions or command invoked by management system, the management system issues the OAM command to the device in the data plane, the device is responsible for executing the command.

Then create a table mapping the functions to technology-specific functions. The table would be part of the applicability document.

[Qin]: That sounds good idea but it depends what are these functions? Are these functions like the table 4 of RFC7276?

The architectural issue is how to invoke the functions for each technology-specific segment making up a complete path. One way is for the management system to do a separate invocation at each MEP along the path. The other way, possibly a violation of principle but possibly not, is for each MEP to relay the abstract (LIME) request to its successor along the path, protocol TBD.

[Qin]: The second approach is related to cross layer data plane OAM, not sure this is in the scope of LIME since LIME is not aimed at developing any new OAM protocols.
Unless this cross layer OAM protocol has already been standardized, I am not sure LIME model can take advantage of it.

Comments?

Tom Taylor

On 03/07/2015 12:34 AM, Qin Wu wrote:
> 1.  monitor networks --> 1. monitor connections this because actually 
> the connections in the network are monitored.
>
>
> to keep track of connectionless network to provide consistent reporting, representation when We deal with both connection oriented network and connectionless network for the end to end path.
> [Qin]: suppose end to end path spans across multiple layer with each 
> layer corresponding to each segment of the whole network by respecting 
> OAM layer boundary, we can gather OAM information including fault, 
> performance info, trouble shooting result from each layer, Stitching together in the management plane layer and form end to end view of OAM visibility for the whole network. Since each layer OAM is using Similar template for consistent reporting the OAM data, stitching them to form end to end view will be more easy.
>
> The only thing that can be done in a connectionless network is monitor 
> the links/sections between the network nodes.
> [Qin]: I believe we are probably talking about the same thing but use 
> the different terminologies.:-) Let’s see how to fix this.
>
> Best regards, Huub.
>
>
>
>
> --
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 3 Jul 2015 04:53:12 -0400

Below, with [PTT]

On 03/07/2015 4:28 AM, Qin Wu wrote:
> -----邮件原件----- 发件人: Tom Taylor [mailto:[email-masked]] 发送时
> 间: 2015年7月3日 16:08 收件人: Qin Wu; [email-masked]; [email-masked] 主
> 题: Language and architectural issues (was Re: [Lime] Comments on
> draft-tissa-lime-yang-oam-model-05)
>
> actually spelling those acronyms out.
>
> [Qin]: I get a little bit confused when you are saying define the
> function invoked by CC,CV. CC,CV are also functions or command
> invoked by management system, the management system issues the OAM
> command to the device in the data plane, the device is responsible
> for executing the command.

[PTT] I'm saying that the functions that are invoked by each of these 
need to be spelled out. For instance, as I said in a previous note, I 
would define CC as reachability verification. CV might be defined as 
hop-by-hop path characterization. PM can be defined as end-to-end path 
characterization (for delay, loss, jitter).
>
> Then create a table mapping the functions to technology-specific
> functions. The table would be part of the applicability document.
>
> [Qin]: That sounds good idea but it depends what are these functions?
> Are these functions like the table 4 of RFC7276?

[PTT] Yes, more or less.
> the management system to do a separate invocation at each MEP along
> the path. The other way, possibly a violation of principle but
> possibly not, is for each MEP to relay the abstract (LIME) request to
> its successor along the path, protocol TBD.
>
> [Qin]: The second approach is related to cross layer data plane OAM,
> not sure this is in the scope of LIME since LIME is not aimed at
> developing any new OAM protocols. Unless this cross layer OAM
> protocol has already been standardized, I am not sure LIME model can
> take advantage of it.

[PTT] This isn't so much cross layer as cross technology, as I see it. 
In any event, we have the discovery problem. For every pair of 
endpoints, either the management system has to discover all of the MEPs 
along the way (which takes some sort of protocol) or we can use the 
second approach. In any event, the management system has to find the 
first MEP in a given path. I don't see how we can escape the need for 
protocol development. The organizational issue is another matter.
> Tom Taylor
....

---

From: Qin Wu <[email-masked]>
Date: Fri, 3 Jul 2015 10:31:50 +0000

> developing any new OAM protocols. Unless this cross layer OAM protocol 
> has already been standardized, I am not sure LIME model can take 
> advantage of it.

[PTT] This isn't so much cross layer as cross technology, as I see it. 
In any event, we have the discovery problem. For every pair of endpoints, either the management system has to discover all of the MEPs along the way (which takes some sort of protocol) or we can use the second approach. In any event, the management system has to find the first MEP in a given path. I don't see how we can escape the need for protocol development. The organizational issue is another matter.

[Qin]: I assume the management system has already discovered all of the MEPs, the management system can rely on BGP-LS to get network topo or rely on network topo defined in I2RS to discover all of the MEPs, the second approach seems like in-band discovery approach which definitely need protocol development.
....

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 06 Jul 2015 11:22:42 +0200

Hello Tom,

Thank you for your response.

See my answers below [Huub2]
> accept, I'm sure, that traceroute and ping test end-to-end 
> reachability. Performance monitoring tools do the same in a 
> connectionless network as well as a connected one.
[Huub2] Ping and traceroute are diagnostic tools used for fault 
localisation and used
on-demand. Monitoring, especially for availability is pro-active.
> connectivity monitoring, since there is no connection in a 
[Huub2] OK, I agree that "reachability monitoring" is a better term

Cheers, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 06 Jul 2015 11:37:07 +0200

Hello Qin,

Thanks for your response,

See my response below {Huub2]

Hi, Huub:

发件人:
Huub van Helvoort [mailto:[email-masked]]

发
送时间:
2015年7月2日 23:16

Hello Qin,

you wrote:

Huub:

发件人:
代 表 Huub
van Helvoort

发 送时间:
2015年6月27日 16:24

收件人:
[email-masked]

All,

[Qin]:My understanding is besides
monitoring connections, we also need to keep track of
connectionless network to provide consistent reporting,
representation when

We deal with both connection oriented
network and connectionless network for the end to end
path.

[Huub] IMHO it will be
extremely difficult to monitor a whole network

using OAM.

[Qin]: suppose end to end path spans across
multiple layer with each layer corresponding to each segment
of the whole network

by respecting OAM layer boundary, we can gather
OAM information including fault, performance info, trouble
shooting result from each layer,

Stitching together in the management plane
layer and form end to end view of OAM visibility for the
whole network. Since each layer OAM is using

Similar template for consistent reporting the
OAM data, stitching them to form end to end view will be
more easy.

[Huub2] even if an end-to-end connection traverses multiple layers,
the OAM of

the layer in which the e-2-e connection is made will provide all
connectivity and

PM required. No stiching is required.

One only has to go down to the lower layers for fault localisation
and diagnostics.

AFAIK there does not
exist OAM for connectionless technologies.

The only thing that can be done in a connectionless network
is

However, that you are monitoring connections again, not the
network.

[Qin]: I believe we are probably talking about
the same thing but use the different terminologies.:-)

[Huub2] please see my response to Tom Taylor.

Best regards, Huub.

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 7 Jul 2015 04:39:18 +0000

Hi Deepak, et. al,
apologies for being late to the discussion and thus I may be repeating arguments. There's one important point I'd like to make:
	LIME charter is to create OAM data model, not to create OAM. IP and IP/MPLS OAM has its toolset and its model which are substantially different from those of Ethernet and/or MPLS-TP. And that was one the main statements reached and agreed upon by the DT and presented to the WG.

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Deepak Kumar (dekumar)
Sent: Wednesday, July 01, 2015 7:13 PM
To: Yuji Tochio; [email-masked]
Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Yuji,

Inline +++DK:

On 6/23/15, 11:54 PM, "Yuji Tochio" <[email-masked]> wrote:

>Hi all,
>
>The authors of draft-tissa-lime-yang-oam-model asked for comments to 
>the authors of draft-lam-lime-summary-l0-l2-layer-independent.
>So far, I, as a co-author of draft-lam..., have collected comments 
>among us and here are attached the comments as below.
>
>OAM architecture for them, but the common OAM architecture in this 
>draft adapts those for Ethernet (IEEE802.1Q and ITU-T G.8013/Y.1731) or 
>MPLS-TP (RFC 6371).
>Given that this draft covers only Ethernet and MPLS-TP OAM, it would 
>not have any issues. But how about other technologies like IP or (IP/)MPLS?
>Do they use the

+++DK: 

We discussed in the LIME Design team meeting, Testing point, fault domain, technology type, addressing, etc are common elements. MEP is implicit in IP.
In various architectures for different OAM technologies. In addition,
RFC7276 also gives a summary of common OAM functions used in OAM-related standards.
Here what we are doing is to adopt OAM concepts defined for Ethernet or MPLS-TP architecture and represent these common elements using some kind of technology independent template.
CFM model is a good basis to define such template, we extend it to a technology independent framework.
That is to say, different OAM technologies share the same OAM concept and can therefore be consolidated into technology independent framework.
"

>parameters in the draft come basically from those for configuring MEPs 
>of Ethernet (and some for IPv4 and IPv6).

+++DK:

>Also co-located sink MEP in case of a bi-directional connection should 
>be considered.

>Loss measurement)related configuration data, But it looks as a part of 
>CC and CV functionalities.
>As seen in ITU-T G.8013 (DM, LM, and Synthetic LM) and PM for Trill 
>OAM, the output (PM related configuration data) should be regarded in 
>more generic way.

>1.  monitor networks --> 1. monitor connections 2. isolation --> 
>localization 3. measure performance --> 3. monitor performance (loss, 
>delay).
>
>(3) The sentence in the last paragraph "This ability to go up and down 
>to different layers" is not a good description for "nesting".

+++DK: Ok.

+++DK: Ok.
>(2) What is "rpc"? (expansion is missing) And note that both rpc and 
>RPC is used throughout the draft.
>that the two MEPs are the source and sink of a connection, Does this 
>mean that for a bi-directional (transport) connection there are two 
>MAs?

+++DK: Okay.
>notation is also used in sections 4.1... 4.4.

+++DK: Ok.

Thanks,
Deepak

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 7 Jul 2015 04:52:31 +0000

Hi Huub,
I agree, on most part, with your observation that when we instantiate OAM in connectionless network we implicitly define a connection. I think that in connectionless network we’re monitoring not a connection but a route, continuity between two end-points, rather than connectivity of them as there’s no notion of MEG in connectionless networks. And MEG is the basic, key element of CO network OAM itself and its data model.

                Regards,
                                Greg

From: Lime [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Thursday, July 02, 2015 8:16 AM
To: Qin Wu; [email-masked]
Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hello Qin,

you wrote:
Huub:

All,

Best regards, Huub.

--

              请记住，你是独一无二的，就像其他每一个人一样

---

From: Qin Wu <[email-masked]>
Date: Tue, 7 Jul 2015 06:31:32 +0000

Hi, Huub:
发送时间: 2015年7月6日 17:37

Hello Qin,

发 送时间: 2015年7月2日 23:16
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>

Hello Qin,

you wrote:
Huub:

All,

[Qin]: suppose end to end path spans across multiple layer with each layer corresponding to each segment of the whole network
by respecting OAM layer boundary, we can gather OAM information including fault, performance info, trouble shooting result from each layer,
Stitching together in the management plane layer and form end to end view of OAM visibility for the whole network. Since each layer OAM is using
Similar template for consistent reporting the OAM data, stitching them to form end to end view will be more easy.
[Huub2] even if an end-to-end connection traverses multiple layers, the OAM of
the layer in which the e-2-e connection is made will provide all connectivity and
PM required. No stiching is required.

[Qin]: Yes, if we following the same template and organize OAM results under MD, MA, MEP in the OAM configuration data structure, stitching is not required.

One only has to go down to the lower layers for fault localisation and diagnostics.

[Qin]: Yes, high layers only provide coarse granularity of fault localization and diagnostics.
In some times, you might not find any fault in the high layer.

[Qin]: I see your point, I will also call this connection as something like pipe.
monitoring connections are common to all the OAM technologies.
The links/sections need to be part of connection. Nodes in the network that are not in the connections don’t need to be monitored.

---

From: Qin Wu <[email-masked]>
Date: Tue, 7 Jul 2015 06:59:03 +0000

Your statement here is a little bit misleading and vague, I think what DT agreed are
1. Technology independent OAM model doesn't change OAM protocol used in the data plane, therefore the LIME model is used to model all the configuration data used for OAM protocol and state data generated by OAM protocol in the data plane. The LIME model will work together with OAM toolset and OAM protocol in each layer and provided automated trouble shooting by relying on RPC and Notifications.

2. Commonality between IP and IP/MPLS OAM and Ethernet and/or MPLS-TP were discussed, Testing point, fault domain, technology type, addressing, , etc are common elements which are applied to all the OAM technologies. As deepak mentioned, For IP OAM, MEP doesn't need to explicit configured. This is difference, but not sure this is fundamental difference, as you stated, between IP OAM and other OAM technologies.
Each layer has its own toolset, they doesn't need to be same, but look for common framework really help provide consistent management, automated control and management. 
RFC7276, section 3 lays a good foundation for this work.

-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年7月7日 12:39
收件人: Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Deepak, et. al,

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Deepak Kumar (dekumar)
Sent: Wednesday, July 01, 2015 7:13 PM
To: Yuji Tochio; [email-masked]
Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Yuji,

Inline +++DK:

+++DK: 

+++DK:

+++DK: Ok.

+++DK: Ok.

+++DK: Okay.

+++DK: Ok.

Thanks,
Deepak

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 7 Jul 2015 07:20:17 +0000

Hi Qin,
in addition to implicit MEP, IP and IP/MPLS OAM based on implicit MIP, MEG and no MEG level, unlike Ethernet and/or MPLS-TP OAM. As result, failure, for example, failure of a link along the path between nodes A and B may be not detected in ip or IP/MPLS environment with ECMP but be detected in connection-oriented, e.g. MPLS-TP LSP or PW, when it uses the link.
RFC 7276 has many inaccuracies at least in regard to use of connectivity and continuity terms., especially when discussing proactive OAM.

	Regards,
		Greg

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 11:59 PM
To: Gregory Mirsky; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
Subject: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Your statement here is a little bit misleading and vague, I think what DT agreed are 1. Technology independent OAM model doesn't change OAM protocol used in the data plane, therefore the LIME model is used to model all the configuration data used for OAM protocol and state data generated by OAM protocol in the data plane. The LIME model will work together with OAM toolset and OAM protocol in each layer and provided automated trouble shooting by relying on RPC and Notifications.

-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年7月7日 12:39
收件人: Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Deepak, et. al,

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Deepak Kumar (dekumar)
Sent: Wednesday, July 01, 2015 7:13 PM
To: Yuji Tochio; [email-masked]
Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Yuji,

Inline +++DK:

+++DK: 

+++DK:

+++DK: Ok.

+++DK: Ok.

+++DK: Okay.

+++DK: Ok.

Thanks,
Deepak

---

From: Qin Wu <[email-masked]>
Date: Tue, 7 Jul 2015 07:37:18 +0000

You are talking about ECMP which is a corner case.
I am not saying ECMP is something that is common to all the OAM technologies.
MPLS-TP does not use ECMP, and thus does not require OAM over multiple paths.

I am not saying we are sticking to MIP,MEP, MEG Level, instead, we adopt model structure concept defined for Ethernet/MPLS-TP network,
make it adapt to various different OAM technologies and extend it to a technology independent framework. 

-Qin
-----邮件原件-----
发件人: Gregory Mirsky [mailto:[email-masked]] 
发送时间: 2015年7月7日 15:20
收件人: Qin Wu; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Qin,

	Regards,
		Greg

-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: Monday, July 06, 2015 11:59 PM
To: Gregory Mirsky; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
Subject: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年7月7日 12:39
收件人: Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Deepak, et. al,

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Deepak Kumar (dekumar)
Sent: Wednesday, July 01, 2015 7:13 PM
To: Yuji Tochio; [email-masked]
Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Yuji,

Inline +++DK:

+++DK: 

+++DK:

+++DK: Ok.

+++DK: Ok.

+++DK: Okay.

+++DK: Ok.

Thanks,
Deepak

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 07 Jul 2015 15:45:21 +0200

Hello Qin,

(snipped to the appropriate part)

And my response [Huub3]

AFAIK there does not

[Qin]: I see your point, I will also call this
connection as something like pipe.

monitoring connections are common to all the
OAM technologies.

The links/sections need to be part of
connection. Nodes in the network that are not in the
connections don’t need to be monitored.

[Huub3] sorry, but I have to disagree: in a connectionLESS network

there are no connections nor pipes (in the connectionless layer).

Every packet has to find its own way through the network from source

to destination. This means it can pass any link/section in the
network.

And following your reasoning every node in the network has to be

monitored.

As Tom Taylor explained only the reachability can be verified in

connectionless networks.

Best regards, Huub.

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 7 Jul 2015 15:21:03 +0000

Hi Qin,
in IP and IP/MPLS networks ECMP is the case, the usual, the normal case. Yes, it is not simple, it is challenging and ever changing. And because of the latter operator has to periodically re-map OAM sessions to available ECMP paths if monitoring of every ECMP path is required.

	Regards,
		Greg

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: Tuesday, July 07, 2015 12:37 AM
To: Gregory Mirsky; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
Subject: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

I am not saying we are sticking to MIP,MEP, MEG Level, instead, we adopt model structure concept defined for Ethernet/MPLS-TP network, make it adapt to various different OAM technologies and extend it to a technology independent framework. 

-Qin
-----邮件原件-----
发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2015年7月7日 15:20
收件人: Qin Wu; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Qin,

	Regards,
		Greg

-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: Monday, July 06, 2015 11:59 PM
To: Gregory Mirsky; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
Subject: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年7月7日 12:39
收件人: Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Deepak, et. al,

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Deepak Kumar (dekumar)
Sent: Wednesday, July 01, 2015 7:13 PM
To: Yuji Tochio; [email-masked]
Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Yuji,

Inline +++DK:

+++DK: 

+++DK:

+++DK: Ok.

+++DK: Ok.

+++DK: Okay.

+++DK: Ok.

Thanks,
Deepak

---

From: Tom Taylor <[email-masked]>
Date: Tue, 7 Jul 2015 19:29:24 -0400

I think I see the point: the MEG for an IP route would have to include 
all the routers that could potentially participate in that route. We 
should probably restrict our attention to the end points (MEPs), since 
that is where we would direct our operational requests.

Again: the basic functions seem to be reachability checking/verification 
(I still don't understand the difference between the two), hop-by-hop 
path characterization, and end-to-end path characterization (PM). The 
tools to achieve these functions vary with the transport technology.

By "layer at a given point" I understand a transport-technology-specific 
segment supporting an end-to-end network path. The segments are bounded 
by MEPs. As we all know, there can be link layers on top of other link 
layers, link layers on top of network layers, network layers on top of 
link layers, and network layers on top of other network layers. At 
different points along the network path the stack (i.e., set of 
supporting layers) can vary. Hence localization is critical so that the 
proper set of segments is probed as follow-up. Is this architectural 
view shared by everyone?

Tom Taylor

On 07/07/2015 12:52 AM, Gregory Mirsky wrote:
> Hi Huub,
>
> I agree, on most part, with your observation that when we instantiate
> OAM in connectionless network we implicitly define a connection. I think
> that in connectionless network we’re monitoring not a connection but a
> route, continuity between two end-points, rather than connectivity of
> them as there’s no notion of MEG in connectionless networks. And MEG is
> the basic, key element of CO network OAM itself and its data model.
>
>                  Regards,
>
>                                  Greg
>
> *From:*Lime [mailto:[email-masked]] *On Behalf Of *Huub van Helvoort
> *Sent:* Thursday, July 02, 2015 8:16 AM
> *To:* Qin Wu; [email-masked]
> *Subject:* Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05
>
> Hello Qin,
>
>     *发 送时间:* 2015年6月27日 16:24
>     *收件人:* [email-masked] <mailto:[email-masked]>
>     *主题:* Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05
>
>     All,
>
>     [Qin]:My understanding is besides monitoring connections, we also
>     need to keep track of connectionless network to provide consistent

---

From: Qin Wu <[email-masked]>
Date: Wed, 8 Jul 2015 01:48:48 +0000

Hi, Huub:
发送时间: 2015年7月7日 21:45

Hello Qin,

And my response [Huub3]

to destination. This means it can pass any link/section in the network.

[Qin]: I am not suggesting to monitor every node in the network and I am just follow your comment on replace “monitoring network” with “monitor connection”.
I think we can choose to just monitor source node and sink node for reachability verification. If there are multiple IP nodes(Let’s say 2 IP nodes, Node A, Node B)
between source node and sink node, we can monitor three sections as you said:

1.       Section A: source node-> IP Node A

2.       Section B: IP node A->  IP Node B

3.       Section C: IP node B-> Sink Node
for reachablity verification.

[Qin]: That’s correct, that’s why we use YANG feature statement to set connectivity verification rpc as optional rpc.
Since connectivity verification rpc can not be supported in connectionless networks.

Best regards, Huub.

--

              请记住，你是独一无二的，就像其他每一个人一样

---

From: Qin Wu <[email-masked]>
Date: Wed, 8 Jul 2015 02:14:19 +0000

I am not saying ECMP is not important when I said ECMP is a corner case.
Discovery and Exercise ECMP as a challenge issue has already been underlined in the RFC7276.
But Attempting for any OAM tools(e.g., IP OAM) to support ECMP discovery and traversal over all
flavors of load balancing technique will require more complex procedures and implementations to support those
complex procedures. We should respect all these limitation.

In current LIME base model, ECMP-choice is just optional parameter that can be used, if you believe this parameter should
Not be defined in LIME base model, fine, we can remove it. It can be defined in the model extension.

-Qin
-----邮件原件-----
发件人: Gregory Mirsky [mailto:[email-masked]] 
发送时间: 2015年7月7日 23:21
收件人: Qin Wu; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Qin,

	Regards,
		Greg

-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, July 07, 2015 12:37 AM
To: Gregory Mirsky; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
Subject: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

-Qin
-----邮件原件-----
发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2015年7月7日 15:20
收件人: Qin Wu; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Qin,

	Regards,
		Greg

-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: Monday, July 06, 2015 11:59 PM
To: Gregory Mirsky; Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
Subject: RE: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年7月7日 12:39
收件人: Deepak Kumar (dekumar); Yuji Tochio; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Deepak, et. al,

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Deepak Kumar (dekumar)
Sent: Wednesday, July 01, 2015 7:13 PM
To: Yuji Tochio; [email-masked]
Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi Yuji,

Inline +++DK:

+++DK: 

+++DK:

+++DK: Ok.

+++DK: Ok.

+++DK: Okay.

+++DK: Ok.

Thanks,
Deepak

---

From: Qin Wu <[email-masked]>
Date: Mon, 13 Jul 2015 03:40:24 +0000

-----邮件原件-----
发件人: Tom Taylor [mailto:[email-masked]] 
发送时间: 2015年7月8日 7:29
收件人: Gregory Mirsky; [email-masked]; Qin Wu; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

I think I see the point: the MEG for an IP route would have to include all the routers that could potentially participate in that route. We should probably restrict our attention to the end points (MEPs), since that is where we would direct our operational requests.

[Qin]:Yes, that concurs what I replied to Huub.

Again: the basic functions seem to be reachability checking/verification (I still don't understand the difference between the two), hop-by-hop path characterization, and end-to-end path characterization (PM). The tools to achieve these functions vary with the transport technology.

[Qin]: I think the basic functions should also include path verification. Path verification decides which path should be traversed when network node A talk to B.

By "layer at a given point" I understand a transport-technology-specific segment supporting an end-to-end network path. The segments are bounded by MEPs. 

[Qin]: Yes.

As we all know, there can be link layers on top of other link layers, link layers on top of network layers, network layers on top of link layers, and network layers on top of other network layers. At different points along the network path the stack (i.e., set of supporting layers) can vary. Hence localization is critical so that the proper set of segments is probed as follow-up. Is this architectural view shared by everyone?

[Qin]: close to what I thought, usually we localize fault, defect at even lower layer.

Tom Taylor

On 07/07/2015 12:52 AM, Gregory Mirsky wrote:
> OAM in connectionless network we implicitly define a connection. I 
> think that in connectionless network we’re monitoring not a connection 
> but a route, continuity between two end-points, rather than 
> connectivity of them as there’s no notion of MEG in connectionless 
> networks. And MEG is the basic, key element of CO network OAM itself and its data model.
>
>                  Regards,
>
>                                  Greg
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 13 Jul 2015 11:49:57 +0200

Hello Qin,

Please see in-line [Huub]

Regards, Huub.

> [Qin]: I think the basic functions should also include path verification. Path verification decides which path should be traversed when network node A talk to B.
[Huub] which path shall be verified? In connectionless there is not "the 
path" or do
you mean to verify all potential paths that participate in the transport?

---

From: Qin Wu <[email-masked]>
Date: Mon, 13 Jul 2015 10:05:05 +0000

-----邮件原件-----
发件人: Huub van Helvoort [mailto:[email-masked]] 
发送时间: 2015年7月13日 17:50
收件人: Qin Wu; Tom Taylor; Gregory Mirsky; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hello Qin,

Regards, Huub.

> [Qin]: I think the basic functions should also include path verification. Path verification decides which path should be traversed when network node A talk to B.
[Huub] which path shall be verified? In connectionless there is not "the path" or do you mean to verify all potential paths that participate in the transport?

[Qin]: I am not saying path need to be verified in the connectionless network. path verification is optional feature in the base model. 
As we discussed earlier, you only need to do reachability checking/verification in the connectionless network, you don't need to exercise all potential paths which add a lot of complexity,
We should respect limitation of the existing OAM tool for connectionless network.

---

From: Tom Taylor <[email-masked]>
Date: Mon, 13 Jul 2015 08:13:54 -0400

In line with [PTT].

...

> We should respect limitation of the existing OAM tool for connectionless network.

[PTT]The existing tools can do hop-by-hop path characterization just 
fine, connection-oriented or connectionless. No tool can do verification 
-- that has to happen at the management system, which can compare the 
results of path characterization with expected results. As an example, 
the management system can identify a tracert hop with unexpectedly high 
delay.

...

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 13 Jul 2015 15:27:47 +0200

Hello Qin,

Thank you for the clarification.
I think we are on the same track now.

BR, Huub.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 14 Jul 2015 15:41:28 +0200

Hi,
> (2) "The YANG data model presented in this document occurs at the 
I don't even understand what this sentence means.
What is the management layer?

Regards, Benoit
> should this be:
> "The YANG data model presented in this document exists at 
> themanagement layer."

---

From: Qin Wu <[email-masked]>
Date: Tue, 14 Jul 2015 14:13:58 +0000

-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2015年7月14日 21:41
收件人: Yuji Tochio; [email-masked]
主题: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Hi,

[Qin]: I think the management layer is referred to management system, could be OSS/NMS,
The YANG data model is used between the management system and
Managed network element, both the management system and the managed network element need to understand
The model and support the model, the model has to be code implemented in the managed network element.
You are right, this sentence is confusing, it looks this sentence is about who generate or produce the data model, if my understanding is correct.

Regards, Benoit