Minutes IETF101: lisp
minutes-101-lisp-04

LISP WG IETF 101

Monday, March 18, 2018
13:30 - 15:30, Afternoon Session I, 120 Minutes
Room: Palace C

- Agenda Bashing

WG Updates and Presentation of Agenda by Luigi and Joel
Comments:
Albert: Does it makes sense to list the bis documents in the intro?
Luigi: The new bis documents? Not sure how much you can do, this doc in RFC
editor queue and missing a single reference.

Dino: Question about the bis documents? There was no mention about the
LISP-Sec document and that seems to be the only reference document that the
introduction document is waiting on.

Luigi: We discussed this already last time we took the document back. The basic
idea is we switch it to standard track but we need to make sure it is coherent with
the bis documents. LISP-Sec will reference the bis documents. My point of view if
we did a good job. We just proof read the bis documents and then LISP-Sec will
be pushed right behind.

Dino: Do you think the bis doc will move fast?

Luigi: Depends. The IESG may be overloaded.

Joel: Changing a reference in a doc means pulling a text which means the doc
has to go back to working group last call, ietf last call, iesg approval ? it is the
procedure.

- WG Items Presentations
 - Update on LISP 6830bis & 6833bis & OAM
  draft-ietf-lisp-6830bis
  draft-ietf-lisp-6833bis
  Dino Farinacci & Albert Cabellos

Albert: Presented that the 6830bis draft that went through 5 iterations since
IETF100 meeting. Then went over the different changes. 6833bis went through 3
iterations.

Discussion on 6830bis section on Mobility, Deployment and Traceroute
considerations removal and to be placed in a new OAM document.

Luigi: Have a quick question about the OAM document, when do you plan to do
it?

Dino: Are you going to push the OAM document at the same time as the bis
documents? Will it not slow these down?

Luigi: No, it will not. OAM text did not go raise technical discussion but it needs to
go through the whole process.

Albert: Agreed then we need to work on OAM document.

Luigi: If we agree the bis doc are ready we can last call these 2. But for OAM we
need to have a call for adoption.

Discussion on extracting the OAM portion.

Albert: It is difficult to extract the OAM section. If we remove the consideration
sec and it will be out of context.

Luigi: For me it is quite simple, just add an introduction that says LISP data plane
is defined in 6830bis and control plane 6833bis. All the administration and
management is in this document. The reader is supposed to be familiar with the
other docs.

Albert: Then I have a problem regarding the reader considering the title. If I have
a LISP OAM document, I expect to have the whole spectrum of what it means for
operation and management of LISP. Then I find the three sections very narrow
regarding 3 different aspects. We can do that but then the title should not be
OAM.

Dino: I agree with Albert 100% and it is hard to decide whether these sections
are really OAM or not. Traceroute probably yes bit putting the mobility section
there is totally counter intuitive. I would suggest to put the mobility section back in
the dataplane document as it is a general problem.

Luigi: If I want to look up mobility I would never go look in a data plane document.

Dino: If you want a general mobility description, you will not look into the OAM
document but may be in the introduction document. Makes more sense in the
data plane document because it is about XTR that?s moving around and it is a
general discussion that it sets up for LISP mobile node and EID mobility.

Joel: Wonder whether we need the text at all ? If you are just laying groundwork
for the actual mobile solutions, is  it actually providing any change in the
normative behavior?

Dino: It is setting expectations of what mobility is.

Joel: You do not have to set expectations of what mobility may be handled by
LISP.

Dino: People should read the section before making this decision because there
was a lot of thought put into that text and we should not lose it. People have
different expectations of what is mobility is changing. For example, for ISP
mobility is an event that happens may be once a year versus being in a high-
speed train and changing your RLOCs, so people need to know that LISP is
trying to solve the train problem and like the multihoming document is trying to
solve a ISP problem.

Luigi: I agree but no one wants to lose the text. May be there is no perfect
solution but I would not put mobility in the data plane document. I am not
shocked using OAM in the title. Let me think about it.

Dino: We should ask the working group about the title.

Luigi: Sure

