Minutes: Rob Wilton Frank Brockners:: There is a mistake in the slides - Connection oriented doc is further along. Ron Bonica: agreed, it is a mistake. Greg Mirsky: Work on Packet Switch Network Connection oriented and connectionless abstract model. Could factor out common functionality between the two models. Benoit: Confused - goal of LIME was to get one YANG model, then need to split into two, no want to go back to the abstraction. What am I missing. Ron: If you can do it quickly, then show me quickly, otherwise ... Benoit: Conclusion was that it was not possible to have a common abstraction. Qin Wu: Discussion to split from one draft into several drafts was based on WG consensus. Greg: Initial draft came from Trill model, which represents connection oriented. Didn't split it, but re-designated it. At the time of the discussion, although we are are working on technlogy specific technologies, agreement was to have a common abstraction. Ron: How to describe the abstraction layer in YANG in 4 weeks, then the WG can adopt it, otherwise missed opportunity. Greg: I sent a proposal before Berlin, but didn't get any response. Qin: I don't follow Greg's proposal. Abstraction is already built into the models, and have already tried to achieve this. Greg: In correction oriented and connectionless networks, the topology could be described by the same model, but OAM is differnet and can't be described in this way. Some distinct differences in the models which is why we agreed to have two separate models. Ron: Please make the propasal in end on the WG list. Cut off is Dec 14th. Benoit: If abstractions are just end points then that could just be typedefs. Shutdown by IETF 99. Having been hearing that the models are almost ready for so long then we need to get them finished. Greg: We already have YANG models that shouldn't be impacted by LIME models. It would be better that LIME TWAMP, BGP, MPLS LSP TE ??? Ron: If these OAM models already exist then what value does LIME add Greg: LIME adds a common abstraction. Ron: Considering existing models. How does the LIME abstraction Greg: LIME model can augment BFD. Ron: What you are really doing is turn LIME on its head. If LIME augments other protocols with something that already has. Greg: LIME is the model that allows the operation to execute or instiante certain network OAM functionality. Qin: Based on clarification from Greg, it seems like a contradiction, I feel confused. Ron: Any other comments? Moving on to the connection less update (Michael Wang presenting):: Greg: Current state of connection less model does not address my comments during adoption call. I believe that the augmentation of technology specific models such as BFD. Michael: What to see a more abstract generic model. Don't want to describe nots of parameters in OAM specific YANG model. Greg: If you don't want to be tied to specific technology, why doesn't the contain the list of RFC xxx (tbc). 2. if there are other mechanism to do continuity check then I would like to understand what you mean. Greg: But you listing BFD single hop, BGP multi-hop, etc. Frank: Is the proposal to remove the refences on the specific models (i.e. the RFCs), the person needs to know what the RFC is. Rob: It doesn't make sense if LIME augments the specific technology modules because that requires devices have to implement all of those technologies. Greg: Scope of LIME is only for IETF OAM protocols. Lada: Concerned that schema mount is using in places where it shouldn't be. Schema mount is useful when the same YANG model is used in different places. If you want to augment then you can't augment in both places. Hence, adding technology specific then augment is a better choice. Confused about the groupings Michael: Groupings are taken from the technology specific modules. Lada: His conclusion is to an augment. Greg: The augmention has to be part of the base model. Michael: LIME model is only providing common subset. Greg: The module lists numerous RFCs, If you can't use existing methods then what is the value of the LIME model Benoit: Connectionless and BFD, which model augments which model? Qin: Import topoogy and network instance model, don't import from BFD model. Benoit: Want LIME model augmented with technology specific models. Ron: Ultimate value of LIME is to provide a common base that other OAM models that augment. Lada: If you have modules that are used already, you could possibly use schema mount. Benoit: Charter is about consistent configuration, reporting, and state. BFD are not going to use the same hierarchy. For BFD, what is the value? Perhaps the consistent reporting? Frank: Too late for BFD or TRILL, other OAMs might be willing to use it. Benoit: OK, but if none of those OAMs are considering using LIME. Jeff: BFD does allow for configuratoin by other means (e.g. OSPF can enable BFD sessions, LIME could do the same thing). Ron: Summarize: Window of opporunity has gone for BFD and TRILL, lets work fast and get it done. Qin: Window for TRILL might still be open. Lada: If LIME proves to be useful, then the BFD module could be modified. Some models such as BFD don't fit in. Trying to convince people that the framework is useful. Michael is presenting on connection orientated model: Greg: Several comments between this model and MPLS-TP model. See this as a TRILL model. Has stale reference to MPLS-TP. Ron: Proposed next steps: Two big obstacles: Greg has the action to produce some text by Beethoven's birthday, and decide what to do what this. Second question is regarding augmention. Proposed solution is that LIME model won't reference any RFCs, but will ask other working groups to augment LIME. Greg: Ask other WGs to review LIME model Jeff Haas: BFD YANG module has to be self contained, so it can't augment LIME. IETF technologies are losely coupled. Greg: OAM has often being regarded as a lonely child. Jeff: LIME has changes in building a common base model. Missing a common OAM layer.