Minutes for LIME at interim-2016-lime-2
minutes-interim-2016-lime-2-1

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 <naikumar@cisco.com>

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.