Fabio: Proposal for title LISP deployment consideration, mobility, OAM.

Albert: If we agree on change of title I volunteer to write that.

Luigi will send email to mailing list and that there are concerns about title and
have a decision by the end of the week.

- LISP Generic Protocol Extension - draft-ietf-lisp-gpe-01.txt
  5 minutes (Cumulative Time: 25 Minutes)
  Fabio Maino / Alberto Rodriguez-Natal

Fabio: Mostly editorial changes and one technical comment in section 4 on
Backward compatibility. Will apply the same logic as the LISP Crypto draft.
Next steps are to allocate the new g-bit and update the IANA consideration
sections and propose for last call.

Discussion about the language to describe the backward compatibility section 4.

Luigi: Clarification question .. with this ?g? bit now you have way to find out
whether there is support or not of GPE. Assuming there is no support like in
legacy LISP how do you deal with nonce and versioning? Do you want to keep it
the way it is?

Fabio: Yes.

Dino: If the encapsulation types returned by the ETR are all the data planes
supported by it all those bits will be set. So you do not have to say if the g bit is
not set and if that encapsulation type comes from any other data planes you
don?t have to say use the default. The only time you have to use the default is
when 6830 is LCAF is not returned and you have no information about any
dataplane except the default.

Joel: Or presumably when there is no match between each point.

Dino: Good points we may be check if the text covers that. Should we take an
inventory of all the popular data-planes.

Fabio: Each individual draft proposing a different dataplane will have to take care
of this one GPE is doing that. There is an ILA draft and may be it should do that

Dino: I am wondering we need to change the LCAF documents and may be we
want to change it only once. Each use case go and ask for a bit and do we need
to keep there and the LCAF document does not specify the bit.

Luigi: Suggest every document request the bits and we must make sure there is
no conflict. Document is small. Ask the room to hum on readiness of the
document?
Room : Agree that the document is ready for last call.

- LISP YANG Model - draft-ietf-lisp-yang-07.txt
  Reshad Rahman / Alberto Rodriguez-Natal

Reshad: Minor changes to comply to rfc7087bis draft
Present the changes in the next revision.


- LISP Vendor Specific LCAF - draft-ietf-lisp-vendor-lcaf-01.txt
  Fabio Maino / Alberto Rodriguez-Natal

Alberto: Request to move to last call.

Luigi: Comments per his review ? 3 editorial comments and no technical
comments before requesting last call.

Asked room to hum
Room: Agreed ? consensus to move to last call

o Non WG Items

- Publish/Subscribe Functionality for LISP - draft-rodrigueznatal-lisp-pubsub-
01.txt
  5 minutes (Cumulative Time: 40 Minutes)
  Fabio Maino / Alberto Rodriguez-Natal

Alberto: Request for a wg doc.

Fabio: This draft is driving the other features

Luigi: Ask the room for hum ? positive for moving to wg doc

- MS-originated SMRs - draft-rodrigueznatal-lisp-ms-smr-04.txt
  10 minutes (Cumulative Time: 65 Minutes)
  Alberto Rodriguez-Natal

Alberto: Request for move to Informational status

Authors request advice on what is the best way to move forward.

Luigi: One possibility, push it as an individual solution.

Dino: Does the document suggest that this is an experiment and suggest to use
pub-sub.

Alberto: We can add that.

Joel: There are some implicit assumptions in the draft that need to be explicit and
some other things addressed. The WG can consider to publish this as in
informational RFC once those are fixed

- LISP control-plane for Identifier Locator Addressing (ILA) - draft-rodrigueznatal-
ila-lisp-00.txt
  15 minutes (Cumulative Time: 55 Minutes)
  Fabio Maino / Alberto Rodriguez-Natal

Alberto: LISP can be used as control plane on a ILA dataplane without changes
in ILA or LISP.

Tom: On TCP vs UDP, I am not familiar how that works with LISP. When using
UDP is there some sort of state that says which Map-Server might send you a
Map-Notify. Do you accept any Map-Notify there should be some sort of security
right? With TCP you just have connections open to map servers I wish to us.

