Subject: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 Oct 2015 10:23:02 -0400

As usual, I've been behind.  I spent most of the last day reading through my
backlog of email to the list and several of the published Internet-Drafts
for the working group.  Thanks also to Greg and Mahesh that tried to engage
me, but caught me during that busy time.

As I mentioned at the microphone at IETF-92 (I think), I have *strong*
concerns about trying to wedge in CFM semantics into IETF IP and MPLS OAM.
Having caught up on the current documents, that concern has not been
allayed.

Things I like about the current document is a move toward a uniform set of
tests.  These are covered in the RPCs.  However, as I try to reconcile the
CFM semantics which are appropriate to some media with what is possible to
retrieve using the proposed IP/MPLS mechanisms, I think there's an outright
mismatch on the things being reported.

LIME is not chartered to invent new mechanisms, only to provide modeling
layers toward those.  This means that either the mechanisms need a far more
specific output, or work needs to be taken to other groups to add in the
missing statistics.

The ability to probe up and down the layers is a good property of LIME, in
my opinion.

Where things get very ugly very fast is trying to uniformly apply CFM
semantics to general IP or MPLS networks.  For example, the idea of a given
IP network being part of a maintenance domain is appealing from a CFM
modeling standpoint.  However, the existing level model will break apart
very quickly once you start trying to model complex service providers.

Some providers have a very simple "core" services layer and several "client"
networks attached to that core.  That would fit.  However, when the roles
overlap, especially in VPN scenarios, CFM semantics' need to avoid overlap
becomes problematic.

This gets even more complicated when the model tries to expand beyond a
single service provider into inter-domain scenarios.

I encourage those participants who are working within organizations like
IEEE to produce a yang model of existing CFM.  I think that will be a useful
technology to complement IETF technologies.

I also encourage the working group to go back to the white board and work
from known IP and MPLS use cases back toward the underlying layers instead
of the other way around.  While I certainly agree that IEEE/ITU OAM is very
mature, I don't believe it's a proper fit for our work.  What I suspect is
that if we start by trying to take the RPC models in terms of functionality
and work from the IETF technologies, we'll likely overlap in the RPCs and a
portion of the reporting from them to transitioning to underlying OAMs.

Basically, we're likely to end up with two universes of modeling sharing
common RPCs but leading toward differing models for representing a given
layer.  However, that's an opinion that's not supported from trying to do
this work; I just strongly believe that trying to force IP networks into CFM
semantics will lead to a bunch of angry IP service providers who want to
know why they're being forced to provision CFM parameters in order to run
the unified traceroute/ping/etc.

-- Jeff

---

From: <[email-masked]>
Date: Fri, 2 Oct 2015 12:55:28 +0200

Hi Jeff,

what is then your proposal for Lime:

Not focussing on CFM semantics?
Is your concern related to different definitions in IETF resp. IEEE etc. or general?

Could you give an example of the reporting missmatch you are concerned, please.

Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Lime [mailto:[email-masked]] Im Auftrag von Jeffrey Haas
Gesendet: Donnerstag, 1. Oktober 2015 16:23
An: [email-masked]
Betreff: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

As usual, I've been behind.  I spent most of the last day reading through my backlog of email to the list and several of the published Internet-Drafts for the working group.  Thanks also to Greg and Mahesh that tried to engage me, but caught me during that busy time.

As I mentioned at the microphone at IETF-92 (I think), I have *strong* concerns about trying to wedge in CFM semantics into IETF IP and MPLS OAM.
Having caught up on the current documents, that concern has not been allayed.

Things I like about the current document is a move toward a uniform set of tests.  These are covered in the RPCs.  However, as I try to reconcile the CFM semantics which are appropriate to some media with what is possible to retrieve using the proposed IP/MPLS mechanisms, I think there's an outright mismatch on the things being reported.

LIME is not chartered to invent new mechanisms, only to provide modeling layers toward those.  This means that either the mechanisms need a far more specific output, or work needs to be taken to other groups to add in the missing statistics.

