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

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
                Terry Manderson ( Terry.Manderson AT icann.org )

SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com )
                    Luigi Iannone ( ggx AT gigix.net  )


MONDAY, March 03, 2014
1520-1620, Session 1 (of 2). 60 Mins

=================================================
Note Takers: Luigi Iannone, Wassim Haddad, and Damien Saucez  

Note Well!


Agenda bashing
http://www.ietf.org/proceedings/89/agenda/agenda-89-lisp

Chairs' Slides
http://www.ietf.org/proceedings/89/slides/slides-89-lisp-8.pptx
=================================================

Joel Halpern => Not much progress on LISP Introduction
     (http://tools.ietf.org/html/draft-ietf-lisp-introduction-03). We
     will deal with that right after this meeting.

Joel Halpern => LISP Deployment Consideration
     (http://tools.ietf.org/html/draft-ietf-lisp-deployment-12) is
     done and is in the RFC Editor queue.
       
No Agenda Change Proposed.
=================================================



draft-ietf-lisp-threats	(Damien Saucez)
Document: http://tools.ietf.org/html/draft-ietf-lisp-threats-08
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-7.pdf
=================================================

Damien Saucez => (end of presentation) Do folks think we are ready for
       WG LC?

Terry Manderson => (to the room) Let's check the consensus on this
      question. If ready for WG LC please hum now.

[Consistent number of people humming]

Terry Manderson => Please hum if you believe this document is NOT
      ready for WG LC.

[nobody humming in the room]

Terry Manderson => Thanks, we will take it to the ML.


draft-ietf-lisp-eid-block  (Luigi Iannone)
Document: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-08
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-0.pdf
=================================================

Luigi Iannone => Document should be ready for a second round of WG LC.

Terry Manderson => Anyone has comments on this document?

[No comments from the room]

Terry Manderson => (to the room) If you think that document 08 is
      ready for WG LC please hum now.

[Consistent number of people humming]

Terry Manderson => Please hum if you believe this document is NOT
      ready for WG LC.

[nobody humming in the room]

Terry Manderson => Thanks, we will take it to the ML. When we go for
      WG LC on the ML and we ask for reviews please do it.



draft-ietf-lisp-eid-block-mgmnt	(Luigi Iannone)
Document: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-01
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-1.pdf
=================================================

Geoff Huston => The ending paragraph of section 4 goes?

Luigi Iannone => Yes.

Geoff Huston => In section 5 there are some normative word there (RFC
      2119), do you really want to use normative words in an
      informational RFC?

Joel Halpern => It is allowed, the question is whether it is intended.

Geoff Huston => Yes, if it is ok, that's ok.

Geoff Huston => Back to section 4, you talk about 99% of the time, do
      you really want to enforce such figure? You can state the same
      intent without being so specific.

Luigi Iannone => The main message there was to provide a reliable
      service. I agree we can be less specific, rewording the sentence
      without numbers, if this is ok.

Geoff Huston => Perfect.

Geoff Huston => About the allocation fees, this is more an IANA/IESG
      problem rather that something to be decided in the WG.

Luigi Iannone => If people think is better we can avoid mention
      fees. I see no issue there.

Joel Halpern => Can the authors please summarize the requested changes
     send them on the list to see if people agree?

Luigi Iannone => Sure.



draft-farinacci-lis-crypto	(Dino Farinacci)
Document: http://tools.ietf.org/html/draft-farinacci-lisp-crypto-00
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-9.pdf
=================================================

Joel Halpern => (On the Diffie-Hellman slide) To avoid sending around
      "p" and "g", we can ask the SaaG WG to create a registry of
      values for "p" and "g" that are good values and you ship just an
      ID for them. 

Michiel Blokzijl => Each time you receive a Map-Request you generate a
	key	for the requester, what if you are flooded by
	requests? You are going to spread your keychain to thousands
	of requesters and store them locally?

Joel Halpern => Thousands of keys is a tiny amount of space, the
     computation of a continuous stream of keys is the issue.
 
Dino Farinacci => The key is a piece of information like RLOCs, is the
     computation load that is high, but if you want security you have
     to pay something.

Michiel Blokzijl => But you need to apply Diffie-Hellman thousand
	times. 

Joel Halpern => Yes, this has to be covered in the draft.

Dino Farinacci => Yes, but if you have several RLOC for the same ITR
     then you can use a shared key to reduce the load but we need to
     know how much security we want there. Is a hard trade-off to make.

Joel Halpern => We need to add text on that.

Dino Farinacci => Yes.

Fabio Maino => These types of mechanisms try to push the load on the
      requesters, so we can think to another message that ask the
      requester "send me back this message if it is really you".
      
Joel Halpern => Yes, but the challenge violates the fact that we want
     to do only one exchange. My suggestion is to write text on this
     trade-off and what the working group thinks about it because any
     answer is the basis to discuss what is the best answer.

Fabio Maino => It would also be interesting to see how this can be
      applied to lisp-gpe and vxlan-gpe because there we can relax the 
      restrictions we have on the header format. This way we can use
      more standard  ways to do encryption and authentication. 

Dino Farinacci => By adding more header space?

Fabio Maino => Yes, for example.

Dino Farinacci => I should have added the requirement to not add more
     space to the header.

Fabio Maino => Yes, but this will need hardware change anyway.

Joel Halpern => Robert Raszuk brought up in the ML that we need to be
     able to use generic algorithms at least for encryption and may be
     for key generation. I need to talk with the  security people. To
     do this in a one round trip time may need more information in the
     Map-Request/Map-Reply packet format.

Dino Farinacci => We need to do what we can to keep this out of the
     mapping system.

Joel Halpern => As long as we keep the information in the
     Map-Request/Map-Reply it should work. But we need to support
     agility in these two dimension otherwise security people will
     tell us to fix it.




draft-freitas-bellagamba-lisp-hybrid-cloud-usecase (Santiago Freitas and Patrice Bellagamba)
Document: http://tools.ietf.org/html/draft-freitas-bellagamba-lisp-hybrid-cloud-usecase-00
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-2.pptx
=================================================

Dino Farinacci =>  (on the use of IPSec tunnel to traverse NAT) That
     is why integrated solutions work well. You can take a NAT
     traversal design and a Crypto design and put them together in
     this use case. For user this will be much better.

Patrice Bellagamba => Yes.

Joel Halpern => Once we clear the blocking documents we will be
     discussing the introduction of new use cases. There are lots of
     new things, like this document, that we will discuss at the point.

Dino Farinacci => Does this use case have any special new requirement
     in multicast? 

Patrice Bellagamba =>  We did not work on that yet, so at this point I do
	not know. 



draft-moreno-lisp-datacenter-deployment	(Victor Moreno)
Document: http://tools.ietf.org/html/draft-moreno-lisp-datacenter-deployment-00
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-3.pptx
=================================================

[No questions from the room]     





MONDAY, March 03, 2014
1630-1730, Session 2 (of 2). 60 Mins

[Skipped afternoon break]
=================================================

draft-hertoghs-lisp-mobility-use-cases	(Yves Hertoghs)
Document: http://tools.ietf.org/html/draft-hertoghs-lisp-mobility-use-cases-00
Slides: Missing Slides on the material page (last checked 13 Mar 2014)
=================================================

Joel Halpern => (On use case 3) How to make sure that the host
     registers itself? In a DC the orchestrator knows that a hosts
     moved, but in a generic domain how to know?

Yves Hertoghs => We can use the same idea like wireless mobility but
     we did not add text yet. But there are also DC specific
     techniques that we can use like intercepting host traffic.

Dino Farinacci => (on the overview slide) If the NVO3 comes here
     asking to use your overlay which of your 7 cases you would
     recommend?

Yves Hertoghs => Then 5 would be my choice. If you have xTR that can
     accept register for both IP and layer 2  and can forward IP and
     non-IP traffic, then it seems to cover all the use cases of
     NVO3. 

Joel Halpern => A comment to the presenters of the last three
     documents. Thanks for bringing this work here. However, what
     strucks me is the fact that we have three drafts with overlapping
     use cases coming from the same company.

Darrel Lewis => We are all individuals here.

Joel Halpern => Yes. Independently from that we either combine or
     disambiguate. Would be good if they do not overlap.

Yves Hertoghs => Fair point. But we could have a distinguished
     deployment guidelines section. 

Darrel Lewis => Some of these mobility use cases may require protocol
       extension, so there is a third dimension along different use
       cases and deployment guidelines.

Joel Halpern => Uses case are interesting and will drive us to do
     something. From the WG perspective, this can lead to work on
     protocol to address gaps identified by these use cases.  That is
     why use cases need to be clear.

Darrel Lewis => Yes, and as part of the re-chartering we should
       probably work on a taxonomy of these use cases.

Yves Hertoghs => And either collapse the document or disambiguate.

Joel Halpern => Yes, and I am not complaining about the number but
     their relationship is not clear.



draft-coras-lisp-re	   (Florin Coras)
Document: http://tools.ietf.org/html/draft-coras-lisp-re-04
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-10.pdf
=================================================

Dino Farinacci => One of the thing we should look at is multi-homing
     at the source. Back when we where working on PIM the question
     was: "Do you want the core to decide whether the replication
     should be done at the source?" If there are two RLOC of the same
     site that join separately, then may be you have to do
     replication. We need to think about it.

Darrel Lewis => You indicated that RTRs are close to 1 and 2, how is
       that determined? There is any previous knowledge?

Florin Coras => Is configuration, you provision RTRs to do replication
       for the source. The other approach would be to have the
       Map-Server to dictate this, by having some additional
       knowledge. One last approach is to have a third party that
       configures the whole topology. Concerning how the ETR know it
       is close to 13: is BGP. The ETR requests who are the upstreams
       and the mapping system provides the leafs. Who decides who is
       leaf and who is not? We go back to point 1. But now the ETR can
       choose between 11, 12, 13.


Dino Farinacci => A way to thing at this is to have a level 0
     consisting in a TE box close to the source and level N TE boxes close
     to the potential destinations, so based on the source address you can	
     decide if it is level0 or level N. 

Darrel Lewis => The relationship looks somehow arbitrary.

Florin Coras => For now it is configuration.



draft-kouvelas-lisp-reliable-transport	(Isidor Kouvelas)
Document: https://tools.ietf.org/html/draft-kouvelas-lisp-reliable-transport-00
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-5.pptx
=================================================

Gal Mainzer => What about non-proxy mode and the communication between
    ITRs and ETRs? 

Isidor Kouvelas => This is just between ITRs and Map-Servers and does
       not change the way Map-Requests are processed.

Gal Mainzer => What is the Map-Request is forwarded to the ETR?

Joel Halpern => We change just the registration process, not the
     request process not the reply  process.

Michiel Blokzijl =>  In the current specification we have a limit in
	the numbers of elements we can pack in a Map-Register, because
	of the MTU. With TCP we can be able to pack 256 RLOCs,
	especially IPv6 addresses, whereas previously was not possible.

Joel Halpern => We still ne to change Map-Replies.

Michiel Blokzijl => So we do not deal with this? OK. 

Isidor Kouvelas => Note that we did not change at all the definition
       of Map-Register.

Dino Farinacci => This can be also save battery life on mobile phones.
     
Isidor Kouvelas => You still have to run the TCP session, so if the
       number of RLOCs is low you do not gain that much.

Joel Halpern => Did you specify, in the draft, what to do when the transport
     connection comes up? DO you register everything again?

Isidor Kouvelas => Yes you register again. It is written in the state
       machine. Actually is the Map-Server that requests a refresh. We
       can easily implement some state on the Map-Server so to allow
       things like "send me everything beyond this progress point so
       to avoid exchanging the complete state.

Joel Halpern => That seems powerful. Thank you.

 


draft-farinacci-lisp-signal-free-multicast	(Dino Farinacci)
Document: http://tools.ietf.org/html/draft-farinacci-lisp-signal-free-multicast-00
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-4.pdf
=================================================

Joel Halpern => If we have several ways to handle multicast, the ITRs
     can support one or more of them, the ETRs can support one or more
     of them, how will they know how to do the actual communication?

Dino Farinacci => We need some negotiation somewhere, like in the
     crypto case.

Joel Halpern => May be we can again put something in the
     Map-Request/Map-Reply, but looks like putting things in the
     registration is not enough because is a harder problem.

Dino Farinacci => I would be happy to say that we are ready to
     converge on one solution, but we are not yet there.



drat-rodrigueznatal-lisp-sdn	  (Albert Cabellos) 
Document: http://tools.ietf.org/html/draft-rodrigueznatal-lisp-sdn-00
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-lisp-6.pdf
=================================================

Dino Farinacci => Flow caching is scary. We will have a scaling issue
     in the forwarding plane. I think we can get the 5-tuple to work
     with DDT, just put a destination address at the top of the
     hierarchy. But if we have to find the mask of the 5-tuple
     equivalent it is going to be difficult.

Albert Cabellos => Agreed. You are suggesting to use the destination
       address on top of the hierarchy and go down, up to the source
       port. 

Dino Farinacci => I did something similar for S,G, where G can be
     specific and S can be coarse. But you need to do a conscious
     decision on who has precedence, and you want to change this?
     or you want to hard code it in the architecture? These are hard
     decisions to make.

Albert Cabellos => I fully agree.

Gal Mainzer => If we talk about SDN, then we talk about service
    chaining,  if we do such kind of lookup at every hop then we will
    add latency to each packet. We should consider doing this only at
    the first hop. The first hop can push the information to the
    rest of the hops.

Albert Cabellos => Good point. Thank you.

Joel Halpern => One can note that LISP has provision to carry multiple
     hops in the packets.

Darrel Lewis => Whether you use ELP, like has been presented during the
       last meeting to do segment routing, or this solution there are three
       areas that break out  that come out and must be considered: 
       - Flow type information in the mapping system
       - Flow type information in term of the map that has been
       required
       - Path information
       If you can separate them you combine them for the different use
       cases.
           
Albert Cabellos => Yes.

Luigi Iannone => I have a comment about the suggested Publish/Subscribe
      mechanism. I think we somehow have it already. If an ITR register a
       mapping, then it is publishing it. If an ETR request a mapping
      then it is subscribing to the mapping. If something changes, we
      have several mechanism to send a notification saying "something
      has changed please retrieve the new mapping". May be is not
      enough but you need to spell out why is it not enough in your
      context.

Albert Cabellos => True. But in this context you are chaining services
       and you can have recursive ELPs so if you want to operate
       quickly it may happen that you do not know your peers so things
       can be slow. That is why we thought about a simple mechanism to
       which once you subscribe if anything changes you receive the
       updates directly. But I agree we need to describe in which
       specific case we need this.  

Michiel Blokzijl =>  SDN means a lot of things to different
	persons. Looking at you presentation a more suitable name
	would be NFC for LISP or LISP for NFC.

Fabio Maino => We do not need names. WE are just learning from the SDN
      applications, mainly with the open source implementation in
      OpenDayLight. In this draft we are just highlighting the
      requirements, if we want to change the name there is plenty of
      time.

Joel Halpern => With that we are done on time.

[Session closed]
=================================================