Minutes IETF105: lisp
minutes-105-lisp-00

IET 105
LISP WG Meeting minutes

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

SECRETARY: Padma Pillay-Esnault ( padma.ietf AT gmail.com )

AGENDA

Session 1/1 (120 Minutes)
=-=-=-=-=-=-=-=-=-

Monday, July 22, 2019
13:30 - 15:30, Afternoon Session I, 120 Minutes
Room: Notre Dame

- Administration
    Halpern/Iannone
    - Blue Sheets
    - Agenda Bashing
    - Status reports for WG drafts
        5 Minutes       (Cumulative Time: 5 Minutes)

Luigi:
RFC 8113 this is now in the RFC queue just waiting for a missing reference
Yang model is under review a yang doctor so this is Chris Hopps
and there is a mismatch in the document between the model and the tree.
 Chris will contact you Fabio and to show you the issue sso that this can be
 solved.

 WG Items

- Update on 6830bis/6833bis documents
      - https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-27
      - https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-25
  15 Minutes (Cumulative Time: 20 Minutes)
  Albert Cabellos

Albert presented a summary  of the updates on 6830bis and 6833bis since last
IETF. A new version of each of those documents both in June 2019 was posted so
1 month ago and then hopefully addressed all the comments made by the reviewers.

Changes summarized into four main items: Security , rate limiting, MTU  and
other

Discussion:

 Fabio: Just trying to understand what are the next steps because my
 understanding is that we are waiting for the discuss comment for the latest
 version to be reviewed and I think at this point is only Ben and Mirja.

Debra :I forget myself did you actually send them mails ?
Albert:  yes I did
Debra:  in June ?
Albert: In June yes. I can check it now again
Debra: if you can this week  try to grab them and asked if they had a chance to
look at it. I'll try to remind them - and definitely next week we'll get on or
more because everybody's very busy right before the meetings but we try to get
them to clear them now but if you can get them this week you know that would be
good in case they don't have a follow-up right to talk about it just because

Albert: You are suggesting me to send them a friendly reminder right?
 Debra: Just say you have time to meet this week

Fabio: May be just one additional comment on this GPE I have a set of comments
from Mirja that needs to be applied at document and you know I just didn't take
a chance to do those but I mean they're in the queue so I hope I can do it
shortly after. I would like to keep these in with the review and aligned with
the 6823 bis at 6833 bis.

- LISP-Security (LISP-SEC) - https://tools.ietf.org/html/draft-ietf-lisp-sec-18
  10 Minutes (Cumulative Time: 30 Minutes)
  Fabio Maino

Fabio presented the updates in response to comments from Ben and Med.

Discussion:

Fabio: To be honest I am not completely sure on the status of the LISPsec Draft
at this point because we basically were told by the reviewer that the review of
the Bis RFC's should go together with a review LISP SEC. We have got a bunch of
comments we have incorporated that we received in Prague, I think that the next
step is getting a feedback back from Ben and from the security Directorate.
That's my understanding but we need to figure out how what is actually the next
step É.

Luigi: If you check the data tracker this document is in the last call for two
months. we should clarify you whether or not taking Mountain moving it forward
if the the new person replies to man you know step it up yeah it's ever

Debra: I think it's really good that this is looking stable and I would give it
a heads up then when you say to Ben and reminding him because I found in the
mail. I think all of us want just say that this one's stable now too because
that's what he really wanted . He was not sure the allocation of the different
information.

Fabio:  right it should be in this document or the others so now you can have
this document also to look to say that everything.

Luigi: good yeah in it as far as I remember he was looking for our complete
security solution for  lisp and this was kinda missing piece.

Debra  yeah I will send him the heads-up for early review.

Fabio: exactly that was my understanding again right that what they were really
asking was to basically move forward this document together so that we have a
overall view of lease that applying control plane and security okay cool any
other questions okay thanks

o Non WG Items

- LISP Uberlays - https://tools.ietf.org/html/draft-moreno-lisp-uberlay-01
    20 Minutes (Cumulative Time: 50 Minutes)
    Alberto Rodriguez Natal

Discussion:
Luigi: Basically the uberlay is an overlay it's specific purpose to connect.

Alberto: that is correct

Luigi: okay next question - can I have several uberlays connecting different
site overlays and these uberlays can interconnect between them ?