The ability to probe up and down the layers is a good property of LIME, in my opinion.

Where things get very ugly very fast is trying to uniformly apply CFM semantics to general IP or MPLS networks.  For example, the idea of a given IP network being part of a maintenance domain is appealing from a CFM modeling standpoint.  However, the existing level model will break apart very quickly once you start trying to model complex service providers.

Some providers have a very simple "core" services layer and several "client"
networks attached to that core.  That would fit.  However, when the roles overlap, especially in VPN scenarios, CFM semantics' need to avoid overlap becomes problematic.

This gets even more complicated when the model tries to expand beyond a single service provider into inter-domain scenarios.

I encourage those participants who are working within organizations like IEEE to produce a yang model of existing CFM.  I think that will be a useful technology to complement IETF technologies.

I also encourage the working group to go back to the white board and work from known IP and MPLS use cases back toward the underlying layers instead of the other way around.  While I certainly agree that IEEE/ITU OAM is very mature, I don't believe it's a proper fit for our work.  What I suspect is that if we start by trying to take the RPC models in terms of functionality and work from the IETF technologies, we'll likely overlap in the RPCs and a portion of the reporting from them to transitioning to underlying OAMs.

Basically, we're likely to end up with two universes of modeling sharing common RPCs but leading toward differing models for representing a given layer.  However, that's an opinion that's not supported from trying to do this work; I just strongly believe that trying to force IP networks into CFM semantics will lead to a bunch of angry IP service providers who want to know why they're being forced to provision CFM parameters in order to run the unified traceroute/ping/etc.

-- Jeff

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

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 2 Oct 2015 13:55:55 +0000

Jeff,

If this assertion is true, it is very concerning. Let's put it to the test.

I invite the authors of draft-tissa-lime-yang-oam model to demonstrate how the model can be applied to IP and MPLS in an inter-domain scenario. If this can be done in email, that would be great. If the demonstration requires a higher bandwidth channel, it can be presented in Yokohama.

In either event, this exercise will demonstrate whether the conceptual framework proposed in draft-tissa is sufficient. Depending on the result, the WG will take appropriate action.

                                                            Ron
                                                           /chair hat on

> semantics to general IP or MPLS networks.

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Fri, 2 Oct 2015 15:33:03 +0000

Hi Jeffrey,

I believe applicability document is trying to address the concern.
We can work on adding section for inter-domain mpls/ip.

MD Configuration Extension

MD level configuration parameters are management information which are set
by the LIME base model, as default values, and inherited by the MPLS OAM
model.

MD level configuration parameters provide context information for
management systems to correlate faults with location information

For example domain name can be set to area-ID in the MPLS OAM case.  In
addition, at the Maintenance Domain level, domain data node at root level
can be augmented with technology type and sub-technology type.
MD level configuration parameters MUST not be carried using MPLS OAM
protocol(e.g., LSP Ping) since MPLS OAM protocol doesn't support transport
of these
   management information.

Thanks,
Deepak

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 2 Oct 2015 15:34:36 +0000

Hi Ron,
I believe that the draft-zhuang-lime-yang-oam-model-applicability is the ground where the demonstration supposed to take place. I've reviewed and commented in many details on the -00 version right after the meeting in Prague. At the time of WG adoption call on the draft-tissa-lime-yang-oam-model I've shared my comments with the WG community. As I understand the authors of the applicability draft are updating the document. Perhaps we can have an update on the progress of their efforts and whether new version will be available for discussion in Yokohama. As of now, I'm of opinion that the draft-tissa-lime-yang-oam-model presents OAM model of packet-switching connection-oriented networks like Ethernet transport or MPLS-TP and does not present adequate model of OAM for packet switching connectionless networks like IP or IP/MPLS networks.

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Friday, October 02, 2015 6:56 AM
To: Jeffrey Haas; [email-masked]
Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

