Minutes for LISP at IETF-91
minutes-91-lisp-1

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
                Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com )
                      Damien Saucez ( damien.saucez AT gmail.com )

AGENDA

Session 1/1 (150 min)
=-=-=-=-=-=-=-=-=-

THURSDAY, November 13, 2014
1640-1910, 150 Mins

- Administration        10 minutes
    Halpern/Iannone
    - Blue Sheets
    - Agenda Bashing
    - Status reports for WG drafts

There is not yet a working group document to discuss the impact of LISP as
required by the charter but a candidate document will be discussed by Damien.
There is a new version of threats but we will not discuss it this time. The DDT
document is going forward for alternative mapping system but is not presented
today neither.

o WG Drafts Update

- LISP Introduction
        https://tools.ietf.org/html/draft-ietf-lisp-introduction-07
        30 mins
        A. Cabellos

Last IETF we were urged to propose a final version.  We got a lot of feedback
to make it and produced -05 and -06 in October and -07 in November.  We issued
a last call that ends tomorrow.

The talk present the incremental changes between versions.

Reminds that the last call ends tomorrow.

Chair: ask if any question or comment

Ron: thanks for the new version that he likes. The paragraph in section 1 has
some english grammar problem that must be fixed (see his mail on the mailing
list).

- LISP EID Block Management
        https://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-03
        5 min
        L. Iannone

Last call was issued on the mailing list but there is some wording issues and
Geoff suggested some wordings (avoid allocation and assignment words) to have
more neutral approach.

Small wording changes but a bit everywhere, so it has been decided to block the
last call to fix this.

There is zero changes in the content, just wording, will make a new last call
just after the meeting.

Question? -> no question

o Non WG Documents

- LISP Impact
        https://tools.ietf.org/html/draft-saucez-lisp-impact-07
        15 minutes
        D. Saucez

Description of the different sections of the document and why they have been
put in the document.

Reminds that LISP offers plenty side features for free, they might not be the
most optimal, e.g., IPv6 co-habitation, but they come without having to to
anything particular to get them.

Sharon says they have an implementation and that it could be added to the
document.

Description of the problems that may happen when LISP sites and non-LISP sites
have to communicate together

Darrel says that there is a couple of use-cases documents that explain how to
address such issues

The document mostly explains how LISP helps to scale the Internet but there is
also a part dedicated to features not related to scaling the Internet.

Geoff explains that MTU issue was a nightmare while developing transition
mechanism with tunnels and that it is amazing that the MTU does not raise
particular problem in current LISP deployment.

Darrel says that with his experience of numerous LISP deployments they observe
that when there is an issue with MTU, it is obvious and they can fix it at the
time of the deployment. The deployment RFC goes through guidelines for that

Joel asks the authors to change the wording in the draft to reflect the
discussion

Darrel to precise it is not worse than other encapsulation-based techniques

Explanation of the problem with middleboxes

Darrel proposes to use the same structure to explain MTU

For the new version Damien asks if Ron can provide a brief text on the
difference between push and pull.

Ron says yes with his thumb

Brian asks to know by how much the BGP table can be reduced

the document discuss a study that shows  that most of deaggregation is done by
stubs and that if LISP is put at the stub all this deaggregation is removed
from the DFZ, reducing the size of the table but also the churn because most of
traffic engineering is done at stub.

Brian says the paper says what could happen, but it would be interesting to
know what is happening today with current deployment.

Luigi looked at the mappings in the current mapping system and checked how many
BGP prefix cover them and the ratio is approximatively 1 BGP for 10 mappings.

Darrel confirms they observe the same order of magnitude with only about 50
routes for 600 sites.

Damien to says that mappings can go down to /32 without impacting at all BGP

Chairs to ask for working group adoption (humming).

nobody to disagree. Will then check for adoption on the list.

- LISP Data-Plane Confidentiality
        https://tools.ietf.org/html/draft-farinacci-lisp-crypto-01
        15 mins
        D. Farinacci

Exact same presentation than in Toronto but had only 1m in at that time. Used
feedback from security experts to make this.

Present the workflow of the protocol on logs of his implementation.

Ron is not sure that the system is protected from Man-in-the-middle attack and
asks for clarification

Dino: It is based on diffie-hellman and the exchanged is passing via the
mapping system that, if using LISP-sec, is protected by an OTK

Joel: by itself the solution does not provide protection, but it is built upon
LISP-sec to get protected. The document should state it clearly.

Joel: we need the review of a security expert on this draft. Joel asks Brian to
help the WG finding a security expert.

Chairs ask if WG agrees for WG adoption, about 10 people read the draft. Nobody
disagree, will then check for adoption on the list.

Damien: what is happening if you lose one packet during the exchange or if the
ETR reboot?

Dino: if there is no state in the ETR it will not work because there is no map
entry and thus drop the packet. The ETR must trigger something like an SMR to
get a key.

Damien: what if there is a forged SMR? Would that make the regeneration of keys
all the time?

Dino: for forged SMR the problem is know and I am working on it with Albert.
Let's re-ask the question when the document about this will be available.

Damien: what if you have several ETRs? Do you share the key

Dino: you don't share, key is done per RLOC. That works well for unicast, for
multicast it is a problem as multiple persons should share the key. The
solution for now is to make unicast encapsulation for multicast.

Damien: how do you know RLOCs are from different ETRs?

Dino: we don't care, key is really per RLOC.

- LISP Signal Free Multicast
       https://tools.ietf.org/html/draft-farinacci-lisp-signal-free-multicast-01
       15 mins
       D. Farinacci

Tested it with VLC, the server behind a NAT, one client public the other in
NAT. Used NAT traversal.

Brian asks for clarification on the packet flow on the slides.

Lucy asks if multihoming is supported.