Dino: Tom has a requirement to run ILAMP to run TLS over TCP. To care about
a mapping therefore any map server can give you a map notify. A map notify is
sent with unique nonce but there is no authentication of it right now. We can
extend the ECDC draft to say that Map-Notify can be signed and receiver can
verify the Map-Notify with the public key.
Tom: So UDP is the predominant use case today or TCP?

Albert: Depends on use case.

Tom: For ILA redirects there is a need  for security and TCP has that benefit.
Also upping the whole control plane like a data center type of API controlled
protocol as opposed to a low level routing protocol. Concerned about the
security.

Alberto: good feedback.

Dino: For the WG, if we have rest interfaces does the WG have to specify how
the API is used? Has nothing to do with IETF and not sure if IETF gets involved
in defining those.

Tom: LISP control plane fairly complete if we could get that over rest that would
be quite helpful.

Alberto: Today we have both TCP and UCP in deployment scenarios.

??: what is the driver for TCP? Was the size of the mapping, if the mapping is big
rather than having many UDP requests, TCP makes it a bit more reliable.

Tom: Been looking at the size of LISP mapping maybe we can compress that a
bit.

Kalyani: My comments are relating to the mapping system in the 5G system.
3gpp is working on APIs. If the mapping system need to be used in the 5G
system, the frame would be introducing in 3GPP.

Fabio: Following up on what kalyani is saying this will be discussed in DMM.
There should be one control plane and multiple data plane and this is the reason
for this draft.

Reshad: Isn?t the issue that you have netconf and restconf and you have a yang
model which is standardized. The job is done or do you need anything more?

Padma: Follow up on what kalyani mentioned earlier on the placement of the
mapping system in the 5G system. I would encourage you guys to  look at the
document we have published in another SDO that actually explains very clearly
all the interactions between the 5G architecture functions with the mapping
system.  I want to discuss with all of you guys so that this work can be leveraged.
It would be good to reference it here.

Luigi: Why don?t you send a pointer on the mailing list where we can find the
document.
Padma: Sure

Tom: On applicability, I agree it would be nice to have one mapping system that
could cover all use cases. One thing though if we are using a mapping system
within a closed network vs a public mobile network, privacy and security is very
different
I think I raised this issue on the list. Especially denial of service is a tricky one.
We know whenever we need to cache, most mapping systems will be a target.
These are the things to consider for the broad use case.

Alberto: This is something we are aware and actively looking into ad we have
discussed different options.

Albert: Concerning DDOS attack to the control plane, we have worked on
solutions in the past for that and we are planning to release a document
explaining how we can solve that. You will see all the details but to me the main
point is that these types of infrastructure are very common and many solutions
around.

Dino: Since you may subscribe to info that spread across thousands of map
servers they don?t need to send you a notification themselves each time a
notification change. At that time if you have a TCP connection established you
have a 3-way handshake, otherwise delay will cause convergence problems.
Because that means that every map server has TCP connections to everybody
together in the internet that is not a scalable solution even though large DC have
thousand of TCP connections ? this is a different order of magnitude.


- Ground-Based LISP for the Aeronautical Telecommunications Network - draft-
haindl-lisp-gb-atn-00.txt
Reshad Rahman / Victor Moreno

Reshad: Update on the ICAO meeting.
Main difference found by evaluation was there is an initial packet loss with lisp
and there was none with AERO.

Fabio: Initial packet loss is a well-known behavior in LISP and there are
mitigation with use of RTR

Luigi: Regarding initial packet loss is something we can avoid.

Dino: An implementation can decide to mitigate and if it is important you can
make it such that it does not drop.

Luigi: Years ago we said that this is implementation.

Dino: May be the specs do it but specs don?t. It is not a must we can do
something else

Erik: I know of an implementation that is not open sourced yet but it does keep a
packet for a while. You don?t to keep it forever but it does keep it for a limited
time

Reshad: from what we know it is not a big throughput so that seems feasible.

