Minutes IETF98: lisp
minutes-98-lisp-00

LISP WG Session

1. Administration
    Halpern/Iannone
    - Blue Sheets
    - Agenda Bashing
    - Status reports for WG drafts
        10 Minutes      (Cumulative Time: 10 Minutes)

2. WG Items

2.1 Open session on LISP 6830bis & 6833bis
  draft-ietf-lisp-6830bis
  draft-ietf-lisp-6833bis
  (To be extended if needed)
        15 Minutes      (Cumulative Time: 25 Minutes)

Presentation by A. Cabellos
draft-ietf-lisp-rfc6830bis

Indicate how the instance-ID is 32 bits in control-plane and 24-bits in the
data-plane Removed some references to experimentation Added "Security
Considerations" (summary of RFC7835) Described LCAF registry in "IANA
Considerations" Updated references

draft-ietf-lisp-rfc6833bis
Removed some references to experimentation
Added ACT values:
 4: Drop/Policy-Denied
 5: Drop/Authenticate on-Failure
Removed open-issues and considerations
Other editorial changes

LISP Control-Plane
Assumptions
Which features are required by an arbitrary data-plane (other than LISP) using
the LISP Control-Plane? - Map-Cache (or similar) - Carry two routable
addresses, one in the overlay and another one in the underlay - Mechanism to
monitor RLOC reachability - Mechanisms to notify that a mapping is outdated

Albert would like to have some discussion on these in data plane.

Comments/Questions
Fabio Manio: How is the last 2 points are addressed?
Fabio asked whether this is part of the dataplane encapsulation

Joel: The last 2 points are crucial and today. We cannot ignore these two
things or else we will be blackholing traffic. Has some concerns that today
there is no documentation on the solution.

Fabio: This the right way to put it that if some other DP want to use Lisp CP
then they have to be careful about this.

Erik Nordmark: Are you thinking about this for l3 over l3 encap are you
thinking of other stuff like vxlan as well?

Joel: The point is we know people who want to use vxlan for this. You can use
LISP as is for carrying  L2 traffic. I am not too concerned of the underlining
type of packets as this is a property of the tunnel encapsulation. Not fine it
not recognizing the issue.

Need to check the wording to make sure that this is right.

Albert: yes the wording to be corrected.

3. Non WG Items

3.1 LISP TE - draft-farinacci-lisp-te
        10 Minutes      (Cumulative Time: 35 Minutes)
        D. Farinacci

Dino Asked for this document as a wg doc?

Comments/Questions
Uma Chunduri: Is there any requirement that the itr knows what the lisp encap
is in the middle? Dino: Good question. Assume that there is somebody is 
putting these mappings in the MS DB with these particular ELPs(Explicit Locator
Paths). It could be an eTR, SDN controller or some other management functions.
It should just work regardless of number of AS hops because this is an overlay.

Victor: Clarification on slide 3.
You just put the address in the packet which will be the interface address
receiving the packet. So your encapsulated packet goes through the interface to
the ETR. Dino: That is the rloc address of the RTR Depends on what address is
used in EID. If you use the interface then the packet will arrive accordingly
on specific interface. If the loopback address is used then it will comes
through whatever interface through routing. Victor: here it is suggesting you
are using the router interface. Dino: Really Good question. If x wants to
encapsulate to y and y wants to encapsulate to z, what you are saying is what
would be the source address be? It could use any address but it certainly could
use y as well. May be you should be using y depending if you are trying to do
multicast on some security concerns then may be use the address which is in ELP
to ensure it is the right guy sending to you. Really good comment.

Fabio Maino: Correction on the number of implementations. There are 3 open
sources and 2 different implementations at cisco.

Dino: The NXOS one is most mature one in Cisco. So what do you use as source
address?

Peter Ashwood-Smith: Quick question. Apologize have not read the draft. Can you
talk briefly about any source Entropy and source ECMP? Dino: No different from
any encapsulated packets. The source get chosen and in the UDP encapsulation.
Joel: LISP header always deals with this. LISP encap already use UDP and this
is addressed already by LISP basic mechanism. Dino: When a sends encapsulated
packet to x and x decaps and reencaps it is almost like label swapping, so it
is not really intuitive. It would look like a seamless encapsulation. Take a
hash on inner header on the RLOC and UDP. In either case there is an entropy ..
RFC6830 talks about reencaps of tunnels which this is and recursive tunnels
would allow you to carry carrier stuff.

