Minutes IETF106: lisp
minutes-106-lisp-01

IETF 106
LISP WG Meeting minutes

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
                Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Padma Pillay-Esnault ( padma.ietf AT gmail.com )

AGENDA

Session 1/1 (120 Minutes)
=-=-=-=-=-=-=-=-=-

Tuesday, November 19, 2019
10:00 - 12:00, Morning Session I, 120 Minutes
Room: Hullet

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

Luigi: Commented on moving the RFC 7954 and RFC 7955 to Historic Status.

RFC 7954 was asking IANA for specific prefix ipv6 prefix to be used
experimentally for Lisp.  RFC 7955 was the guidelines on how to manage this
block. So far RIPE has very kindly take over on the management of this block. 
The experiment went over for three years and the deal was if we don't have
sufficient demand for the traffic's blocks and there is no specific action from
the IETF then we give this block back to IANA. We had few requests about an EID
prefix but there was no specific action so it's time to give back this block to
IANA that happened in September.  The most reasonable thing to do is to make
them historic and we can add the note that you can see to the two documents.

Padma: We actually have the Anonymous EID draft that was actually using a
  portion of these prefix blocks. We'll need to find out what we're going to do
  next. Of course it is possible to ask for another range or change the range
  but I wanted to let you know that
.

Luigi: From my perspective, there are two way forward for this document. One,
  do you really need an allocation of IANA and in this case you may ask one in
  the document itself. Otherwise you just can specify the fact that maybe an
  operator should reserve a prefix to use it for the Anonymous EID.

Padma: The advantage of having an IANA pool is that all operators may use that
  and you have a better anonymity.  If you have each operator giving you a pool
  then you won't have an Anonymity that is as efficient.

Dino: The reason we needed a well-known allocation is because if we wanted
  the rest of the bits of the address to be a hash of the public key and we
  wanted an application to use that to look up a public key to verify
  signatures. It would be nice to know that it's not an opaque address or an
  address that's assigned a different way but it actually is a hash.

Luigi: The only comment that I can say okay but not with these prefix. It is
  too late.

Padma: I think we're fine with that this is noted.

o WG Items

- Update on 6830bis/6833bis documents
- https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-27
- https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-25
  20 Minutes (Cumulative Time: 25 Minutes)

  Albert Cabellos

Fabio: Thank you Albert for taking care of the comments because it was a
  massive work. All the comments were incorporated in the discuss in one of the
  last review we got.

Luigi: Acknowledging Albert's work, solving comments and discuss was a huge
  work.

Deborah: I also thank you for your work and I encourage you try this week to
  get with Mirja and Benjamin to encourage them to look at this because what
  will happen in two weeks everybody will take start taking the Christmas
  holidays New York holidays.  Especially the europeans go skiing and Mirja
  will not be on the IESG next year. So we got to get this done so I really
  encourage it to these next week two weeks get them busy with them.

- LISP Generic Protocol Encapsulation (LISP-GPE)
- https://tools.ietf.org/html/draft-ietf-lisp-gpe-11
  20 Minutes (Cumulative Time: 45 Minutes)
  Fabio Maino

Luigi: Just a quick note on GPE. This document past WGLC a while ago and was
  under review at IESG. There were a few comments and changes that we believe
  are important, so the working group has to be aware of them. It's just an
  update but we do not need to go through again through the same process,.

Joel: I understand we don't have transit nodes, the closest we have is an RTR.
  RTRs technically terminate a tunnel and start a new tunnel.  We don't have
  any transit nodes. I've noticed this coming up in a number of overlay
  protocols where the protocol runs between two endpoints and somebody starts
  worrying about what is the transit node doing . Let's not make any argument
  about transit behavior.

Dino: Your comment is very right about our RTRs. But, there could be nested
  headers?

Fabio: Maybe we should write more clearly that and I agree with your reference
  on fancy notes. Maybe what we should specify is that at the tunnel endpoint
  the implementation can pass in H/W, for those headers that were not defined
  at the time that the hardware was designed, the packet can then be processed 
  in software.

Joel: In terms of ETRs is just fine, just the transit header caught my
attention.

Fabio: That's a good comment. I'll change according to what we discussed.

Luigi: It would it be enough just to drop the transit word and say this GPE
node.

Fabio: Yes.

F