Jeff,

                                                            Ron
                                                           /chair hat on

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 2 Oct 2015 15:49:46 +0000

Greg,

This is true. The outcome of this exercise is relevant to both of the following drafts:

- draft-zhuang-lime-yang-oam-model-applicability
- the draft-tissa-lime-yang-oam-model

If we find that the CFM framework is applicable to IP and MPLS, we will have content for the applicability model and we will have validated the CFM assumptions of draft-tissa.

However, if we find that the application of CFM concepts to IP and MPLS is painful, we will have to change the direction of both drafts.

                                                                             Ron

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Friday, October 02, 2015 11:35 AM
> To: Ronald Bonica <[email-masked]>; Jeffrey Haas <[email-masked]>;
> [email-masked]
> Subject: RE: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?
> 
> Hi Ron,
> I believe that the draft-zhuang-lime-yang-oam-model-applicability is the
> ground where the demonstration supposed to take place. I've reviewed and
> commented in many details on the -00 version right after the meeting in
> Prague. At the time of WG adoption call on the draft-tissa-lime-yang-oam-
> model I've shared my comments with the WG community. As I understand
> the authors of the applicability draft are updating the document. Perhaps we
> can have an update on the progress of their efforts and whether new
> version will be available for discussion in Yokohama. As of now, I'm of opinion
> that the draft-tissa-lime-yang-oam-model presents OAM model of packet-
> switching connection-oriented networks like Ethernet transport or MPLS-TP
> and does not present adequate model of OAM for packet switching
> connectionless networks like IP or IP/MPLS networks.
> 
> 	Regards,
> 		Greg
> 
> I invite the authors of draft-tissa-lime-yang-oam model to demonstrate how
> the model can be applied to IP and MPLS in an inter-domain scenario. If this
> can be done in email, that would be great. If the demonstration requires a
> higher bandwidth channel, it can be presented in Yokohama.
> 
> In either event, this exercise will demonstrate whether the conceptual
> framework proposed in draft-tissa is sufficient. Depending on the result, the
> WG will take appropriate action.
> 
>                                                             Ron
>                                                            /chair hat on
> 
> 
> >

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 2 Oct 2015 11:58:55 -0400

Roland,

> Is your concern related to different definitions in IETF resp. IEEE etc. or general?

IETF OAM is very immature by comparison to IEEE/ITU.  I'm fine with using
semantics and perhaps terminology.

Much of my concern is that since this is a data modeling exercise that we
don't try to force IP and MPLS technologies (not MPLS-TP) to fit into the
same configuration model one would do for CFM.

To speak in a somewhat polite fashion, if you told most IP network operators
that they would have to give every IP end-point CFM-style configurations to
make LIME work, I think you'd find they were somewhat hostile to the idea.
:-)

CFM is great for places that it is already used.  With respect to lower
level layers that are implemented on CFM-style systems, we want to use them.
The proposed data model covers this case fairly well as a service model.

The IP/MPLS end of things is not covered, IMO.  If I'm missing something
that the authors believes shows that it is covered, an example showing an
intra-domain traceroute would be helpful.  Inter-domain traceroute is a
good example to show as well.

> Could you give an example of the reporting missmatch you are concerned, please.

In path-discovery, grouping monitor-stats is used.  This includes a min,
average and max delay stat.  This isn't something returned from many
traceroute IP implementations.  Perhaps it should be, but it's a bit
different. 

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 2 Oct 2015 12:03:15 -0400

Deepak,

> We can work on adding section for inter-domain mpls/ip.
[...]
> protocol(e.g., LSP Ping) since MPLS OAM protocol doesn't support transport

I think that trying to force the semantic of MD-Level into IP protocols will
likely be highly problematic for operators.  Consider coordination efforts
that would be required in an inter-domain fashion.

That said, for IP layers, the semantic of "higher level" or "lower level"
are still valid.  IP may be on top of MPLS which might be on top of GRE,
which might be on top of IP which might be, at a given node, on top of TDM.