Luigi: Out of curiosity, this is talking about source routing.
Dino: Yes, this is an alternative to Spring, just another way of doing it and
but it can do multiple AF.

Uma: If you want to use to route between these two you can have a dedicated
path. D: It would be nice to select and store the rloc in MS and also have a
segment route and then control the path in the underlay. There is also similar
discussions in the multicast case as well

Luigi: <Asked if people agree to make this a wg item>
No objection in room

3.2 LISP Mobile Node - draft-meyer-lisp-mn-16
    10 minutes (Cumulative Time: 60 Minutes)
    D. Farinacci / D. Meyer

Dino: Gave a brief history of LISP. Originally LISP for host, this draft is an
opportunity for putting LISP on a mobile node. This puts LISP in the position
where it has the architecture for mobility.

Dino: Presented Earlier in Buenos Aires. The EID would be fixed and never
change but the it would be possible to change the RLOC changes but we still
have TCP stay up and have session continuity.

Comments/Questions
Joel: Careful because of privacy concerns
Dino: Technically you are right there is another to have secure communication
when you are moving around.

Luigi: Even though the document has been there for a while it has not been
chartered. Now we have chartered it and will be working on it.

Albert Cabellos: There are implementations in progress. Out of experience there
are the things that need to worked on in this kind of documents. At the end,
many of the challenges come from NAT, for instance it is not specified is what
happens when you have an interface behind NAT. What happens when you do not
have a map cache, you do not know where to tell the new mapping , when there
are multiple interfaces there need to do more work on how to do switchover.
There are issues with MS. there are issues regarding multiple interfaces moving
and how handover works from one interface to another in these situations.
Support the document but we need to try to work on these.

Dino: OK Let me response to the NAT question. In the document documents how it
is supposed to work across NAT. An XTR always encapsulates to an RTR and so as
the node move it is only that RTR that needs to know of its rloc changes, all
the other peers were encapsulating to the RTR. In this case, this is a very
good scalability feature where you have only a subset of RTR that need to know
of the change. This is pretty well speced and documented in the NAT translate
draft.

Albert: My point is when you have a handover and that you are no longer behind
NAT and get a public IP address. You have no longer in the RTR but you have the
map cache. This is the case for hetnet cases Dino: OK, this needs to be
addressed. Luigi: we need to enhance this document Dino: Not sure it has to be
to put this in this document as this is not necessarily a mobile node only
problem.

Peter A.: Quick Question about the cellular on mobile environment. The various
GW are both a source of revenue and cost to operators. They essentially want to
get rid of them. What would be the replacement? Do you have some thought and
how to it would work in this environment. The discussion before was about that
these gateways and that they have a lot of other functions and when we started
looking at this and it has about 20 pages of stuff with things like billing,
policy and so on. In fact we had this discussion before but wondering if you
have thought about this. All of these functions would have to be show that they
are no longer need or replaced. I know it is not as exciting as some of the
rest of the stuff but have you thought about some of these points.

Dino: Padma wants to respond to this question.

Padma Pillay-Esnault: As you know, the 5g architecture is still being discussed
right now and no one knows for  sure what is going to be the next architecture.
I think may be your question is specifically about GTP and the services around
GTP, because that is where we really have pages of stuff. The handover of
tunnels.

Peter: The question was not so much about the tunneling and this is a just a
mechanism. There are intermediate things that do things like billing and policy

Padma: I agree. I don't think LISP currently is or should be addressing those.

Peter: This is why precisely why I am asking this question.

Padma: But I think we are talking about two different things here: the control
plane and the data plane. The control plane such as billing and policy GTP even
thought it was clumped and tightly coupled with the tunnels signaling and data
forwarding in the past .. do not have to be so in the future architecture.

Dino: Are you saying that this should remain as is or is there a way to put
charging and billing in the database?

Padma: This is precisely what IDEAS is looking at.

Peter: If I can break it down a little bit, you can do the billing in those GW,
you can somehow accumulate billing and put it in the DB, or using the mobile
devices themselves. There is a lot of work about the mobile being the ultimate
anchor point and have the being billing there.

Dino: We can do make LISP run in the UE. One way to look at this as but we have
also possibility to have the enb to do the encapsulating. If we use the
separate EID and RLOC encapsulating capability , then we can have the enb doing
some of the encapsulation. But when we go to 3gpp they may ask whether we are
replacing tunnel to another type of tunnel.