Alberto:  that is an excellent question., this is actually in the list of next
steps. In the draft right now we consider a single overlay. We have discussed
on what to do with multiple uberlays É. that comes with a different set of
requirements and assumptions that we need to evaluate.  I mean theoretically
yes but we have not addressed that yet on the draft.  So that is on next step
for us but that's a good question.

Dino: It turns out to have multiple uberlays is less desirable than to have
good multi-home connectivity on the underlay that the uberlay realizes because
the uberlay is just there to connect the edge points of the other overlays and
nothing else.  It is not clear that you need separate policy where you need a
separate uberlay  infrastructure to interconnect so that's why we first started
off  that we needed one

Luigi: yeah I understand that you start  with the simple solution but my point
is not that you need several uberlaysÉ. what can happen is it for whatever
reason you have different overlay sites and they decide to interconnect and
deployed at uberlay É so me and you and Alberto and Fabio take we interconnect
pairwise and we use different uberlay but  in the future we want all to
interconnect we become big family okay now what you do?  You deploy a new
unique uberlay or you interconnect the uberlays?

Dino: What you do is you interconnect the site overlays in another mapping
system.

Luigi: the uberlay?

Dino: No I didn't say that I said you connect all the site overlays you take
all their any EIDs and you sent them to a new mapping system and it looks like
a regular overlay rather than to iterate this pattern again.

Albert: I think that LuigiÕs question is that you have two completely separate
uberlays like the picture you have here but two different ones so you have two
overlays connected here to here right. Then at some point you want to bring the
four different sites overlays together and I think that the answer is you will
have is the two uberlays that used to be completely independent each other you
will aggregate so you will end up with a single uberlay that connects the four
site overlays right

Dino: Correct. In other words, you merge the uberlays but that's what I wasn't
suggesting.  I was suggesting it's just one overlay yeah because the EIDs that
are connecting this uberlay have their own local mapping system  .. could
register to a mapping system that's global and it just looks like a regular
LISP overlay as we know it today.

Luigi:  You kill at least one of the uberlay and you keep the other one a
little bit.

Dino: It is not clear as you still need it anyway for the original ...

Luigi: This is something that must be discussed. I think that whatever solution
we end up on the uberlay  É

Alberto: I agree that we are not addressing yet the  use case where you have
multiple overlays. I think that we're kind of saying the same thing here but if
not clear

Fabio: From a practical standpoint ,,, this is coming out of the International
Civil Aviation Organization did by the way as the site. In that case, what I
think will determine what you do is how LISP domains are related . In that
particular case for example the requirement is that there are some LISP domain
that they will not become the same because there may be different providers.
The first level  is trying to put them together with an uberlay yet is exactly
trying to get everybody to talk to each other.  Now  depending on how many
domains and requirements É  you can go to a single overlay or a single uberlay
or maybe to the multiple É

Luigi: I think in the draft the very end  (you should add) if you  don't want
touch these specific points over each case then just state it. For example ,
what we do not consider in this document. Need to say something one way or
another.

Authors request discussion on the mailing list  and  would like to know if the
working groups will take upon this draft and make it a work group item. Authors
invite discussion on next steps points.

Luigi: For clarificationÉ what do you mean by improve state reduction in
uberlay?

Alberto: For instance think that you have multiple ways to register.  (on slide
multi-overlay control plane) these guys kept the borders they need to register
the mappings from the local site overlays into the overlay and you can take
different approaches for that so you can register the mappings as you get them
from the local site or you can try to aggregate as much as possible. If there
are gaps, you need to register the gaps and so on. So we need to discuss which
is the best way to reduce the state you need to release it into the uberlay.

Luigi: Okay. I'm thinking me because if we did a very good job when we have a
massive scalable mapping system you don't need this

Alberto: oh you're talking about the overlay so so that's that's fine

Fabio: I mean if we say for in okay the overlay is gonna run at the planetary
scale but there may be two organizations don't want to use the same .

Alberto: Yes. We can say if you don't want to aggregate anything that you're
gonna really need then a mapping system that is able to scale to a global scale
so that's the kind of considerations that we need to think of.

Luigi: Can you clarify to me know what is the difference between federated and
decentralized?

Dino: In this case ,well the analogy I was going to get us look if you have a
single bgp process that's running with multiple VPNs you can keep the VPNs
separate but they're shared by one process and one routing protocol but if you
ran two bgp routing process that are completely separate it may have a
different period topology altogether that would be the same as using uberlays.