If we can discover the lower layers in IP, we still can drill-down.  
Once we have drilled down to a layer managed by CFM, the existing model
would work well.

My suggestion would be to work from this sort of use case in the future
modeling work -  and note the caveat about avoiding requiring IP/MPLS
operators to configure CFM attributes at every node!

I look forward to seeing such a model.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Oct 2015 10:15:43 -0400

Qin,

On Sat, Oct 03, 2015 at 12:54:13PM +0800, gmail邮箱 wrote:
> > likely be highly problematic for operators.
> ［Qin］MD level parameters don’t need to be imposed to IP protocol，it is sent from the manage plane and terminated at the test points。Charter clearly said base model MUST NOT change IP protocol.

Please consider that the current published yang model seems to suggest that
such concepts are needed at the IP level.  This is why I'm asking for a
demonstration of how the model is intended to apply to IP and MPLS.

If the intent is to add to the published yang model, that has not been clear
from my reading of the mailing list archives.

> >  Consider coordination efforts
> > ［Qin］LIME charter said the scope is restricted to single administrative domain，do we intend to change to tackle inter—domain case？

That is obviously for the chairs to comment upon.  Given my background in
BGP and how this mechanism is likely to be applicable at some point, I have
to ask the long-term question, even if the short-term proposal is intended
to be more constrained.

> ［Qin］The goal of lime WG，I think， is to identify common model structure for various OAM tech at different layer. Just like http://tools.ietf.org/wg/netmod/draft-ietf-netmod-routing-cfg/ did to provide common struct for various routing tech
> do u aggree with this？or u believe we should find different structure for oam at different layer？

I agree that there should be common layers.  I believe that the RPCs that
are currently specified have some promise to apply between the layers.  I do
not see how the current proposal intends to be generic to IP and MPLS since
it seems to be CFM-model specific.

> if it is the former，do you have better structure than CFM like struct？Modeling oam from protocol perspective is not able to come up with common oam struct. Modeling oam from fault manange and perform management perspective，u probobaly get similar struct like cfm struct.
> if u have better struct，we are happy to hear！

I don't currently have a better proposal - only strong concerns about the
impact of trying to impose CFM like mechanisms on IP and MPLS.  I'm also
doing this because I think the lime work is useful and would rather see it
succeed.

> ［Qin］every node？This is not our proposal。The manage plane could rely on plan info or topo info built from somewhere else to decide which testpoints need to configure，in simple IP OAM case，only src and dst testpoints need to be configure.

How would you know ahead of time what nodes would need provisioning for CFM
attributes?  Altering parameters during troubleshooting is not how most
operators want to plan their networks.

-- Jeff

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Thu, 8 Oct 2015 10:18:58 +0000

Hi Greg, Ron, Jeff and all,

Sorry for keeping you waiting.

The new version of the LIME applicability draft has been published as follows:
https://tools.ietf.org/html/draft-zhuang-lime-yang-oam-model-applicability-01 
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-zhuang-lime-yang-oam-model-applicability-01 

Please let us know if it can address your concern. As usual, comments and suggestions are very appreciated.

Regards!

Yan and Tom (on behalf of authors)

-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年10月2日 23:35
收件人: Ronald Bonica; Jeffrey Haas; [email-masked]
主题: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

Hi Ron,

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Friday, October 02, 2015 6:56 AM
To: Jeffrey Haas; [email-masked]
Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

Jeff,

                                                            Ron
                                                           /chair hat on

---

From: Qin Wu <[email-masked]>
Date: Thu, 8 Oct 2015 11:01:21 +0000

Hi, Jeff:
Sorry for late reply, I have just come back from vacation.
Please see my response inline below.

-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Jeffrey Haas
发送时间: 2015年10月5日 22:16
收件人: gmail邮箱
抄送: [email-masked]; Deepak Kumar (dekumar)
主题: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

