Minutes IETF101: lisp
minutes-101-lisp-04

Meeting Minutes Locator/ID Separation Protocol (lisp) WG
Title Minutes IETF101: lisp
State Active
Other versions plain text
Last updated 2018-04-17

Meeting Minutes
minutes-101-lisp

   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.