Subject: Re: [trill] YANG models for OAM

From: Qin Wu <[email-masked]>
Date: Tue, 8 Jul 2014 12:07:02 +0000

Hi, Tissa:
There are many options for SFC OAM, BFD extension, Generic Header extension, Generic TLV extension.
Unlike other existing OAM protocols, mechanisms and tools, SFC need to address OAM for the technology that is above layer 3.
SFC haven’t developed OAM protocol yet at the top of layer 3.

Before they developing OAM protocol, they need to figure out whether they need to develop technology dependent OAM protocol,
Or technology independent OAM protocol since SFC OAM and Overlay OAM share a lot of similarities(e.g., both can use overlay technology to stitch a set of overlay node or service node to form the end to end path). Why not build one protocol to support both?

That’s why we bring up transport independent OAM covering various heterogeneous network technologies and propose to consolidate OAM in both
Management plane and data plane.
http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-02
http://tools.ietf.org/html/draft-king-opsawg-time-multi-layer-oam-use-case-01.txt

Regarding flow-entropy, why not reuse entropy mechanisms in the existing underlying transport. How is flow entropy different from ECMP choice you proposed in the draft.
If my understanding is correct, IEEE 802.1ag only support Equal Cost Tree (ECT) mechanism instead of ECMP, IEEE802.1Qbp support ECMP,
Are you proposing to combine ECT supported by IEEE 802.1ag with ECMP supported by IEEE 802.1Qbp and use them together at the same time in the same network?

Also BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., CCM-interval, BFD interval. If we integrate them together, we really need to think about how to integrate them together in the management plane. Is there any common component we can define for both? How we define these component and make them more extensible.

Regards!
-Qin
发件人: Tissa Senevirathne (tsenevir) [mailto:[email-masked]]
发送时间: 2014年6月30日 0:20
收件人: Qin Wu; [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: RE: YANG models for OAM

Hi Qin

There are several way this is applicable to SFC

1.       SFC is underlayer independent , which means it can have all sorts of encap types underneath, the model presented in tissa-netmod-oam, address exactly that issue. Instead of re-inventing and re-implementing various different OAM the draft propose to integrate them at the management layer.

2.       In this draft we define a flow-entropy as an opaque element that each of the technology type can specify and include. If we look at draft-quinn-sfc-nsh-02.txt, it define a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entropy. The beauty is that it is all up to the technology to specify that (size and shape is technology dependent) and base model is still intact.

With the above in mind , can you please review draft-tissa-netmod-oam and see it is flexible and extensible enough to for the purpose. If things are missing we can add and extend.

I have requested netmod WG chairs for a presentation slot for further discussion of the draft.

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: YANG models for OAM

Hi, Tissa:
Thanks for initiating discussion on this topic.
Unified OAM for multi-Layer network is a good idea to me.
draft-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out the an initial description of the problem.
The question to draft-tissa-netmod-oam is
I am wondering how this generic Yang Model can be applied to SFC environment?
How do you support the case where two endpoints support different layer OAM or doesn’t support any OAM at that layer.

BTW: I have cc’ed time mailing list since I believe this mailing list is purposed to look for generic and integrated OAM covering various heterogeneous networking technologies.
Regards!
-Qin
发件人: netmod [mailto:[email-masked]] 代表 Tissa Senevirathne (tsenevir)
发送时间: 2014年6月11日 3:03
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: [netmod] YANG models for OAM

All

We have published YANG model for OAM. #1 draft below place the generic framework for OAM, that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

1.       http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/

2.       http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/

3.       http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/

Please review and share your comments

Thanks
Tissa

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Tue, 8 Jul 2014 14:47:59 +0000

Hi Qin

May be a point is missed here.

1.      Thought SFC can go up and down on layers, what controls that behavior ? Is’nt it the Service header ?

2.      Is the OAM comes down to fault isolation, verification , monitoring etc for the specified SH ?

Like discussed before (many times) exact en-cap is less important what is important is to have a model that define OAM framework and scope. CFM to my opinion do an excellent job in defining what is needed. Hence the choice of a similar model for the YANG Model.

You have noted BFD and CFM are similar because they have similar set of timers. That is a wrong comparison. Have similar set of timers does not make two protocols the same. What makes them is what framework they follows.  We have used key word CFM here loosely. Though we borrow lots of concepts form CFM there are things that needed to be revisited.

I have requested presentation slots in nvo3 and NETMOD working groups and will be going through in details how each one of the technologies map to YANG model presented here.

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: YANG models for OAM

Hi, Tissa:

Regards!
-Qin
发件人: Tissa Senevirathne (tsenevir) [mailto:[email-masked]]
发送时间: 2014年6月30日 0:20
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: RE: YANG models for OAM

Hi Qin

Hi, Tissa:

All

Thanks
Tissa

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Tue, 8 Jul 2014 14:52:57 +0000

+SFC working group.

From: nvo3 [mailto:[email-masked]] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Tuesday, July 08, 2014 7:48 AM
To: Qin Wu; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nvo3] YANG models for OAM