Peter: There is a beauty to have a mobile device to another mobile device to
have the absolutely shortest path. For low latency application people are
looking at this.

Dino: So you are saying encapsulating ue to ue would be a nice feature. The
radio signals still need to go to the enb, this is something to think about. If
you want to attack the cellular network then you need to show that you are
providing some benefits for all the other things you are losing.

Padma: Comment regarding the UE to UE, let's not forget we are still going over
the air interface and we will have big headers. So there are pros and cons to
that as well. Another of looking at it, is how should we place the mapping and
what does it take to have really efficient mapping for this type of situation.

Uma: I was looking in the mobility draft. Is there any bearing on ipv4/ipv6
here?

Dino: The UE could have ipv6 and ipv4 address and it even though the example
was with ipv6 address it can be anything

Uma: What is the latency? Caches to be updated. Do you have some numbers HO 4g
to wifi? About the caches to be updated and look ups. Dino: That kind of a long
answers and there are many ways of doing these so will take offline as long
discussions.

Albert: I would not say that all latencies are very much LISP related. You need
to update the mapping which is very fast. There are many steps and this can
also be also about other sources such as wifi authentication introduces also
latency.

Uma: I see that.

Dino: So we know when you move from one place to another, it may take much
longer depending on the signaling. We have a proposal that Padma is presenting
called  Predictive Rlocs. And we think that is a solution for zero packet loss.

Uma: The questions is when you are talking about mobile  to mobile, we need to
resolve the PGW to PGW which is not solved in 4g. The problem is that you need
to register to this new PGW and this problem is orthogonal to LISP. This new
authentication to PGW will also contribute to latency.

Dino: Understood.

Padma: Just a comment in regards to what Albert said earlier comments. We
should look at latency across multiple functionalities and have an idea about
how they contribute to latency. It is important to understand how the latency
is spread end to end. This is also another aspect regarding how we cache and
where, how we actually log in. This is very interesting and we need to invest
time in study of all these aspects.

Dino: You can actually put all this in a slice in instance.

Padma: The PGW mobility problem can be solved with Predictive Rlocs but it does
take some timing to ensure that this is most optimal.

Luigi: This is an interesting discussion but you can have make before break
solution and solve the registration problem.

Padma: The problem with make before break is then reforwarding is that with new
applications with are very sensitive to latency and now may have issues when
the reforwarding is long and signaling is added on top of that.

Luigi: This is an excellent discussion.
We will charter the doc and poll to adopt this document as a wg.
No objections in the room.
Poll the room whether it is not suitable to charter mobility as part of the
charter.

Silence in room
Will add to the charter.

3.3 LISP EID Mobility - draft-portoles-lisp-eid-mobility-01
  5 minutes (Cumulative Time: 50 Minutes)
  V. Moreno

Victor: Presented earlier in Buenos Aires. The differentiation from the
presentation that Dino made earlier is that that RLOCs are not on the node
itself. The RLOCs exist on a different infrastructure than the endpoint.

Ask for this document to be considered as a wg document.

Comments/Questions
Uma Chunduri: I can see how these two (drafts) is tightly coupled, in mobile
cases EID and RLOCs are both changing. Can you please explain the reason why
you separated those two?

Victor: There is a history and some implications. There are cases with
applications specially in NV02.

Uma: Is there any special considerations on the EID on what it should be for
example?

Victor: Definition of EID or use? The definition is specified in the draft.

Peter A.: My question is in the interest. I am aware of in IPR to replace
distribution hash tables. The company went bankrupt and bought up by somebody
else. Just make a note that I made a comment. I have sat in court before for
not saying something like this.

Luigi: Clarification? You use EID to distinguish between L2 and L3.

Victor: We segment the mappings with l2 or l3.

Dino: When you do l2 overlays vs l3 overlay there are complications because an
L2 overlay it makes the box look like a bridge but when you have an l3 overlay
it looks like a router. So when a packet comes on an interface you do not know
whether you should take the mac frame and bridge over the overlay or look at
the ip hdr and make it an L3 overlay. So what we are trying to say we should
look at the interface whether it is associated to an Instance ID, a vrf or an
IID which a 1x1 mapping. The behavior should be determined by the ingress
interface whether we bridge or route.

Joel: This is not how things have been done in the past when having combined
bridging and routing.

Dino: That is because we failed.

Joel: There are a lot of bridges and routers who work just fine today. It
bridges over whatever is its bridge domain.