Dino answers that multihoming is supported and explains what's happening in
such situation.

Dino asks if it can ask for WG adoption

Joel says it does not seem to address any particular point of the charter.

Dino says there is interest from people to simplify multicast.

Joel asks to first fix the blocking items first.

Dino asks then why LISP-crypto can pass

Joel answers that it is because it address points in the charter

- LISP Generic Protocol Extension
        http://tools.ietf.org/html/draft-lewis-lisp-gpe
        10 mins
        D. Lewis

There is a lot of work on that and a -03 will come very soon.

Luigi to precise that in some situation the ETR will also have to maintain
state. In OpenLISP you can ask the ETR to check the association between EID and
RLOC for the received traffic.

The point is that xTR might have to deal with several types of encapsulation.

This is not yet a final version and many things have to be discussed still.

Darrel proposes to deprecate some features to get some fields available.

Dino: different encaps use different port

Darrel: better to avoid consuming ports

Damien: there is a lot of bits added and overloading of the different fields,
maybe it is time to think at making things more general. Why not generic TLVs.
That might make the header a bit longer but give a more elegant way to extend
the protocol.

Darrel: we have to keep in mind the backward compatibility problem. The key
requirement in this draft is to maintain backward compatibility.

Damien: what about proposing a document saying what would be the ideal and then
see how we can do that in practice.

Darrel: would like to work on such document but that does not belong to this
particular draft

Luigi: what is the position of version number? what size?

Darrel: the exact position is still to be discussed. For the size if backward
compatibility is the most important, you don't have much versions possible, you
are very limited. Nothing prevents having new versions with larger version
later.

Luigi: that would be fragmented...

Luigi: to document wants to ask for new IANA registry. Is that really
necessary, there is already the protocol numbers.

Darrel: the feedback was that it would be a waste of space (too many bits) and
some  people are interested about strange features that are not in the current
registry.

Luigi: but you can say you can just use the first bits of the registry

Joel: you cannot change the meaning of a registry

Luigi: if we have to implement we have to deal with a new set of registry while
the other registries are there

Joel: could not find a current registry able to deal with that

Erik: asks for clarification on VxLAN

Erik: you can also say that you will have a new registry that will be useful
for others.

Dino: you should use ether type and not create new registry because anyway
there is a problem with P bit.

- LISP Reliable Transport
        https://tools.ietf.org/html/draft-kouvelas-lisp-reliable-transport-01
        10 mins
        D. Lewis

no question

- LISP RLOC Membership Distribution
       https://tools.ietf.org/html/draft-kouvelas-lisp-rloc-membership-00
       10 mins
       D. Lewis

Joel: to know what prevents injection of wrong information.

Darrel: the assumption is that the underlay network is a close network. urp is
done in the underlay network

Joel: ok in a DC or a cable network, but how to protect from the outside.

Damien: the assumption is that the network cannot be compromised?

Darrel: yes, the endpoints can, but not the network (the CE can not the PE).

Luigi: what is the encoding you use? It seems to be different than an RLOC
record.

Darrel: it is just a set.

Luigi: why not using the RLOC record.

Darrel: we wanted to compress.

Sharon: could we use different options instead of imposing it.

Darrel: prefers to have one way only as it requires a lot of synchronisation in
the system.

Darrel ask people to read the document and comment it on the mailing list

- LISP FlowMapping NFV
       https://tools.ietf.org/html/draft-barkai-lisp-nfv-05
       10 mins
       S. Barkai

Sharon is asking for adoption.

Joel: for the moment nobody can ask for new adoption

Joel: we do not adopt use case but protocols, if the protocols allow you to do
that no need to adopt. You have to state what you need to have it working.

Joel: you have to say what features are requested. Kind of things we have to
look at.

Joel: this is the working group that decides what is the priority, not the
chairs. But nothing can start before the blocking points are unblocked.

Sharon says that to improve the way the system work it requires some "massage".

Luigi indicates that to decide we first have to know what feature are needed.

Joel does not see what is needed by looking in the current draft.

Chairs asks the authors to update the draft to get clear about that.

- LISP Multiprovider
       http://tools.ietf.org/html/draft-shen-lisp-multiprovider-vpn-00
       5 mins
       N. Shen

Can use multiple MSP with MSP meaning Mapping System Provider.
The example shows several sites that are willing to get to the same VPN but
there is global Instance-ID (IID)  coordination

Brian Weis: Why does the xTR needs to know about the fact that is going to go
through the gateway?

Joel: it doesn’t need to

Dino: does that mean that the gateway tunnel router of destination LISP site
and the entry coming back to the xtr is not needed?

Joel: it is not doing multi element, it is just a way to proxy it.

Dino: if ELP is not needed, how to map the IIDs?

Joel: The EID is unique but the IIDs are different on the two sites. It is a
single VPN space with a shared set of EIDs.

Clarification on the slides.

Dino: How they know where to find the information?

Joel: How you get the information is another question, but the assumption is
that the information is know.

- Overflow Time/Discussion
       20 mins

Dino: Asking Brian Haberman (AD) and the Chairs if the WG is doing its part by
moving forward the blocking documents.

Brian: The WG did a great job moving forward the intro document, the same has
to be done with the threat document and the impact document.

Dino: Can we recharter soon (as soon as blocking documents are done) to avoid
to have to catching up with the industry and instead of shake the industry

Brian: I agree. What the WG does is up to the WG participants and I cannot help
you to go faster. But as soon as you are done with those document I can help
you recharter.

Dino: Reasonable but can we have some parallelism going on?

Brian: The intro is in last call but threat and impact are not done yet. As
long as rechartering discussion does not remove focus from those documents that
is OK.

Dino: OK, as long as we work on those documents we can talk about the recharter.