abio requested review and comments to be sent.

Luigi: Comment on slide. These are controlled environment and they are
  connected over the public Internet still connecting controlled domains, so if
  the domains are controlled. You have a way to know who's using GPE.

Fabio: It makes sense. That's a good comment. After changes the document will
  be sent for review for last call.

o Non WG Items

- LISP Uberlays
- https://tools.ietf.org/html/draft-moreno-lisp-uberlay-01
  15 Minutes (Cumulative Time: 60 Minutes)
  Marc Portoles Comeras

Dino: If somebody happened in a side uberlay one point to a Map-Server in the
  core Uberlay (and it's against the requirements of the draft) maybe the site
  ID that's being registered could actually be known in the core Uberlay and
  when it registers to overlay one it can do the loop detection.  You might be
  able to prevent this dynamically without any special, anything other than
  what you've already specified.

Marc: We could actually use it but I think we could still find cases where we
  may be able to break it
.

Dino: Clearly the draft says you shouldn't do this and if somebody accidentally
  does it, does the machinery actually keep the network together?

Joel: It's not the machinery. It  isn't going to take care of the horizontal
  links. They need the rules anyway.

Luigi: For clarification, does the site ID comes from the site from which I
  learned the mapping or from the site publishing the mapping?

Marc: It identifies the origin but it's meaningful in the destination. It's a
  number that both border XTRs redristributing the EIDs need to share in order
  to be able to implement this.

Joel: So it's more than just locally significant to the site.

Marc: Actually it does not need to cross side boundaries. We have the border
  set, these two guys are connecting these two overlays. Let's say the overlay
  on the side will use a site ID to identify that prefixes come from side
  overlay. But this number is only significant for the two borders and it must
  be unique in the overlay but does not need to be globally unique. The site
  overlay does not need to know anything about this number, which is used by
  these two borders in order to identity, to recognize, registrations that they
  have made and they have come back to the same border set.

Joel: So it's used by the borders in case their registrations get reflected
  from somewhere else. It's carried opaquely. There is a requirement than in
  order to make it work different sites better manage to nonetheless use
  different ones even though they're locally significant. If two sites collide
  a misinterpretation will happen, so it's not quite locally significant it's a
  64 bit number that's a random. Need to be careful how you describe these
  things.

Dino: To me it's a little bit misleading, how you have the things going.
  Because what's happening is the XTRs and b-xTRs are registering to MS1. So
  what is the arrow going from MS2 back to B-xTR2? Is that a message?

Marc: It could be a publish message, for example so the border XTR does
  subscribe to receive everything that is resisted on Map-Server 2
.

Dino: Are you saying Map-Server 2 is sending a Map-Notify message to XTR2,
telling them about things that have been registered to it which could have came
from other site overlays but could also come from itself and therefore you know
you shouldn't register it.

Marc:  We could also have partitioning or any sequence of events that can lead
to this.

Dino: If Map-Reply has an RLOC set in it, by definition it's not a negative
  mapping.  We should use the right terminology
.

Luigi: May be use the term proxy.

Dino: Anybody who sends a Map-Reply that are not their own RLOC are advertising
RLOCs of somebody else and yes you can call that a proxy.  It's a great term
because when  Map-Server returns on Map-Reply on behalf of an ETR it's a proxy
Map-Reply by definition.

- ISP Mobile Node Multicast - Demo
  15 Minutes (Cumulative Time: 75 Minutes)
  Dino Farinacci gave a multicast demo with lisp mobile node.

Victor: If a receiver is multi-homed do you have to provision?

Dino: iPhones (I don't know about Android devices) they have multiple
  connections but they only use one at a time.

Joel: That is one of the thing that are working to change.

Dino : In iOS or in general?

Joel: In general. We don't know what the implementations do. There are talks
  about using multiple interfaces, and it may be transparent to you. There is
  definite support for even splitting but simultaneously Wi-Fi and 5G, so this
  is something they're all looking at, but it's all ongoing
.

Dino: I would argue that if the IGMP was report was being sent to an EID of the
  RTR then the ITR can see there's two RLOCs for this EID.  Then,  I can load
  split across them so that's how we could do it with an overlay approach.

Albert: The problem typically with mobile phones is that although multi-homing
  might be available at the kernel level, they typically hide this kind of
  functionality and make it transparent to the application level, which means
  that it's very hard to take advantage of that.

Marc: Could we maybe bring back the control Map-Server into the picture?

Dino: I don't know if that helps the problem. If we put a Map-Register
  functionality on the phone and it registered its EID joining the group, it's
  not only registering its EID that has two interfaces it's also registering to
  224.1.1.1. When it does that, it can put a RLOC set in that register saying I
  have two interfaces and to the replicator it looks like two different places
  where in fact it's the same but you'll have to do duplicate detection on the
  receiving end. I've been getting requests from customers contracts that it's
  nice to send packets both ways and if we can use the nonce to detect
  duplicates and have a small cache then on receipt we could drop the duplicate
  packets. That's subject for another topic, another IETF.

Sharon: If you want to fix that for public safety channels, this is not a bug
so keep that option .

Dino: Ok, Interesting
.

- Distributed Geo-Spatial LISP Blackboard for Automotive
- https://tools.ietf.org/html/draft-barkai-lisp-nexagon-11
  15 Minutes (Cumulative Time: 90 Minutes)
  Sharon Barkai

  Author asked for WG adoption
.

Joel: You will need an email to the list from you asking for adoption.

Sri: Can you talk a little bit more about the AAA? You talked about the damage
  interface? The diameter of messages?

Sharon: You have IP connectivity and you want to use specific mobility
  network, what you do is you ask for authorization from the
 DNS: what is my AAA server for this mobility? You will get an IP address and
 then you ask a diameter server in which you give it your credentials, user
 password, vendor, etc... and you will get back an EID which is your overlay
 address on top of the carrier IP address. It's a v6 overlay address that
 you're gonna use in an RLOC  which is a tunnel you're going to use for the
 edge.

Sri: Before that there's a sim-based authentication?

Sharon: No, that's already done by joining the mobile network
.

Joel: He's authenticating the user of the network; he's authenticating the user
  of the overlay service
.

Sri: It is admittedly an unusual use of the AAA protocols, because they're
  normally used inside the network. It was not clear to me. I like it.

Dino: Did you want to run LISP within a slice or across slices?

Sharon: Typically the carrier will provision slices of quality of services for
  our IP network. So in LISP everything is unicast
.

Dino: Do you have an EID for each slice, in a separate mapping system, or would
  it be a crop? That's what I'm wondering
.

Sharon: No the slicing is purely for the EBC.

Dino: Looking at hexagon tiles, where you have one bigger hexagon covering 7
  smaller hexagons, should the small hexagon in the center join one multicast
  group plus the multicast groups of all its neighnoring tiles? Or should it
  joint the group that is the aggregate of all of them? I've noticed with the
  resolutions they don't map exactly and fit exactly so do you have to join
  seven groups the one you're in and all the six neighbors? Have you thought
  about any of those how to make work

?

Sharon: What you use is a specific resolution for multicast, which is
  resolution 9, which is like a few blocks. Let's say this Ruffle City holds
  all the tiles that's EID addressable. When you  have hierarchy there is
  leftovers, this is the price you pay for having a polygon which is both
  approximation of a circle but ties in an hierarchy. In R9, there will be some
  overlaps, but what you will do is that because you know where you are you
  will register for the tiles which you are in your direction vector
. It's a joint latency data and state trade-off and we you now see it showing
early.

Joel: If you know where you're going you join beforehand.

Sharon: Exactly.

Dino: But if you join to a larger grid then you don't have to leave/join,
  packets will go to more places.

Sharon: It is similar to handover. You may join a few just to make sure that
  you are covered. For the same reason, it's okay to receive multi-home, it's
  all contained so you just get more. It will just receive a look ahead
.

Dino: It depends how soon you start joining, because there is join latency.
  The join message is like Map-Registers, UDP messages that can be dropped.
  Will you get the information soon enough? Do you have to plan multiple tiles
  ahead of you? The code doesn't know that the driver is gonna make a
  right-hand turn right
....

Sharon:  No, but the client does know it's vector and the driving.

Joel: There's a distinction between useful to know and really promptly and
  safety-critical information. As far as I know you're not trying to handle
  safety critical data. Really fast is a different scale.

- Overflow Time/ Discussion
  30 Minutes (Cumulative Time: 120 Minutes)

  No additional discussion took place.