WG: Locator/Identifier Seperation Protocol
================

Chairs:
====

Joel Halpern
Terry Manderson

Secretaries:
============
Wassim Haddad
Luigi Iannone



Joel starting the meeting:
------------------------------

    
Agenda bashing:

--> Darrel Lewis: wise to collapse the draft updates into one agenda item?

--> Joel Halpern: Any objection in the room 

No objection!


Agenda is now open for updates (30 min for all the WG drafts)


Darrel Lewis presenting:
----------------------------

- draft-iet-lisp-06
- draft-ietf-lisp-alt-03
- draft-ietf-lisp-interworking-01 (ready too late for cut-off date, will be submitted later)
    
--> Fred Templin (on fragmentation issue): what you will do if ICMP messages get lost?

--> Darrel Lewis: It breaks
    
--> Sam Hartman: this is one big issue in IPsec deployment (break if you rely on ICMP messages to avoid reassembly). I have done an analysis to see what to do and I am not aware of any work on path MTU
discovery that works.
    
--> Fred Templin: If you blackhole messages, SEAL can help obviously: need to consider a stateless version (?). It does not reassemble on the ETR

--> Joel Halpern (after update on draft-ietf-lisp-06): Any general comment?

--> Joel Halpern: Dimitri Papadimitriou has reviewed draft-ietf-lisp-06. The comments will be sent on  the mailinglist.

2nd draft: draft-ietf-lisp-alt (Darrel Lewis presenting)

--> Vince Fuller: what this means is that a box doing aggregation EIDs prefixes across a hole has to understand LISP protocol and cannot be only an off the shelf BGP box.
    
3rd draft: draft-ietf-lisp-interworking (still Darrel Lewis)
    
    Done!
    
--> Sriram Kotikapaludi (NIST): when you send exceptions for EID prefix coverage, do they all go in one message or in separate message?

--> Darrel Lewis: yes one message. map reply contains all locator records in one message (i.e., all negative replies).
    
--> Sriram Kotikapaludi: any performance penalty in this case?

--> Dino Farinacci: It is a trade-off between mapping and storing (map request load vs. memory on the ITR)
    
--> Sriram Kotikapaludi: just wondering if it makes sense to split them in multiple messages after the first packet is dealt with.

--> Darrel Lewis: There will be a problem with implementation if you do that: if we split the replies and the nonce is cleared after the first packet is validated then it won’t be able to check the validity of subsequent replies.
    
--> Joel Halpern: the other obvious implementation risk is if the 2nd packet is lost then how do we recover? If the process takes too long we can fix it later.
    

Dino Farinacci presenting: draft-ietf-lisp-multicast-02
---------------------------------------------------------------

Done for today! 


Move to the next session agenda:
    
--> Joel Halpern: concerning the security analysis:

--> Luigi Iannone: started to work on one draft: what we should do?
    
--> Joel Halpern: get several drafts, then we can figure out whether we should address them in the main document or we need other drafts to address them

--> Sam Hartman: we seemed to be working on different parts of the problem but we’ll need to merge at some point in time. I am more interested in having the info written down first.
    
--> Joel Halpern: none of the security issue will be swept under the carpet. Every problem will be written down but not all will be solved (to be figured out)

--> Joel Halpern: Someone will/should write a deployment document because I received many questions on how to deploy LISP (confusion) 

--> Dave Meyer: amend charter to make space for such document (i.e., become a WG)?
    
--> Joel Halpern: It depends on the progress and the document. Jari and the WG will decide
    
--> Sam Hartman: It is in the charter! There is already material available from the last meeting.
    
--> Joel Halpern: OK then we can use it as a hook
    
--> Jari Arkko: document will be beneficial and if it is not in the charter then we can fix it. I’d like to see it.
    
--> Jari Arkko: the other thing is about addressing security issues and not others. We should see what things are threats that need to be addressed.


    Material for the 2nd session:
    
Dino Farinacci presenting: How to send Map-Replies:

--> Isidor Kouvelas: The problem is when ITR is v6 only while ETR ETR has both v4 and v6 and does not know that it does not have to reply using v4.

--> Sam Hartman: I raised this issue before!

--> Joel Halpern: v6 map reply can only happen on the 3rd alternative

--> Wes George: question from Jabber: can someone post the slides?

--> Joel Halpern: I won’t get them posted during this session unfortunately. Just got them an hour ago

--> Sam Hartman: This is an issue that comes back to Joel's comment during the last meeting on whether map-requests should be encapsulated or not. Do we really need packet changes?
That question is still an open issue. Better not to do this change and
later on choose to not encapsulate. 

