Minutes IETF105: lispminutes-105-lisp-02

Meeting Minutesminutes-105-lisp

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, Chris Hopps, and there is a
mismatch in the document between the model and the tree.
Chris will contact the authors to show the issue so 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,
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. We are waiting for
the discuss comments for the latest version to be reviewed by Ben and Mirja.
Deborah: Did you actually send them mails?
Albert: yes I did.
Deborah: June?
Albert: Yes. I can check it again.
Deborah: If you can this week try to grab them and ask 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. But if you can get them this week, it would be good.
Albert: You are suggesting me to send them a friendly reminder right?
Deborah: Just say you have time to meet this week
Fabio: May be just one additional comment. On GPE I have a set of comments from
Mirja that needs to be applied at document, and I just didn't have a chance to
do those, but 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 6823bis and
6833bis.
- 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 Benjamin Kaduk and
Mohamed (Med) Boucadair.
Discussion:
Fabio: Not completely sure on the status of the LISP-SEC draft. Because we were
told by the reviewers that the review should go together with the review of the
bis documents. A bunch of comments received in Prague have been incorporated.
We think that the next step is getting a feedback back from Ben and from the
security Directorate.
Luigi: If you check the data tracker this document is in the last call for two
months. Clarification is needed on whether or not moving it forward.
Deborah: It's really good that this is stable and I would give it a heads up,
when you say to Ben.
Fabio: So now you can have this document also to complete everything.
Luigi: As far as I remember he was looking for our complete security solution
for LISP and this was kinda missing piece.
Deborah: I will send him the heads-up for early review.
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: Can I have several uberlays connecting different site overlays and these
uberlays can interconnect between them?
Alberto: 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.
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: 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. Let's say me
and you and Alberto and Fabio we interconnect pairwise and we use different
uberlay but in the future we want all to interconnect we become big family.
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, you connect all the site overlays you take all their any EIDs and you
send 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. You will have the two uberlays that
used to be completely independent from each other, now aggregated so you will
end up with a single uberlay that connects the four site overlays.
Dino: Correct, you merge the uberlays but that's what I wasn't suggesting. I
was suggesting it's just one overlay, because the EIDs that are connecting this
uberlay have their own local mapping system and they 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.
Dino: It is not clear, as you still need it anyway for the original reason.
Luigi: This is something that must be discussed in the document.
Alberto: I agree that we are not addressing yet the use case where you have
multiple overlays.
Fabio: This work is coming out of the International Civil Aviation
Organization. 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 it is exactly trying to get everybody to talk to each other.
Depending on how many domains you can go to a single overlay or a single
uberlay or maybe to multiple.
Luigi: I think in the draft needs 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 sites at the border need to register
the mappings from the local site overlays into the uberlay 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. If we did a very good job when we have a massive scalable mapping
system you don't need this.
Alberto: If you're talking about the overlay that's fine.
Fabio: You can have an overlay that is gonna run at the planetary scale but
there may be two organizations don't want to use the same mapping system.
Alberto: Yes. Let's put it this way: 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.
Dino: We can have the analogy with 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 topology altogether that would be
the same as using uberlays.
Luigi: Can you clarify to me know what is the difference between federated and
decentralized?
Alberto: The centralized comes from some the discussion that we are having
with Victor and the cloud 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 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.
Alberto: We need to agree on the scope of the draft and what it is not going
to address.
Luigi: Other than that, I don't think there is any other specific issue that
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 cache miss because you send
a packet with a larger TTL and you don't see any next hop.
Dino: The tool has nothing to do with the original traceroute, so it doesn't
use TTL mechanisms at all. It's not written up in a draft, there's the source
that you can look at.
Albert: Do you have any plans to specify protocol changes 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.
Prakash: Does it understand also the underlay the LISP packet is travelling on?
Dino: It knows the number of hops. There is another tool called LOCator that
can be used in conjunction. I am open for 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 but you do not
live in Montreal, your iPhone is pointing to which PETR?
Dino: Will show in the demo. It did work 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 if
it's always the same PETR, I mean if it's your own then your traffic is going
back to California, 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. You mean should the PETRs should be dynamically learned based on
your physical location?
Luigi: Yes. This could be an issue. We have to think about this. I'm not
asking for a solution for now. Another thing RTRs are configured by gleaning?
Dino: 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.
Luigi: We have to keep this in mind 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.
Dino: Mobile node document just assumes they're in this pristine environment
which is not the Internet where the RLOCs 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
Discussion:
Prakash: Does RLOC Probing cause scalability issues in the network?
Dino: Certainly less is better. 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
multi-homing because the network connectivity isn't good. Your point is taken
should you just RLOC probe a few of them. 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
Prakash: How to exchange of LISP 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.
Luig: 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: 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 that brings together the use of
mobility with an overlay, the use of the mapping system to map something not as
traditional as EID/RLOC mapping as we have done so far and also that tries to
take advantage of the locality of the service offer by the market servers that
are storing the demand itself. Then on top of that, using signal free multicast
to basically reach 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.
I agree 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. You may want to
have a basic mapping service that is highly distributed available at the edge
of the network that offers you quasi real-time information. I think this is
very general in many application that we see coming. That's why I think there
is a lot of value in 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 there are new things that are needed. It's very
nice to see that so far most of the requirements that Sharon articulated seems
to be addressed by what we have in the overall LISP.
Dino: If we just wanted to publish this as a use case and made it informational
RFC what are the steps we have to go through?
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. We may 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. 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. 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.
Sharon: 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 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 next time or something. I've got to talk to folks. I've talked to
one of the ops ADs. It turns out Richard Barnes, whom I'm on another committee
with, was very active in that area.
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 not in the picture as far as I'm
concerned.