Qin,

On Sat, Oct 03, 2015 at 12:54:13PM +0800, gmail邮箱 wrote:
> > I think that trying to force the semantic of MD-Level into IP 
> > protocols will likely be highly problematic for operators.

Please consider that the current published yang model seems to suggest that such concepts are needed at the IP level.  This is why I'm asking for a demonstration of how the model is intended to apply to IP and MPLS.

If the intent is to add to the published yang model, that has not been clear from my reading of the mailing list archives.

[Qin]: I am afraid you misunderstand what I said above.
I think it is useful to have MD level parameter in the model structure, since MD level parameter stands for fault location information, having MD level parameters together can help us better and quickly locate fault or localize fault in the specific domain.

To apply MD level parameter to IP and MPLS, the management system will set MD level parameter in the base model and send MD level parameter to the source test point, therefore source testpoint doesn't need to set MD level parameter by itself, when testpoint get fault or test results by running OAM command(e.g., Ping, traceroute), these test results will send back together with MD level parameters to the management system using base model. Therefore test point may need to keep MD level parameter sent by the management system before it gets test results back. The management system doesn't need to maintain MD level information in this case.

Alternatively, the management system can maintain association between MD level information and test point identity, in this case, the management system doesn't need to send MD level parameters to the source test point, when testpoint get fault or test results back and send them to the management system, the management system needs to look up MD level parameters from database based on testpoint identity and represent MD parameters and test results using model structure proposed in the base model.

> > ［Qin］LIME charter said the scope is restricted to single 
> > administrative domain，do we intend to change to tackle inter—domain 
> > case？

That is obviously for the chairs to comment upon.  Given my background in BGP and how this mechanism is likely to be applicable at some point, I have to ask the long-term question, even if the short-term proposal is intended to be more constrained.

> ［Qin］The goal of lime WG，I think， is to identify common model 
> structure for various OAM tech at different layer. Just like 
> http://tools.ietf.org/wg/netmod/draft-ietf-netmod-routing-cfg/ did to 
> provide common struct for various routing tech do u aggree with 
> this？or u believe we should find different structure for oam at 
> different layer？

I agree that there should be common layers.  I believe that the RPCs that are currently specified have some promise to apply between the layers.  I do not see how the current proposal intends to be generic to IP and MPLS since it seems to be CFM-model specific.

[Qin]: To model OAM from different OAM protocol perspective, you end up with modeling OAM in different way since we use each OAM protocol as root node in the model structure.
To model OAM from fault management perspective and performance management perspective, you can model OAM in the same way, since from these two perspectives, we will not care about what OAM technology is used, what OAM tool is used, we will only be interested in where we can locate the fault(corresponding to MD/MA level parameter), where are these testpoints (MEP/MIP Identity), what kind of context information is associated with testpoint (MEP level parameters), what kind of OAM command do we have(corresponding to various rpcs)? we will correlate faults, defects and network failure information with fault location information, 
CFM like template did provide such concept. So what we are doing in the base model is to adopt CFM template concept and make it generic enough to apply to all the other OAM technology
And extend it to technology independent framework. Please see the first paragraph of section 4 in draft-tissa-lime-yang-oam-model-06
"
   In this document we adopt the concepts of the [IEEE802.1Q] CFM model
   and structure it such that it can be adapted to different
   technologies.
"

I think IP and MPLS also need to care about where are these testpoints, what kind of context information is associated with testpoint, what kind of OAM command do we have?
Why you think IP and MPLS OAM doesn't fit into such framework.

> if u have better struct，we are happy to hear！

I don't currently have a better proposal - only strong concerns about the impact of trying to impose CFM like mechanisms on IP and MPLS. 

 I'm also doing this because I think the lime work is useful and would rather see it succeed.

[Qin]: Thanks, I think that's also our goal.

> > My suggestion would be to work from this sort of use case in the 
> > future modeling work -  and note the caveat about avoiding requiring 
> > IP/MPLS operators to configure CFM attributes at every node!
> > 