--> Dino Farinacci: the two issues are orthogonal
    
--> Sam Hartman: does not agree. This problem can arise in the core architecture when 2 (v4 and v6) addresses are in the map-request and you have only v6 addresses. You cannot solve the problem. 

--> Dino Farinacci: This is explained in the next slide and has nothing to do with packet encapsulation.

--> Sam Hartman: Changes to the packet are no orthogonal.

--> Joel Halpern: couple of comments: there are similarities in the change that are proposed. On the issue of arch change: I can't push for change while sitting here!
Otherwise, there were two of us (or three) who want it. If people think there is an issue we should solve then we'll start a discussion on it but I can't keep pushing it...

--> Sam Hartman: It seems to me that people ignored the message you sent on the list.

--> Joel Halpern: I am not asking you to do more. People that think this is an issue should speak by themselves. Let's take it back to the list. But
conceptional, these are still different problems.
        
--> Dino Farinacci: bringing Joel architecture thing is orthogonal
        
--> Hannu Flink: want to check my understanding: Map-replies relays information from ETR to ITR avoiding the mapping system, isn't an issue?

--> Dino Farinacci: no
    
back to the slides (Dino speaking again)
    
--> Sam Hartman (on the proposed changes to Map-Replies): why do you need more than two bits? Why not only two possible addresses?

--> Dino Farinacci: possibibly don’t but we want to anticipate more than two address families.

--> Sam Hartman: reducing the number of variable fields is an issue. Allowing only two addresses should be enough and make the implementation simpler. Unless, we have a compelling reason I think we don’t need more than two.
I don't really care!
    
--> Luigi Iannone: I don't see the implementation issue here. Looks clean in my opinion
        

Hannu Flink presenting: Membership test to complement the mapping system:
    
--> Joel Halpern: step 4 on the left: is it important to send the first packet to the RLOC?

--> Hannu Flink: No… Just to circumvent drop and buffering

--> Joel Halpern: for the 1000 EIDs site, use 4K response?

--> Hannu Flink: Yes
    
--> Dino Farinacci: run the BF across the 1000 EID values? 

--> Hannu Flink: Yes, this is the flat case. 

--> Dino Farinacci: Don't know about performance

--> Joel Halpern: can you elaborate why the false positive is similar to stale mapping?

--> Hannu Flink: you’re right. But if you look at the sequence of messages exchange => it is the same protocol sequence.

--> Joel Halpern: any other topics to raise today? 

Session 2 Wednesday 24th March (135 Min)



Administration  

- Jabber Scribe(s): Darell Lewis
- Blue Sheets

Agenda Bashing                                          
Presentation and Note well


5 presentations scheduled:

Dino Farinacci: LISP Instance IDs
Dino Farinacci Presenting: Version Hashing
Luigi Iannone: LISP Mapping Versioning 
Sriram Kotikapaludi Presenting: Enhanced Efficiency of Mapping 
Fangwei Hu presenting: LISP with MPLS



Dino Farinacci Presenting: LISP Instance IDs
--------------------------------------------

--> Joel Halpern: Could you use the same or different ALT instances with different I-bit instances?

--> Dino Farinacci: This is possible, I am not sure whether we can use the same one. However this bit is very useful in Data Centers.

--> Joel Halpern: We need to add text with the procedural description of how this bit is exactly used.

--> Luigi Iannone: If the I-bit is set does it goes in every single packet?

--> Dino Farinacci: Yes.


Dino Farinacci Presenting: Version Hashing
------------------------------------------

--> Luigi Iannone: The problem of synchronization goes beyond the version number. My opinion is that it should be documented somewhere (i.e., what happens when there is a lack of sync).

--> Dino Farinacci: We think that synchronization is decoupled from this proposal and should be addressed separately.

--> Margaret Wasserman: In the first slide you said that this applies only to proxy ITR.

--> Dino Farinacci: It is more important there but it is not the only case. You can use it in ITR and ETR as well.

--> Margaret Wasserman: This includes the square case, the one with two unidirectional flows between two sites, as well.

--> Dino Farinacci: Yes.

--> Darell Lewis: This also includes when ITR and ETR functionalities are split on different boxes.

--> Dino Farinacci: Agreed.


Luigi Iannone: LISP Mapping Versioning 
---------------------------------------
(draft-iannone-lisp-mapping-versioning-01.txt)

--> Joel Halpern: There are many situations where one side or the other is waiting for the other to communicate. You need other mechanisms to solve this issue.

--> Luigi Iannone: I never claimed this is solving all the problems.

--> Dino Farinacci: Joel, you mean that this solution should fix the problem as well or it is another solution?