Alberto: The centralized  comes from some the discussion that we are having
with Victor and the iCloud guys. Latest discussion is about how the
organization can deploy its own site in an overlay and then the uberlay is
federated. so that no organization has control over the over the uberlay. Still
under discussionÉ lot of open questions still.

 Luigi: There is some work to do on this document. Still need much discussion
 on the mailing list if we want to go for the adoption.  Should define what is
 missing  and discuss on the mailing list.

 Albert: okay we need to agree though on the scope of the draft and what it is
 not going to address.

Luigi: otherwise I don't think there is any specific issue in should be covered

- LTR: A LISP Traceroute Tool -
https://github.com/farinacci/lispers.net/blob/master/docs/ltr.pdf
  15 Minutes (Cumulative Time: 65 Minutes)
  Dino Farinacci

Dino Presented a demo of the tool.

Discussion:

Albert I guess that you infer that there is a map catch miss because you send a
packet with a larger TTL and you don't see any next hope or know that this has

Dino: nothing to do with the original traceroute so  itdoesn't use TTL
mechanisms at all . Since it's not written up in a draft there's their source
that you can look at. É.

Albert: Do you have any plans to specify protocol that you need in order to
implement that because I understand that this doesn't work with a standard LISP.

Dino: Right it would not.  It's absolutely true that the forwarding
implementation has to change to understand the trace. We can certainly write a
draft if the working groups interested in it. If it's useful should we write a
draft.

Prakash ???

Dino: It knows the number of hops.and there is another tool called LOC8tr that
t can be used in conjunction.  Possibility of using both tools in conjunction.

Open discussion on possible uses and integration of this tool and what
information is useful.

- LISP Mobile Node - Demo
  15 Minutes (Cumulative Time: 80 Minutes)
  Dino Farinacci

Discussion:

Luigi: Clarification you have LISP mobile node on your iPhone as you do not
like in Montreal your iPhone is pointing to which PETR?

Dino: will show in the demoÉ  it did work when I was in when I was sitting in
Montreal .it worked on the cellular network

Luigi: how do you change it because basically you may have a long stretch in
the in the passage it's always the same PETR, I mean if it's your own then your
traffic is going back to California you know even if you are connecting to
something that is here.

Dino:  Yes. I already experimented where that was very interesting the RTT is
doubled yes.

Dino: You mean should the PETRs should be dynamically learned based on your
physical location?

Luigi: Yes. This could be an issue  so we have we have to think about this. 
I'm not asking for our solution for now. Another thing RTRs are configured by
gleaning É

Dino: RTRs are not configured by gleaning.  The XTRs are gleaned and the RTRs
have a command saying glean the information from us É

Joel: We have the document says not to do that É
Dino: The document says not to do that in public domain. This a demo Éthis is
not an RFC.

Luigi: my point is that we have to keep this in mind because if you want to
move to the document forward. We cannot have the basic specs that say you
should not use this and another document is technology is based on something
you should not use .

Dino: I understand your point but we're not violating anything so far

Fabio, Luigi, Albert: É. Open discussion on gleaning , lisp document and real
use case deployment.

Dino ÉMobile node document  it just assumes they're in this pristine
environment which is not the Internet where theRLOCs that the mobile nodes
registering are all in global space.  So I mean a lot of these documents don't
reflect reality.

DemoÉ.
Caveats discussed:
- Lisp Mobile mode must send before it can receive
- Latency exists to learn LISP-MN when it is discovered
-Asymmetry problem
Todo List  next

Discussion:
??: Does Rloc Probing cause scalability issues in the network?
Dino: Certainly less is better so not doing it is better than doing it. Apple
does a good job of testing the Wi-Fi signal and if it's not good it
automatically switches to LTE to give you some better performance. Should we be
smart enough to know that the PETR aren't doing well with rloc probing which
may be your point and maybe turn it off and then try to go native. But then you
lose a session survivability multihoming because the network connectivity isn't
good.  I found that here a little bit too by roaming around was stuff wasn't
working I'm going what's going on and it's the ietf hotel Wi-Fi network that's
kind of bad so this is a great environment I'm gonna be doing testing in fact
I'm going to be testing all this week if anybody sees me walking around and
they want a quick demo right there I just have to pull out my wallet and boom
or pull out my phone I could show you. Your point is taken should you just RLOC
probe a few of them versus all of them because there's all those phones are
going to be our look probing the same ones but I have a feeling we're going to
have location-aware deployment to solve the Luigi problem . So maybe not all
the phones in the world are gonna probe the same for RTRS or the same hundred
RTRS they're going to be local based