How would you know ahead of time what nodes would need provisioning for CFM attributes? 

[Qin]: The management system should know this, the management system will receive service request from the customer who complains about network churn.
The service user may report coarse location or don't report any location information to the management system, the management system will choose test points and set associated MD level parameters based on the coarse location information given by customer or user profile corresponding to the customer (user profile may indicate coarse location information).
 Altering parameters during troubleshooting is not how most operators want to plan their networks.

[Qin]: You are right, but the management system can tune parameter and perform a second troubleshooting when it complete the first troubleshooting if the management want to further get fine grained fault and location information. This is about troubleshooting automation.

-- Jeff

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 19 Oct 2015 15:02:39 +0000

Pigging backing on this email to share a couple of thoughts.

Thanks Jeff for kicking it off!

> On Oct 2, 2015, at 11:58 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Roland,
> 

I agree a single domain traceroute would be a good example to show. Regarding inter-domain, I’d suggest let;s get intra-domain agreed first, as per our charter:
"The initial scope is restricted to a single administrative domain and may be extended for inter-domain scenarios in future as and when a need rises."

Qin, you answered Jeff’s question in prose on this email: https://mailarchive.ietf.org/arch/msg/lime/vViD6g8kfDvRur6Cgh8UfeCou58 <https://mailarchive.ietf.org/arch/msg/lime/vViD6g8kfDvRur6Cgh8UfeCou58>.

Perhaps you and your co-authors could expand on that example and describe it during IETF94? A quick demonstration of the model would anchor this conversation into more specifics and probably drive it more usefully. Showing how exactly it work. Thanks for that!

> traceroute IP implementations.  Perhaps it should be, but it's a bit

This is useful. Are you aware of other potential mismatch reporting and issues?

Thanks!

— Carlos.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 19 Oct 2015 16:53:39 -0400

Carlos,

Thanks for drawing my attention back to this mail.  My apologies to Qin for
not responding earlier.

> Perhaps you and your co-authors could expand on that example and describe it during IETF94? A quick demonstration of the model would anchor this conversation into more specifics and probably drive…

I would find such a presentation very useful.

Qin's mail seemed to convey that in the context of IP technologies, the
fields in the yang model are simply "keys of convenience" - they do not correspond
to underlying OAM technologies.  

While this seemed to be the likely idea, in some cases they will correspond
to real OAM keys (e.g. MD for IEEE technologies) and in others, are just
keys of convenience.  An example will show how these two world-views relate
to each other, and provide discussion points for considerations of keeping
the namespaces for such keys potentially disjoint.

> This is useful. Are you aware of other potential mismatch reporting and issues?

I didn't do such a thorough audit, but I would suggest such an audit happen
as part of taking this work forward.  Right now I'm concerned with the
higher level issues. :-)

-- Jeff

---

From: Qin Wu <[email-masked]>
Date: Tue, 20 Oct 2015 03:42:17 +0000

-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Jeffrey Haas
发送时间: 2015年10月20日 4:54
收件人: Carlos Pignataro (cpignata)
抄送: [email-masked]; [email-masked]
主题: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

Carlos,

Thanks for drawing my attention back to this mail.  My apologies to Qin for not responding earlier.

Qin's mail seemed to convey that in the context of IP technologies, the fields in the yang model are simply "keys of convenience" - they do not correspond to underlying OAM technologies.  

[Qin]: Just to clarify, I am not indicating that. If we put all OAM technologies under only one umbrella, I think the fields in the YANG model, especially list key, should correspond to the underlying technologies.

While this seemed to be the likely idea, in some cases they will correspond to real OAM keys (e.g. MD for IEEE technologies) and in others, are just keys of convenience.  An example will show how these two world-views relate to each other, and provide discussion points for considerations of keeping the namespaces for such keys potentially disjoint.

