LIME Interim Meeting #2 — Connectionless (CL) Date: 27 May 2016 Time: 10:00-11:45 am EDT Topics: OAM Connectionless (CL) YANG Model Event: http://www.worldtimebuddy.com/event?lid=4487042&h=4487042&sts=24405360&sln=10-12&a=preview Scribe: Nagendra Kumar Nainar Minutes: LIME CL meeting: ================ Attendees: Carlos, Deepak, Greg M, Qin Wu, Ron Bonica, Sri Hari, Nagendra, Michael, Reshad. Minutes summary: * Chairs introduced the purpose of the interim meeting and asked the authors to share the document. * Deepak shared the document and explained the differences. * Discussed about Passive OAM. Discussed if it should be in Connection Oriented or Connection Less document. Agreed to discuss this on the alias for consensus. * Discussed about definition for short lived OAM. Agreed to add some terminology definition for clarity. * Discussed about the Test Point. If "A pair of address" can be considered as TP. Need more clarity around this. * Discussed about Passive OAM definition. Recording information in data point increases the size and changes checksum. So it is not passive any more. * Agreed to share the references from IPPIM Work Group to have a clear terminology and definition on how OAM model with information recording in data packet should be termed as. * Discussed about the Notification section added recently. * Discussed if Notification is related to LIME or SUPA. * Discussed about current tree positioning. Should we have OAM specific (BFD) approach or transport specific (IP/MPLS) approach. * Discussed about the IPFIX and Data Export model. Should it be here in this document or to be dealt by SUPA. There might be some commonalities as even Ping/trace uses timers to identify delay/jitter. * Discussed on the model Agreed to change "path-discovery" to "traceroute". * Chairs asked the authors to update and publish a new version. * Chairs will ask for WG adoption after the new version. Detailed Discussion captured: Carlos: Authors submitted a new version yesterday or today. Qin: Yes. we submitted recently. Some changes in technology specific OAM model. In this update, we removed entropy and ECMP and updated TTL, included all comments from last interim meeting. Ron: Carlos and I will read and take a decision by next Friday. Greg: Took a short look at the document. Some definitions are different from CO document and what we proposed in MPLS-TP OAM document. Ron: Is it drastically different or can it import the changes?. Greg: Need to check further, took a very short look. We can talk by next week. Ron: Can we do it in next few weeks. Greg: Yes. Ron: Authors, Spin another version in few weeks so we can take a look and take it up to WG adoption call?. Deepak: Send us the offline comments and we will include it. Carlos: Please have the discussion on the mailer list instead of offline. Once it is updated, we will have a look. Connection Less Document: Ron: Can the Authors present the document?. Deep: Updated the document yesterday with passive OAM. People might not have had time to look into it. Passive OAM is added as a feature. Greg: I have a question. passive OAM should be CO or CL? Deepak: We put this in CL. We can go ahead and get it as a comment. Greg: You have statistics for IPv4 and IPv6. For CL, MPLS is part of CL, excluding MPLS-TP. So can it be just another object?. What is the definition of long lived OAM session. Deepak: It is more like a BFD kind of session. Greg: What if we have SBFD and use it to just probe the ability of certain path. Will it create certain stats or not?. Deepak: I may need help in that area. Ron: Is it not on-demand and Continuous instead of short-lived vs long lived?. Deepak: Yes. Greg: We will need to check and correct the terminology. Ron: Trace can be long lived too. Greg: Let us think about the terminology. Carlos: I can send the terminology. I can take that as an action. Deepak: Now in section 3. (Asks if there is any question on this) Greg: In CL OAM, I believe, there is no OAM layer. Deepak: It is just to differentiate between underlay/overlay layers. This is to bring relationship between different layers. We can discuss to see if it is required and remove if not required. Deepak: The model is pretty simple now to differentiate between different layers. It is not possible else. Greg: ok. I will need to read the new version. Deepak: I will put a comment here asking for review comments from Greg. (Marked it in the document) Greg: I am fine with first and second bullet in section 3.1 Deep: This is coming from BFD. It is there in their model. Greg: I don’t think we put it as a test point. But need to check. Reshad: we don’t have the concept. Depending on whether it is single or multi hop..do we have test point in BFD. (Incomplete) Greg: We define, src/dst to define the BFD session. but it is not the test point. It is the tested path/object. Reshad: yes. Greg: If it is test point, it should be one address or interface. Reshad: Should we use address instead of entity?. Greg: A pair of addresses mentioned as test point is the issue. Pair of address is not singular. Test point should be singular. Deep: One or multiple path is also possible. Greg: We are assuming there is continuity between endpoints. Deep: we can rename it. Greg: BFD have a local test-point and remote test-point. Deep: TP address can be local or remote. So local will be src+interface... Ron: Seems Greg is not keen of having TP here. Deep: Let us go to the model. We put this as an action item. We can define another object if required. Carlos: About last bullet (in Section 3.1), you should remove that. Deep: It is removed from model, but not yet from the document. it will be done. Carlos: Perfect. Deep: Let us go to section 3.2 Greg: I have a problem with the definition for passive OAM. If we record some information in data packet itself, then it is probably not passive. We can assume that there is some payload. But we are changing the length of packet and it will not be passive anymore. By changing the packet, we are changing the checksum. Carlos; Can you share the definition of passive from IPPIM?. Greg: Ok. Deep: (Incomplete.) Sri: Greg is right. It is not exactly passive. But the intention of saying it as inband as it contrast with active OAM. So we kept the name as passive. We can call it as inband OAM instead of passive OAM. Deepak: It is not really inband. Sri: By inband, I mean to say it is not a separate packet, but inband with data packet. Greg: we can use picky-back OAM. it might not fly :) Inband is something which is already part of OAM. Anything traversing the same path is considered as inband. I will share the reference from IPPIM WG on definition of passive method OAM and lets think about the terminology. Greg: We can go to section 3.4.. Checking the definition for upstream and downstream path. Deep: This is a stitching scenario. In case of vxlan tunnels, for inter-vlan routing, it go to GW and gets translated and flows over the tunnel again. Greg: From label distribution, Upstream and Downstream have different meaning. we may need some text to introduce the terminologies. We may need some time to read. Deep: Yea, you can send us the comments. section 3.7 "Notification" was recently added. Greg: (Incomplete) Deepak: It creates a ACL policy and creates notification on error. The info is stored in the configuration than RPC as it is more like configuration driven. It is more like BFD model. Greg: I understand BFD being proactive, it uses a similar alerts when there is state change. Deep: For passive OAM, when there is any event based trigger, there will be some notification. (Explained about different notification types). Sri: The intention of notification is either triggered or threshold based, where we specify some watermarks and based on it, we expect the node to deliver some notification on need basis. It is not like BFD to automatically trigger but threshold based. It is not RPC based. It is more like threshold based notification. This is one aspect of notification and other is Data Export. Greg: Would that be more applicable to SUPA?. you define some generic policy and have some information exported. We have some policy to monitor and use some metric and query..(Incomplete) Michael: It may not like SUPA. The policy is defined based on condition/action?. Greg: The action can be empty or raise alarm. I need to read more. Deep: It is very much related to ACL, but once we have it configured, (Incomplete) This is a new item for discussion and may need more information to be added. Model might be more clear. (Discussion on the model). Greg: We will think about the objects (src-dst-address) is really a test point. Deep: Mahesh also pointed. Deep: We have to remove TLV address. Greg: RFC4379 should be replaced with bis document. For mLDP, there is a YANG model. Deep: They should extend further things. Greg: Since now we have much of it defined elsewhere. we need to see how it fits. If it is defined elsewhere, we will ask the authors to review the objects. In some places, RFC5884 is used differently. it needs to be fixed. Carlos: What is the rational of having BFD at the same level for MPLS and IP. RFC5881 is for IP and 5884 for MPLS and there is no tools-bfd?. Deep: This is more of OAM capability from the device. I may need some guidance. Carlos: It is a useful part of tree as a capability. But it either should be OAM specific (BFD) or should be transport specific( IP/MPLS) etc. Deepak: BFD is OAM technology and IP/MPLS are transport technologies. Sri: Same comment is applicable for passive OAM as well. Deep: Should we have passive OAM as a standalone tree?. Sri: (Incomplete) Deep: You had some question on IPFIX. Qin: it is just a comment. Passive OAM is mandatory or optional?. Deep; We will re-org to different tree. so it is optional. Greg: It is intended to have IPFIX model here?. I would mention that we will have a separate model for IPFIX. Deep: It is more of a Data Export. Greg: The export model more appears to be SUPA related. Exporting data is separate function. Exporting data or measurement is not function of OAM. Sri: I agree. We can discuss more offline. The only intent is to choose what type you want to do for export. Greg: This might be good for discussion. FCAPS - data export is somewhere. we need to find where it fits. we can discuss this. Another question. Now we talk about delay/jitter. so that is under performance metric. it is already in right group. How is this document related to perf measurement document. Deep: We might have to define common things. Greg: We need to check if the time based parameters are part of LIME or SUPA. Carlos: This is an action plan to check SUPA closely and have an opinion with the co-chairs. Greg: We will analyze and discuss the TP address. Deep: Rest all are different augmentations. Because of the lists, the tree is very huge. You can take a look and share the comments. Sri: Regarding PM, we added delay/jitter here to have it as a simple performance metric. We can discuss if required to find a better home. Deep: Delay/jitter is available in normal ICMP ping as well. Explained the overview of the tree. Previous comment was to call path-discovery as traceroute. should we change this?. Greg: We can change this as traceroute. Highlighted the notification generated on the errors. Greg: Very good coverage. Let us take some time to read and continue our discussion o the list. Ron: We made much progress?. Greg: Yes. this is a very new material. It will take some time. Ron: Can the authors publish a new version?. It is not mature as CO. Is it appropriate for WG adoption call?. Greg: Yes, we can share the comments to the authors. Ron: CL, we will ask authors to publish a new version and then we will ask for WG adoption. Meeting Adjourned.