Hi Qin

Hi, Tissa:

Regards!
-Qin

Hi Qin

Hi, Tissa:

All

Thanks
Tissa

---

From: Qin Wu <[email-masked]>
Date: Wed, 9 Jul 2014 01:27:51 +0000

Hi, Tissa:
I don’t think the idea you proposed have any inconsistency with what we are proposing in draft-ww-opsawg-multi-layer-oam-02. But looks like we are debating something,:)
You and us are both looking for OAM consolidation in the management, in addition, we are looking for OAM consolidation in the data plane.
Please see my reply inline below.

Regards!
-Qin
发送时间: 2014年7月8日 22:48

Hi Qin

1.       Thought SFC can go up and down on layers, what controls that behavior ? Is’nt it the Service header ?
[Qin]: It is possible, but who control that behavior, it is the management plane, the management plane need to interact with different layer OAM in the data plane or
Management plane need to interact with OAM protocol that is defined for SFC at the top of layer 3.

2.       Is the OAM comes down to fault isolation, verification , monitoring etc for the specified SH ?
[Qin]: Not clear whether SH is the only approach. OAM information can be put into BDF protocol or Generic TLV as well.

[Qin]: We are on the same page, but isn’t more straightforward and reasonable to define Generic OAM framework separated from Yang Data model for Generic OAM.
That’s what we like to propose in the draft-ww-opsawg-multi-layer-oam-02. Developing separate Architecture and Framework from Transport Independent OAM Problem statement draft.
Generic OAM framework should also allow more interaction between data plane and management plane and more interworking between different layer OAM protocol.

You have noted BFD and CFM are similar because they have similar set of timers. That is a wrong comparison. Have similar set of timers does not make two protocols the same.

[Qin]: That’s not what we are proposing, we hope in the management plane there is some common components or elements that can be used by not only BFD, but also CFM.

What makes them is what framework they follows.  We have used key word CFM here loosely. Though we borrow lots of concepts form CFM there are things that needed to be revisited.

[Qin]: That would be a very good survey, in my opinion, before going there, isn’t more nice to have a gap analysis document to
a .Identify technology dependent and independent component
b.  analyze and understand the different motivations and opportunities for optimisation of OAM in different technology networks,
and the trade-offs between those optimisations and the overall advantage of a generic OAM mechanism.

Hi, Tissa:

Regards!
-Qin

Hi Qin

Hi, Tissa:

All

Thanks
Tissa

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Thu, 31 Jul 2014 23:49:03 +0000

Don

I am aware of that, but this is different, MEF YANG model is specifically for Ethernet and structure does not allow to bring different addressing schemes other than MAC address. Additionally the proposed standard allow to add flow entropies and facilitate nested OAM between different technologies. You may have to read in to the details to see the actual differences.

From: O'Connor, Don [mailto:[email-masked]]
Sent: Thursday, July 31, 2014 4:32 PM
To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [nvo3] YANG models for OAM

Tissa, Greg, all

Metro Ethernet Forum has already standardized Yang Modules for Ethernet Service OAM Performance Monitoring and Fault Management. Please see MEF 38 and 39

http://metroethernetforum.org/carrier-ethernet/technical-specifications

Regards

Don

From: L2vpn [mailto:[email-masked]] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] YANG models for OAM

Greg

Yes it is, generic YANG model steup the base framework. It can be extended to add tools as well as other elements as well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the reason we have designed the model as modular as possible and extensible as possible.

Please let us know if any of the parts are not extensible or not modular enough.

Thanks
Tissa

On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tissa, authors, et. al,
I've read documents and would like to clarify scope of these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there would not be connectivity verification. And the performance measurement is the big part of OAM as well as protection coordination, defect alarms, and etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?
Regards,
Greg

On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <[email-masked]<mailto:[email-masked]>> wrote:
All

Thanks
Tissa

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

---

From: Qin Wu <[email-masked]>
Date: Fri, 1 Aug 2014 01:06:16 +0000

I think MEF more look at Yang data module for Y.1731, It is Ethernet technology specific Yang Data model.

Regards!
-Qin
发件人: OPSAWG [mailto:[email-masked]] 代表 O'Connor, Don
发送时间: 2014年8月1日 7:32
收件人: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir)
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [OPSAWG] [nvo3] YANG models for OAM

Tissa, Greg, all

Regards

Don

Greg

Thanks
Tissa

Thanks
Tissa

---

From: Qin Wu <[email-masked]>
Date: Fri, 1 Aug 2014 01:11:09 +0000

Exactly, different layer may have different addressing schemes. But I am wondering which layer the flow entropies are applied? L2, L3, MPLS layer?

发件人: netmod [mailto:[email-masked]] 代表 Tissa Senevirathne (tsenevir)
发送时间: 2014年8月1日 7:49
收件人: O'Connor, Don; Tissa Senevirathne; Greg Mirsky
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [netmod] [nvo3] YANG models for OAM

Don

Tissa, Greg, all

Regards

Don

Greg

Thanks
Tissa

Thanks
Tissa