[Qin]: MD should have meaning for all the cases, in BFD case, it corresponds to area-id.
If BFD and LIME model have two different model structures, Mapping between two heterogeneous model structure become a challenging job. In my opinion, we should not take this way.

However if we take LIME as application of BFD, then both BFD and LIME can be developed as base models,
As a client of BFD, the LIME base model uses the services provided by BFD or grouping defined in BFD model(i.e., BFD can keep its own model structure). The LIME BFD YANG model augments the base LIME module to support BFD and provide consistent reporting ,configuration and representation and is defined
as a separate module. 
In this way, we can have common LIME model structure for all the OAM technologies, I think technologies specific model should share the same namespace as the base model, the namespaces should not be disjointed. 

Here is the example on how two word-views are related to each other.
https://tools.ietf.org/id/draft-wang-yang-bfd-oam-04.txt

Also you can see the similar example in the section 4 of draft-ietf-ospf-yang-03.

> > In path-discovery, grouping monitor-stats is used.  This includes a 
> > min, average and max delay stat.  This isn't something returned from 
> > many traceroute IP implementations.  Perhaps it should be, but it's 
> > a bit different.
> 

I didn't do such a thorough audit, but I would suggest such an audit happen as part of taking this work forward.  Right now I'm concerned with the higher level issues. :-)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 20 Oct 2015 09:08:21 -0400

Qin,

> [Qin]: MD should have meaning for all the cases, in BFD case, it corresponds to area-id.

There is no such thing as an area-id in the context of BFD.  Did you mean
something else?

> If BFD and LIME model have two different model structures, Mapping between two heterogeneous model structure become a challenging job. In my opinion, we should not take this way.

I agree that the mapping is challenging.  At the moment, I find a homogenous
use to be unclear and need the clarification examples to continue
commenting.

It's also important to note that I'm not really asking after BFD, although
that's a long term goal.  A simple ping or traceroute example is a good
start.

> https://tools.ietf.org/id/draft-wang-yang-bfd-oam-04.txt

