[lisp] draft minutes from ietf77

[Terry Manderson <[e-mail]>]

Folks,

The following are the draft minutes from IETF 77 for the two sessions.
Thanks to Luigi and Wassim for preparing them.

If everyone could review them, and email me ASAP with any required
alterations that would be great. I intend to upload them tomorrow evening.

Cheers
Terry

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 Fueller: 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: NoS 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: Let me explain. There is one disadvantage in version
numbering, which is the configuration, but the corset is worth it.

--> 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.