Skip to main content

Minutes IETF101: lisp
minutes-101-lisp-01

The information below is for an old version of the document.
Meeting Minutes Locator/ID Separation Protocol (lisp) WG Snapshot
Date and time 2018-03-19 13:30
Title Minutes IETF101: lisp
State Active
Other versions plain text
Last updated 2018-04-13

minutes-101-lisp-01
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.
Ê
Ê
Ê