Layer Independent OAM Management in the Multi-Layer Environment (lime) AGENDA
MONDAY, November 2, 2015 1520-1650
Yokohama, Japan
Room : Room 301 
Chairs : Ron Bonica < rbonica@juniper.net>, Carlos Pignataro cpignata@cisco.com
Jabber : lime@jabber.ietf.org
URL : http://datatracker.ietf.org/wg/lime/charter/

Agenda

Administriva

Charter: http://datatracker.ietf.org/wg/lime/charter/

Mailing List: https://www.ietf.org/mailman/listinfo/lime

Slides: https://www.ietf.org/proceedings/94/slides/slides-94-lime-1.pdf

General questions from Chairs to working group to establish LIME goals:

· What are the right questions for LIME?

· Do we add precision to LIME’s scope?

· Test Applicability of LIME’s generic model

· Align BFD and LIME YANG models – for which use cases?

LIME YANG Model

· Doc: draft-ietf-lime-yang-oam

· Presenter: Qin Wu, Deepak Kumar

· Slides: https://www.ietf.org/proceedings/94/slides/slides-94-lime-0.pdf

Objectives

- Look for common structure for all OAM technologies to provide consistent representation

- Using configuration model to provide consistent configuration and representation

Comments

Greg

- Continuity Check (in asynch mode) they detect multipliers and errors how you detect the end-points is dependent on the underlying technology

Qin

- We respect OAM technology, we do not the check protocol itself.

Greg

- You assume Ethernet/connection orientated paradigm.

Qin

- Is this operational model versus configuration model?

Greg

- Once you impose 1731 you establish connection orientated paradigms, this does not exist in IP or IP/MPLS OAM.

Ron (As individual contributor)

- We understand significant differences between connection-orientated and connection-less data planes. There must be commonalities?

- Do we need connection-orientated (CO) and connection-less (CL) models to avoid abstraction concerns?

Mahesh

- Regarding the common structure for OAM technologies, will this include other SDO technologies?

Qin

- No, our focus is IETF technologies.

In summary

- Review model structure based on Greg’s comments (CO & CL)

- We need to answer the questions from Operators

- We keep discussing applicability, need to focus on solutions

LIME Applicability Document

· Doc: draft-zhuang-lime-yang-oam-model-applicability

· Presenter: Zhuangyan (Yan) 

· Slides: https://www.ietf.org/proceedings/94/slides/slides-94-lime-2.pdf

Objectives

- To provide consistent reporting, configuration and representation, augment the LIME base model with specific OAM information to generate LIME model

Comment from room

- Is inter-domain in or out of scope?

Yan

- It is out of the LIME charter and not revealed in LIME base model

In Summary

- Open issues include: how MD&MA works for BFD and MPLS?

- Inter-domain still out of scope? Depends on IP definition of domain, but you should review the model to remove the need to ask this question

- Poll by the chairs asking who has read the updated version? Response: “a few”

BFD Applicability

· Doc: draft-ietf-bfd-yang

· Presenter: Reshad Rahman 

· Slides: https://www.ietf.org/proceedings/94/slides/slides-94-lime-3.pdf

Carlos (as Chair)

- You listed pages of concerns. Can you summarise the clear/top concerns?

Reshad

- Major concern is MD, and being too generic. BFD is uses across multiple technologies, so having a generic model is difficult.

Carlos

- What do customers want? On Sunday we discussed use cases, including on-demand. Even with seamless BFD you are not configuring the classic BFD.

Greg

- You still operate within certain addressing. We will report the result as loss of continuity, then keep sending indefinitely.

Carlos

- Is the main issue end-points and identification of domains? Can you summarise the top issues, rather than every NIT?

- Should we keep this as generic, or can we use it for two models?

- Should we also consider seamless BFD and on demand?

Greg

- CFM imposes much more configuration versus BFD, another example of paradigm diversification. We cannot solve this in LIME as we do not develop new OAM protocols

In summary

- Current LIME model is not suitable for BFD

- Current thinking is BFD YANG model should not augment the generic LIME model

- LIME might use groupings from BFD for networking technologies which are more “IEEE-like”, not basing the model on only IP/MPLS

- Seamless BFD combines on demand and proactive capability

- Categorising “end-points” is probably the hardest issue to address (identification of “end-point”, and definition of “domain”)

- More discussions needed between BFD and LIME teams

Layer Transcending Traceroute

· Doc: draft-nordmark-nvo3-transcending-traceroute

· Presenter: Erik Nordmark

· Slides: https://www.ietf.org/proceedings/94/slides/slides-94-lime-4.pdf

Greg

- Using target FEC, is it there? Checking tunnel mapping to CP. LSP ping underlay to verify mapping. So you need to include L2VPN FEC in your PING. Include your FEC for your LSP, its work

- You will need to have a policy configured

- Lime will provide correlation of results

Ron (Chair)

- We need to discuss the underlay policy issue

In summary

- Existing traceroute shows the path even though the user can’t control the devices nor the path

- Overlay networks might hide underlay path

- Does the LIME model prevent layer transcendence as described here?

- Should LIME be open to layer transcendence, “subject to policy”