Luigi: If this is a private network we can choose to keep. The reason we drop is
not to fill the buffer of the queuing but if this cannot happen then it is reality safe
to save them.

Reshad: it is supposed to be a closed network but there are several networks ?
American, European? so it not a simple flat network.

Victor: I would really encourage the WG to have read and you will find
implications of the pub/sub here on regional network on mobility and how you
would that best or some proposal on the draft but it is not necessarily using
things like DDT so there is a lot of thinking that can go into this.

- A Simple BGP-based Mobile Routing System for the Aeronautical
Telecommunications Network - draft-templin-atn-bgp-06.txt
  Fred Templin

 Main architectural change is the AERO proxy which sits at the datalink sub
network border and acts the same as for an enterprise network web proxy so
inside the sub network the client airplane interacts with the proxy in the same
way it would interact with a server in the outside world.


- A Decent LISP Mapping System (LISP-Decent) - draft-farinacci-lisp-decent-
00.txt
    Dino Farinacci / Colin Cantrell

Comments:
??: do you use unicast instead of multicast for the requests?

Dino: The problem is if you are in a situation where you have the Internet but you
need to auto discovery each because XTRs will be added and deleted. By using
unicast there is no way you can auto discover. Usually for discovery we use
multicast or directory services and if you use directory services you are
depending on a third party. There are solution but you will need to preconfigure.
We want this to be like a crypto currency where everything is pretty self-
discovering peer to peer. We are basically buying applications from the crypto
currency world and trying to apply it here. May look like a routing protocol but it is
not because it is over the top.. just multicasting things with efficient distribution.

Tom: so  when you are talking about multicast you actually talking about really a
multicast group.

Dino: XTR join Class D addresses or FF::/8 .. so the multicast service model is
available for this control plane.

Tom: My impression is that multicast may or may not be available in most
networks. I work in 2 really large providers networks and I know a lot of provider
networks do not have multicast.

Dino: If the underlay does not do multicast we can do head end replication.

Tom: So why not just sent it to one and let the head end replication do the rest

Dino: Because you don?t know who to send it to, the whole point of accessing the
mapping system to send you a Map-Register is that I do not know your RLOC.
And I need to access the MS to know your RLOC. If unreliable you send them
periodically or add a reliable multicast protocol on this

Joel: But you start piling complications. I can understand this is a small case or
moderately small case of common things which want to use LISP and which are
all on a common fabric which supports multicast so that all the scaling properties
and benefits work. But as a general mechanism it looks like it will need so many
complexities by the time you are done for the general deployment case.

Dino: I am not telling it is a general mechanism and I can show you the use
cases we are targeting.

Joel: But the draft does not tell you the use cases you are talking about.

Luigi: How do you discover the multicast group you have to join

Dino: That?s configurable.

Joel: if you configure that you can configure other things as well. One xTR
running all the time and give you its address.

Dino: You do not know which xTR is on your side of the partition you might as
well statically configure all the RLOC and map cache entries and not even run a
MS.
But if they move around and change their RLOCs you may have loops. So that?s
why you need multicast for the dynamic discovery.
Joel: There is no authenticated delegation. You can authenticate participation but
you cannot authenticate delegation.

Dino: So, you use our EDCSA draft, the instance ID is part of the signature

Joel: That is a different approach from authenticated delegation.

Luigi: Then you need to know the multicast group to join but also all the public
key of everyone who will potentially join. Am I wrong?

Dino: You do and the public keys are registered they do not have to be
authenticated. Registering a public key is harmless but using it and what you are
verifying that signature data is the previous stuff.

Luigi: Goes back to the question of scalability of such a mechanism for big
deployments it is complex.

Albert: On the ?no third-party trust or dependency exist? the way I understand it
you actually have full trust right as you are trusting all participants of multicast
group.

Dino: Exchange of info require some trust but you want to talk to someone who is
giving you the mapping but you can verify that with the signatures right?

Albert: But how do you verify with a signature?

Luigi : For further comments please take it offline

- LISP for the Mobile Network - draft-farinacci-lisp-mobile-network-02.txt
- Not enough time.