Thanks for the -04 update. I see that the authors have now moved to using
the BFD defined groupings for the model.  This addresses one of my (and the
BFD yang authors') big concerns.

-- Jeff

---

From: Qin Wu <[email-masked]>
Date: Wed, 21 Oct 2015 02:34:43 +0000

-----邮件原件-----
发件人: Jeffrey Haas [mailto:[email-masked]] 
发送时间: 2015年10月20日 21:08
收件人: Qin Wu
抄送: Carlos Pignataro (cpignata); [email-masked]; [email-masked]
主题: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

Qin,

> [Qin]: MD should have meaning for all the cases, in BFD case, it corresponds to area-id.

There is no such thing as an area-id in the context of BFD.  Did you mean something else?

[Qin]: See the Module example-bfd-routing-app in the section 2.5.2 of draft-ietf-bfd-yang-00, area-id is part of example-bfd-routing-app.

> If BFD and LIME model have two different model structures, Mapping between two heterogeneous model structure become a challenging job. In my opinion, we should not take this way.

I agree that the mapping is challenging.  At the moment, I find a homogenous use to be unclear and need the clarification examples to continue commenting.

It's also important to note that I'm not really asking after BFD, although that's a long term goal.  A simple ping or traceroute example is a good start.

[Qin]: See section 5.1 of draft-zhuang-lime-yang-oam-model-applicability-01, it did give an example for IP OAM,
In this example, we can set technology type under data node "domain" to either IPv4 or IPv6, IPv4 means ping and traceroute for IPv4 technology, IPv6 means ping and traceroute for IPv6.
   module: ietf-gen-oam
      +--rw domains
         +--rw domain* [technology MD-name-string]
            +--rw technology        identityref  // set to IPv4 or IPv6,            
            +--rw MD-name-string    MD-name-string // set by the management system 
               +--rw MAs
                  +--rw MA* [MA-name-string]
                     +--rw MA-name-string       MA-name-string // set by the management system
MD is set by the management system, for example, as "MD1" in the LIME base model
MA-name-string is also set by the management system, for example, as "MD1-MA1" in the LIME base model, MA-name-string can be used to stand for ping and traceroute from different tenant or customer, or distinguish different tests that is used to pinpoint the type of fault and its location.

If the testpoint in the data plane doesn't want to receive MD and MA level parameters, the management system can choose not to send MD and MA level parameter to the test points, that means the management system and test point has different model structures, one is complete model structure with MD and MA level parameters, one is simplified model structure without MD and MA level parameters, when test point send back test results using simplified model structure, the management system need to put MD and MA parameters back and represent them using complete model structure. It adds a lot of complexity since the management system need to figure out which test results belong to which MD or MA. In some cases, it is not possible if the management system send multiple rpcs for ping to the test point, how the management system tell  which ping rpc is for MD1, which ping rpc is for MD2?

However if the testpoint in the data plane can receive MD and MA level parameters, the MD and MA parameter MUST not injected into ping or traceroute initiated by the testpoint since ping and traceroute doesn't support or understand MD and MA parameters.  therefore the test point need to keep MD and MA parameter. When ping and traceroute tasks complete and test results come back, the testpoint represent test results together with MD and MA parameter using LIME base model structure, and send back to the management system.

Hope this clarifies.

> However if we take LIME as application of BFD, then both BFD and LIME 
> can be developed as base models, As a client of BFD, the LIME base 
> model uses the services provided by BFD or grouping defined in BFD model(i.e., BFD can keep its own model structure). The LIME BFD YANG model augments the base LIME module to support BFD and provide consistent reporting ,configuration and representation and is defined as a separate module.

Thanks for the -04 update. I see that the authors have now moved to using the BFD defined groupings for the model.  This addresses one of my (and the BFD yang authors') big concerns.

[Qin]: Yes, happy to see that we are converging.

-- Jeff

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 21 Oct 2015 05:10:41 +0000

Hi Qin,
regarding the area-id in the 'module: example-bfd-routing-app' in the draft-ietf-bfd-yang.
You can notice that the area-id is outside of BFD configuration and characterizes routing domain, not BFD. BFD, as per RFC 5880, is not concerned with AS or VRF. And, as one of co-authors, can inform the community that we're considering changes to the BFD YANG model that will impact the example in question.

	Regards,
		Greg

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Tuesday, October 20, 2015 7:35 PM
To: Jeffrey Haas
Cc: Carlos Pignataro (cpignata); [email-masked]; [email-masked]
Subject: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

-----邮件原件-----
发件人: Jeffrey Haas [mailto:[email-masked]]
发送时间: 2015年10月20日 21:08
收件人: Qin Wu
抄送: Carlos Pignataro (cpignata); [email-masked]; [email-masked]
主题: Re: [Lime] CFM semantics, IP and MPLS OAM - how to proceed?

Qin,

[Qin]: See section 5.1 of draft-zhuang-lime-yang-oam-model-applicability-01, it did give an example for IP OAM, In this example, we can set technology type under data node "domain" to either IPv4 or IPv6, IPv4 means ping and traceroute for IPv4 technology, IPv6 means ping and traceroute for IPv6.
   module: ietf-gen-oam
      +--rw domains
         +--rw domain* [technology MD-name-string]
            +--rw technology        identityref  // set to IPv4 or IPv6,            
            +--rw MD-name-string    MD-name-string // set by the management system 
               +--rw MAs
                  +--rw MA* [MA-name-string]
                     +--rw MA-name-string       MA-name-string // set by the management system
MD is set by the management system, for example, as "MD1" in the LIME base model MA-name-string is also set by the management system, for example, as "MD1-MA1" in the LIME base model, MA-name-string can be used to stand for ping and traceroute from different tenant or customer, or distinguish different tests that is used to pinpoint the type of fault and its location.

Hope this clarifies.

-- Jeff