--> Joel Halpern: Mobility is out of scope if we want to solve this problem.

--> Luigi Iannone: Mobility is not in the charter but this model works better than hashing.

--> Joel Halpern: Is this the only case of mismatching?

--> Luigi Iannone: Not necessarily this one. There are several scenarios where you can imagine this desynchronization.

--> Srini Subramanian: It could happen that the new version number is wrong, how to deal with that case?

--> Luigi Iannone: You can either ask the ETR directly or go through the mapping system. When you have a new version number, you can go through the mapping system and if the mapping system is broken then you better unplug your computer.

--> Joel Halpern: We can do nothing, version hashing or version numbering. 

--> Joel Halpern: Do you have any preferences about this?

--> Dimitri Papadimitrou: I prefer Luigi's versioning solution.

--> Dino Farinacci: I prefer Luigi's solution too.

--> Joel Halpern: Interesting!

--> Dino Farinacci: There is one advantage and one disadvantage of 
version numbering over version hashing. And the advantage is 
beneficial if we can bear the cost of the disadvantage. And my gut 
feel was we *could* bear the cost of the disadvantage.

The advantage was that you get version ordering or sequencing so you 
could tell which mapping was more current. The disadvantage is that 
you have to configure the version number for each database-mapping for 
each xTR at a site.

I think the disadvantage is a reasonable cost to get the advantage. 
But the implementation could screw this up so we need to provide 
suggestions in the map-versioning draft.

--> Joel Halpern: So we need to propose text on the mailing list. Luigi, you seem to be the most adequate person to do it.

--> Luigi Iannone: Sure. I can do that.


Sriram Kotikapaludi Presenting: Enhanced Efficiency of Mapping Distribution Protocols
---------------------------------------------------------------

--> Darell Lewis: There is an action bit in the Map-Reply.

--> Joel Halpern: (concerning slide 3) Why we need to advertise all of the de-aggregated prefixes?

--> Sriram Kotikapaludi: This is a Patricia Tree so you need to de-aggregate and announce everything.

--> Dino Farinacci: (concerning slide 3) This is not a nasty situation, you don't need to de-aggregate but the problem has merit.

--> Jesper Skriver: (concerning slide 3) You expand only if you do not allow overlapping, but the problem is what ETR of AS10886 doesn't know of the other.

--> Joel Halpern: What's the difference between a /20 and a /24, why not send back directly the /24 instead of the /20 with the holes?

--> Dino Farinacci: In that case the ETR should not reply with the /20

--> Joel Halpern: This is the same behavior like replying with /24 directly

--> Dino Farinacci: It depends on what you advertise in the ALT.

--> Joel Halpern: I don't see the difference, better to let's go to the list.

--> Darell Lewis: The only difference that I see is that it may take longer.

--> Sriram Kotikapaludi: In this way you cover more prefixes.

--> Dino Farinacci: So you store the mapping but count for more specific.

--> Joel Halpern: How to know whether or not to send the request?

--> Dino Farinacci: We can get away encapsulating to that locator set, the mask tells you what to store.

--> Sriram Kotikapaludi: Version can help in detecting the change that triggers a new Map-request.

--> Dimitri papadimitriou: How does this works with 20% holes, 30% holes, etc.? You are driven by the traffic to discover the holes. This can be non efficient.

--> Sriram Kotikapaludi: 90% is not used to discover the hole. The percentage does not matter.

--> Dino Farinacci: We have a tradeoff between the information you put in replies and latency.

--> Joel Halpern: let's take it to the list.

--> Damien Saucez (jabber): What's the gain? It depends on the distribution of the traffic. What will we have in reality?

--> Sriram Kotikapaludi: I agree that there is overhead.


Fangwei Hu presenting: LISP with MPLS
--------------------------------------

(draft-hu-lisp-mpls-trans-00.txt)

--> Dave Meyer: The ingress TE and Provider Lockin issues are back with this solution.

--> Dino Farinacci: In your case the ITR and the PE is in the same box?

--> Fangwei Hu: In scenario of slide 5, yes.

--> Dino Farinacci: What if site 2 is in a different MPLS domain?

--> Fangwei Hu: We do not consider this case in this scenario.

--> Dino Farinacci: You say that LISP encapsulation plus MPLS encapsulation is not a good thing. In my opinion it is good because it is deployable.

--> Darell Lewis: (from the jabber) In slide 6, what about the checksum?

--> Joel Halpern: This argument has a lot more people involved and I am not asking the presenter. Other questions?

Nothing from the room.

--> Joel Halpern: This concludes the session, see you in Maastricht.