??: Exchange of LSP cryto keys?
Dino: I don't know how we're gonna exchange lists crypto keys dynamically
without RLOC probing but unless they're  PSK static or something like.

Luigi:  How do you exchange keys?
Dino: They are public keys it's diffie-hellman exchange it's like TLS does so
it's no different. The private secret keys are built independently.

Luigi: Crypto would be nice to see.
Dino: you think there would be a compelling thing ?

Luigi: I had a second question about multiple multiple IEDs and multi IID. When
I install a new application I have to figure out which key ID to use which IID
to use.

Dino: Defaults to adding that but it could add any type of routes it have to be
destination based. You would have to say anything that so if I'm a cisco
employee anything that goes a Cisco use my VPN now. How to do it seamlessly for
the user  is up to implementation.

Luigi: I have a small question do you need to jailbreak your iPhone to install
this stuff?

Dino: You can download the latest version at the app store so if anybody wants
to try it go ahead and I'll give you the addresses of the RTR actually you
already know them.  So I'm expecting a DOS attack after this [Laughter]

- Distributed Geo-Spatial LISP Blackboard for Automotive -
https://tools.ietf.org/html/draft-barkai-lisp-nexagon-05
  20 Minutes (Cumulative Time: 100 Minutes)
  Sharon Barkai

Discussion:

Fabio: I  want to make a comment on why I think this use case is very
interesting for LISP.  We are seeing a use case where the brings together the
use of mobility with an overlay, the use of the mapping system to map something
not as traditional as PID /RLOC mapping as we have done so far and also that
try to take advantage of the locality of the service offer by the by the market
servers that are that are storing the demand pin itself and then on top of that
using single free multicast to basically reach a featured efficiently all the
devices that are subscribed to a certain information so it's a combination of
use cases that are basically bringing together things that in the last few
years we thought were possible with LISP but what I think is very helpful this
use case here is bringing all together in one you still with a very clean
practical application.

I agree which around that this is specific to this particular use case but I
think is not very hard to think of other use cases that are not related to
vehicle mobility and traffic road conditions that may have similar attributes
right you want to have basic the mapping service that is highly distributed
available at the edge of the network that offers you quasi real-time
information so I think this is very general in many application that we see
coming so that's why I think there is a lot of value in you know working on
this use case and basically trying to see how all the things that we have done
in the LISP working group fit together and it would be interesting to see if
you know there are new things that are needed it's very nice that so far most
of the requirements that Sharon articulated seems to be addressed by what we
have in the overall LISP so this is very useful I think activity for this
working group.

Dino: if we just wanted to publish this as a use case and made it informational
RFC what where are the steps we have to go through does it require the working
group does it not do you have any preferences?

Joel:  The question of how to advance the document turns on a different point
than the IETF procedures in terms of our Charter it's okay we could Publishing
the informational document because this deals with geolocation topics I'm
trying to find out from the geolocation experts here at the IETF how they want
to make sure that appropriate review from the teams who have dealt with these
problems before because this is not a new topic to the IETF then the usage is
new but the general topic of communicating information about geo locations and
such like his one that they've worked on a lot so I want I'm going this week to
talk to some of the people who've been involved with that historically and
figure out a good path because when speaking personally not as chair I like the
work as chair I need to figure out what the best way is to get the appropriate
review and appropriate

Sharon: Just one comment on this it's true it's geo state but the thing here is
that it's a brokered Network meeting.  It is shared state there's not very geo
state

Joel: historically there's been sensitivity when we deal with geographic
information so I want to make sure not that I want to make sure we get the
review and involvement for people have been in that space and I don't care
which working group ends up owning the problem it may be that what we'll do is
ask you to present this material at the ops area group next time or something
I've got to talk to folks I've talked to one of the ops ADs I've talked to some
of the others I've talked to some of the geolocation people who've been
involved turns out Richard Barnes whom I'm on another committee with is very it
was very active in that we'll just will close the loop and find out the best
way to move it forward.

Sharon: On a personal note  appreciate this peer review to keep grilling this
thing.

Joel: We're not gonna throw you out of LISP don't worry .

Dino: Was that a response to making it informational or just any type of work?

Joel: Just whatever type, it looks to me like it it's mostly informational it
needs just to find a new Lcaf but that's all and the Lcaf for registration
procedures would allow that but that's a that's an it in the picture as far as
I'm concerned.