Minutes IETF101: lisp
minutes-101-lisp-02

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: It does it makes sense to list these documents in the intro?
Luigi: The new bis documents? Not sure how much you do this doc in rfc editor
queue for 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 proof read the bis documents and then lisp sec
pushed right behind.

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

Luigi: depends they 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 draft did not go through
technical discussion and need to go through the whole process. Albert: all
three then we need to work on OAM document. Luigi: if we agree the bis doc are
ready we can last call for these 2 but the OAM we need to have a call for
adoption on OAM draft.

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 freelancing the introduction that says lisp
 is defined in dataplane with  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  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 dataplane
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 … Joel: you do not have to set expectations that what mobility may be
handled by lisp… Dino: People should read the section before making this
decision because there was a lot of 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 SP mobility is an event that happens may
be once a year versus being in a high speed train and changing your outlooks …
so people need to know that lisp is trying to solve the train problem and like
the multihoming document is trying to solve a SP 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 dataplane 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 end of the week decision..

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

Dino: If the encapsulation types returned by the ETR all the data planes
supported by it .well 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
dataplanes 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 be take an inventory of all the popular dataplanes like…
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: TCP vs UDP and not familiar how that works with LISP. When using UDP is
there some sort of state that says which map servers might send you a map
notifier. 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
very the map notify for public key to  verify,
 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 Security has been 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 may be 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 introduce 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: Rhythms of 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 changes. 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
packets 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: s 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. Dino … 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 precious 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 comments please take it offline

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