Re: Relationship between BFD model and LIME base model

[Mahesh Jethanandani <[e-mail]>]

Thanks Qin for the summary. I would add that the last option (support for /bfd and /lime/bfd) should be considered the fourth option. 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. 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 <http://www.ietf.org/mail-archive/web/netmod/current/msg13243.html>

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
        }
    }
}

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/...

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.

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]> 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] <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]