Dino: It is not that simple. Because this works only if you respond only your
arp requests but if the arp request is for the host and we have to figure out
how to respond.
...
So you have to determine how this interface is going to answer arp requests.

Joel: It is pretty straight forward.

Victor: It is more a matter of bridge domain vs routing. Gave an example.

Luigi: How long has it been since this document..
Victor: The document has been around 6-9 months.
Dino: This is a merge of 3 documents
Fabio Maino: I do not remember all the other documents but we had l2 mobility,
Mobility and added to this document and let the others go.

Luigi: query for adoption � several people read the draft and no objection in
room

3.4 LISP Virtual Private Networks and Extranets - draft-moreno-lisp-vpn-00
  10 Minutes
  V. Moreno

Presentation and Request for adoption as wg document

Questions/Comments
Reshad Rahman: We discussed about this Victor. In the next version, are you
going to put some text where the same EID segment can you multiple rloc. Or is
it out of scope? There is an assumption that multiple id segments use different
rloc segments. Each EID segment would be using only 1 Rloc segment. Victor: Yes
Agree.

Victor: Request for adoption
Luigi: poll for adoption.
No objection will take to the list

Joel: This is not changing LISP but the access policy using LISP mechanism
Dino: The exact change is that the rloc  record now has to be an unified list
where it stores the Rloc and Instance ID of the path. That is what we speced
out.

Joel: OK.
Dino: We used an exist LCAF which is LISP LCAF.
Joel: Important that in this case that the receiver knows what to do with the
list it receives.

3.5 LISP A Blockchain-based Mapping System -
        20 Minutes      (Cumulative Time: 80 Minutes)
        A. Cabellos

Albert: Presented in IDEAS side meeting also
Brief tutorial of block chain

Comments/Questions
Joel: How does the MR know which MS?
Albert: Assumption that the information is distributed everywhere
Joel: This is a lot of data
93:00
Erik Nordmark: But this is storing the delegations and not the mappings. The
number of entries might be large but it does not change that much. Albert: Yes.
If you think that your mapping will be changed very often then you should not
be using blockchain to put it in the mapping system. Dino: Real quick question
this is not trying to support ddt. It is not trying to do map referral like ddt
Albert :yes

Albert: you can think of 30 participants but if only 10 participants..

Joel: does all participant need to interaction with the MS
Albert:
Dino But you still need a MS to forward to. Prefer the referrals, the referrals
only happen at the time of the building the ddt structure Albert show Dino: The
blockchain lookup concern. Albert on need to do the whole list to verify that
all is fine

Context
Albert it provides more info that we actually need

- LISP Beta Network
  10 Minutes (Cumulative Time: 90 Minutes)
  A. Cabellos

Presentation of lisp beta network
Albert : Invite people to join

Comments/Questions:

3.6 LISP Predictive RLOCs - draft-farinacci-lisp-predictive-rlocs-01
    5 Minutes (Cumulative Time: 95 Minutes)
    P. Pillay-Esnault

Padma: Presented in Berlin last year and refreshed in November. This is
complementary to the two mobility drafts. We find that in the mobility space
that ID solutions are attractive specially to solve issues with session
continuity. One of the problem is that inflight packets need to be reforward
and today there are many ways of solving that such as reforwarding after
storing and buffering. However, it is not very applicable for Heterogeneous
networks or changing of providers for example.

Comments/Questions

Peter Ashwood: The concept of cloud RAN would be very interesting and have
control of multiple antennas. Sending a copy to the next rloc is natural. It is
very interesting concept to be applied to this application.

Chris Seal (Hutchison): It is difficult to be predictable. In theory, it should
be predictable but in practice this is very difficult to predict. Padma:
Actually it is an interesting question. If you look how we do a handover in
cellular networks, the network knows before you where you will be relocated as
the target Enb has to accept the HO before it signals the UE. Chris: UE knows
because it has been told. While the trend may be predictable. Padma: Exactly,
the UE has a list of possible connections it can connect to. Chris: The reason
why I am saying is that it is remarkably difficult to predict exactly which
sites to go next. Padma: Remember that the UE does have the list of possible
connections with their characteristics such as signal strength and so on. The
choices are narrowed down and we can work from those.

3.7  LISP EID Anonymity - draft-farinacci-lisp-eid-anonymity-00
    5 Minutes (Cumulative Time: 100 Minutes)
    P. Pillay-Esnault

No time. Will be presented in next IETF