RE: Relationship between BFD model and LIME base model

[Qin Wu <[e-mail]>]

Hi, Mahesh:
发件人: Mahesh Jethanandani [mailto:[e-mail]]
发送时间: 2015年9月8日 8:42
收件人: Qin Wu
抄送: Carlos Pignataro (cpignata); Deepak Kumar (dekumar); wangzitao; Ronald P. Bonica; [e-mail]; Benoit Claise; Joel jaeggli; Alia Atlas; [e-mail]
主题: Re: Relationship between BFD model and LIME base model

Thanks Qin for the summary. I would add that the last option (support for /bfd and /lime/bfd) should be considered the fourth option.

[Qin]: Yes, I miss it, I think this option would be a good option if we can come to agreement.
if we support
/bfd
/lime/bfd
That means both LIME model and BFD model should be developed as technology independent models or generic YANG models, in addition, BFD can be developed as model extension to LIME base model.
/lime/bfd can also be represented as /lime[technology=’bfd’]

The advantage of this approach is that LIME can still collate all OAM technologies and provide a hierarchy, and it does not require the technologies themselves to have to change their current configuration model.

[Qin]: your understanding on the advantage of this approach is not correct,

1.       LIME base model is not a super model which compose various technology specific OAM model together, LIME model is not device model proposed by draft-rtgyangdt-rtgwg-device-model-00.

2.       LIME base model provides abstract model structure for each OAM technology, Each technology specific OAM  model can extend from LIME base model, but one LIME base model can not be extended to support multiple OAM technologies.

3.       LIME base model will be mapped into each technology specific OAM model when the management system know which OAM technology is used to do the troubleshooting on specific network.


We can still investigate reuse of groupings and data types from option 2.

For a reference, please refer to the discussion on the netmod mailing list on root nodes - http://www.ietf.org/mail-archive/web/netmod/current/msg13243.html

[Qin]: I am not sure we should follow the example proposed in that discussion, Lada has already clarified root nodes discussion has nothing to do with routing-cfg model,
I would argue as well data nodes discussion is also not applicable to LIME model or OAM model.
If routing-cfg model follows
Routing/isis
Routing/ospf
I think OAM model should also follows
Lime/bfd
Lime/trill
Interface model should also follows
Interface/VLAN-Interface
Interface/Ethernet-Interface


If I was to extrapolate from that example, the lime model could contain something like this:

container technologies {
    list technology {
        key name;
        // information about MD, MA … would go here.
        container data {
            // all oam-technologies supported by lime are mounted here
        }
    }
}

[Qin]: I assume you haven’t had in-depth review of draft-tissa-lime-yang-oam-model-06, LIME base model has technology type to distinct one OAM technology from another.
Since you agree we go with /lime/bfd,
You should also agree we go with /lime/trill
                                                  /lime/nvo3
How  is it possible to support
/lime/[bfd,trill,NVO3]
It contradicts with the assumption you made.

The choice of where to build this hierarchy is now up to the implementor.

You could do this on the device if the interest is to do fault isolation on a device in which case your path would look like

/lime/technologies/technology[name=‘bfd-foo’]/data/bfd/...

[Qin]: If we go with /lime/bfd/, LIME in this path info stand for base model, bfd in this path info stand for model extension to BFD.
bfd has already indicated the OAM technology we are using.

or on the controller if you want to collate faults across a domain, in which case it would look like:

/domains/domain[name=‘bar’]/lime/technologies/technology[name=‘bfd-foo’]/data/bfd/...

I would argue that most operators would be interested in the latter and not just faults on the device.

[Qin]: if we go with /lime/bfd
LIME model has already provide hierarchy for BFD support as follows:
/domains/domain[name=’bar’][technology=’bfd’]/MAs/MEP[name=’LSR1’]/
LIME model has already correlate domain information with faults.

We can discuss all the options in a call. I am at IEEE meeting this week, but we can meet next week if need be.

On Sep 7, 2015, at 12:08 AM, Qin Wu <[e-mail]<mailto:[e-mail]>> wrote:

Carlos:
I have just come back from 3-days vacations. Sorry about the delay.
Deepak has already had two discussions with Mahesh about path forward, the goal is to try to find all the possible solutions to resolve the relation between BFD and LIME:
I think if BFD model likes to follow LIME model structure, there are three options we can exercise:
(1)     BFD model can follow common structure proposed in LIME and augment LIME model with technology specifics. We have already provide an example to show how LIME model can be extended to support BFD.(See attached), e.g., single hop, multiple hop can be distinct using sub-technology defined in the BFD model.
(2)     BFD model just try to reuse several groupings defined in the LIME base model and reference existing grouping in LIME by using “uses prefix name: grouping name”
(3)     BFD model just try to reuse several leafref type defined in the LIME base model and reference existing data nodes in  LIME by using leafref(See attached)
The options (2) and (3) use its own model structure and doesn’t follow LIME model structure completely, also In option (3), it is challenge or not easy to represent some data nodes in BFD model using leafref type defined in LIME. Therefore Option(1) is perfect if BFD follows LIME model

If BFD mode doesn’t want to follow the whole LIME model structure or only follow subset of LIME model structure with session level and per interface level, I think BFD model should be developed as standalone technology independent model or generic model and decouple from routing-cfg model, we should agree it is possible to have two generic models. when we want to translate generic BFD model into generic LIME model, it seems mount point proposal can be used to move BFD data nodes to LIME model structure(i.e., moving session-cfg from bfd model to session-cfg in LIME model, moving interface-cfg from bfd model to interface-cfg in the LIME model.

I am expecting to talk with Mahesh about these options. Hopefully we can converge discussion soon.

-Qin
发件人: Carlos Pignataro (cpignata) [mailto:[e-mail]]
发送时间: 2015年9月7日 10:40
收件人: Qin Wu
抄送: Mahesh Jethanandani; Deepak Kumar (dekumar); wangzitao; Ronald P. Bonica
主题: Fwd: Relationship between BFD model and LIME base model

Qin,

This is a great message, and I appreciate the discussion and seeking path forward with the BFD model.

I have not seen a response to this message, however.

Maybe you could have this discussion with a broader audience, including the LIME list.

Thanks,

— Carlos.



Begin forwarded message:

From: Qin Wu <[e-mail]<mailto:[e-mail]>>
Subject: Relationship between BFD model and LIME base model
Date: August 29, 2015 at 5:13:59 AM EDT
To: Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>
Cc: "Deepak Kumar (dekumar)" <[e-mail]<mailto:[e-mail]>>, wangzitao <[e-mail]<mailto:[e-mail]>>

Hi, Mahesh:
LIME model have five level parameters:
1.       MD level parameters
2.       MA level parameters
3.       MEP level parameters
4.       Session level parameters
5.       Interface level parameters
MD level parameters, MA level parameters can be directly inherited in the LIME base model extension and set as default value,
e.g, domain name in the MA level can be set to AS Number, Area ID,
LIME base model can provide flexible structure for BFD and other OAM technology.

Here we give an example how LIME base model can be extended to support BFD (See attached),
We model the same parameter proposed in draft-zheng-bfd-yang-04 using multiple level structure defined by LIME base model,
bfd-session-cfg defined in draft-zheng-bfd-yang-04 can be well grafted into session level structure defined in LIME base model
bfd-interface-cfg defined in draft-zheng-bfd-yang-04 can be well grafted into interface level structure define in LIME base model.

For notification, LIME base model only provide defect notification definition, doesn’t provide state-change notification, so new state-change notification can
Be defined in the BFD model,
For operation state, LIME base model doesn’t provide separate state data structure for operation state, so maybe BFD model can extend state data structure defined in
The base model for routing defined in draft-ietf-netmod-routing-cfg-19.

I am happy to discuss if you have any questions. I hope we can come to agreement soon.

I heard about your discussion with Deepak about harmonization of BFD with LIME, One proposal is to have BFD generic model and LIME generic model separately,
Support both
/bfd
And
/lime/bfd
if there is such consensus, I am happy to accept this. I also think if we go with /lime/bfd, I think we can provide better OAM management automation, or consistent reporting, configuration, representation, MD level parameters and MA level parameters are just management information, they should not be the burden for BFD, these management information doesn’t bother how BFD work(BFD fuction doesn’t need to know about it), just help establish the testpoints relationship or global view of OAM topo by associating test point(MEP) with MD, MA and other context information.

Regards!
-Qin
<bfd-leafref-lime.txt><bfd-leafref-lime.yang><draft-wang-yang-bfd-oam-04.txt>

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>