Minutes IETF100: lisp
minutes-100-lisp-00

LISP WG IETF 100

Minutes

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

Luigi: The last security draft that was in ISG last call came back for the   
simple reason we are chartered to do standard track work while the security
draft was still experimental.  The document has been already changed to
standard track and we'll work on it make sure is coherent with the bis
documents and then move it forward for last call.  I'm doing the write up and
will hand it to Deborah. Side effect of having the security document back is 
that the introduction document will wait a little bit longer because there is a
missing reference to the security document it's been there for 900 days so a
couple of months more is not a big issue.

Deborah: Regarding the security doc it wasn't so much that it was experimental
versus standards track. I think it's because there's a lot of emphasis on
security as you all know now here at IETF, and I felt that we need to ensure
that we make the best documents. It is really important to have the security
document and it's not going to be favored so much that's just experimental so
let's just make it standards track so that we have a good reference.

o WG Items Presentations

1. Update on LISP 6830bis & 6833bis
  draft-ietf-lisp-6830bis
  draft-ietf-lisp-6833bis

Albert:  Short preso on changes since last IETF.
Latest version 6830bis -07
List of changes
Clarified UDP IPv6 checksums following RFC6936
•  Clarified definition for RTRs
•  Removed EIDs MUST NOT be used RLOCs since this is relative to the deployment
•  State that RLOCs are routable in the RLOC space, not globally routable
•  State that the map-cache is generally short-lived as opposed to short-lived
•  State that AFI pertains to the data-plane rather than an IPv4 or IPv6 address
•  State that ETRs may (not will) send map-replies
•  Change ‘mandate’ to ‘recommend’ in the maximum number of LISP headers
prepended •  Add reference to [I-D.ietf-lisp-vpn] in InstanceID •  Clarify that
E-bit is conveyed in RLOC-probe Map-Reply •  Clarify when to use private IP
addresses •  Clarify when to use InstanceID, remove reference to RFC1918

- 6833bis version 06 changes
I: This is the xTR-ID bit. When this bit is set, what is appended to ignored on
receipt. the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage
procedures in [I- D.rodrigueznatal-lisp-pubsub] for details.

Luigi: Comment or questions?

Dino: We had one comment from you Albert about a reference in 6830 on some
research that's going on, while actually that research has finished a long time
ago. So, the recommendation by Albert was to remove it. We can put a new update
out and send it to the list and see what they think. 6833-bis just came out and
Alberto added a set of clarifying comments that look non-controversial from
first glance but we'll have a deeper look at them next week. I think we've had
a lot of opportunity for commentary for over a long period of time I think
we're ready for last call. We'd like to request that I don't know what you guys
think.

Luigi:  I have a comment that I was reviewing thoroughly the 6830, and there is
some text that does not belong there. We need to review 6830 and then we will
look at 6833bis.

Luigi: There is still some text that doesn't really fit in the data plane.  We
don't have time to go into details today but I want to push this on the mailing
list in the coming weeks because I would like to be done at least with 6830 by
Christmas. Keep an eye on the mailing list.

Dino: okay the goal for 6833-bis is a little bit later then. The next IETF this
should be all in the RFC editor queue.

2. LISP-Security - draft-ietf-lisp-sec-14.txt
  5 minutes (Cumulative Time: 25 Minutes)
  Fabio Maino

Fabio presented the changes on behalf of the co-authors.

Changes Since rev-12
• All changes were introduced in the “Security Considerations” section to
address the last call review 1. Recommendation to periodically refresh LISP-SEC
shared keys to address key aging and key compromise 2. Clarification on
resiliency to Replay Attacks based on use of nonce 3. Considerations on role of
LISP-SEC to mitigate DoS and DDoS

Fabio: Ask if we move back to last call?

Luigi: We will need to redo last call after we moved forward the bis documents.

Fabio: OK

Joel: There is a message here for the WG, because we will be last calling all
three of them soon. You don't want to be trying to fully read from scratch if
you haven't looked at all the three documents, so read them. They're close
enough to be finalized. Please look at them now get comments to the list if you
see something so that we can make sure these are in good shape and we can get
them through last call and hand them to Deborah for the IESG.

3.  LISP YANG Model - draft-ietf-lisp-yang-05
  5 minutes (Cumulative Time: 30 Minutes)
  Reshad Rahman

Reshad: Introduced the NMDA guidelines and the impact on the lisp yang model
draft and resulting changes

NMDA guidelines
• Network Management Datastore Architecture (NMDA) guidelines are documented in
dra -dsdt-nmda-guidelines • Addresses “OpState problem” which has been
discussed at IETF: duplica on of nodes in separate con gura on and opera onal
containers • New <opera onal> datastore for opera onal data added in dra -ie -
netmod-revised-datastores. Contains data/state and con gura on which is in use
by the system • Metadata annota on indicates the origin of the data in <opera
onal> datastore. E.g. intended or learned.

 LISP YANG updates for NMDA guidelines
• Removed duplicate containers across the models
• Single map-cache on (P)ITR (for both sta c and dynamic)
• Single mapping database on MS (for both sta c and dynamic)
• Removed references to “state/con g/cfg/etc” from descrip ons

 Site-ID/xTR-ID
• Only one xTR-ID/Site-ID per LISP router-instance across all its LISP roles

Map Server
• Authentication key now per Site-ID
• Site-ID/xTR-ID added to mapping records • Removed ‘registered-mappings’
• VNI is now the parent for mappings

Dino: Why the authentication is per site-id rather than by prefix.

Reshad: Most common usage is by site-id and it can be augmented to cover
prefix-id. The implementations I'm aware of have it per site ID

Dino: So, if somebody wanted different authentication for different
eid-prefixes for the same site they would have to configure them as separate
sites.

Reshad: Well, with this model yes. If you want to support what you just asked,
we would need to augment the model. It could be a vendor specific augmentation
or maybe it can be part of the IETF.

Dino: So, if you want ID prefix authentication just configure it a separate
site you're not taking the functionality away just have to do it a little
differently and if you say there's popular implementations that do it that way
then it's probably not that much of a problem.

Reshad:  That is our opinion yes.

Next steps:
• More operational data needed, e.g. counters?
• Compare with LISP MIB
• Comments/feedback from LISP WG

Luigi comment: If you say that the ETR is per-ITR and not per-mapping which
means that you have no choice but use one ETR for different prefixes.

Reshad: You cannot do it per prefix right now with the way the model is today,
so if you people feel that this functionality is either needed or fairly common
implementation, we can definitely consider adding that back either via an
augment of that base or by adding it in the base model.

Deborah: I saw this is experimental most of the young work we're doing it's
standards track in IETF.  I was just wondering could this be standards track
because especially you say you have implementations.

Reshad: I was not one of the initial authors.  I think it was experimental
because that's what the other the work was started.

Joel:  We started working on this before putting the base work on standard
tracks.  I think it would make very good sense to move this to be proposed
standard as well and we'll advance it behind, but not very far behind, the
other documents.

Reshad: So the community now has four documents to read.

Deborah: There is a strong interest right from the IESG not only in security
but in management and so if we can show you also have a document in the
pipeline for the yang that would be great.  I would strongly encourage if you
could get some of this to the hackathon that we could show the implementations
and if you have any open source. That is why I'm also thinking to make it
standards track because of the open source community.

 Fabio: we have a few implementations available and if we can put it on
 standard track that would be really cool.

Non WG Items

1.  LISP Map Server Reliable Transport -       
draft-kouvelas-lisp-map-server-reliable-transport-04.txt
  10 minutes (Cumulative Time: 40 Minutes)
  Reshad Rahman

Reshad presented on behalf of the authors
Changes
Replaced draft-kouvelas-lisp-reliable-transport That was last presented at
IETF91 Main change since then is addition of scope field in the refresh
procedure

Authors: Asking for WG Adoption.

Dino: This might be a radical comment, but we are probably in a technology
transition now maybe the question should be asked if we can keep the messaging
same as LISP and run it over QUIC. We'll have a UDP interface we can use the
same port number and we get security for free.  You haven't said if you use TLS
here and I'm seeing requirements for having the interaction between the mapping
system be encrypted. So, I'm just wondering if we should maybe spend some time
there get some folks together and see how LISP can work over QUIC to make it
reliable so I don't know if you think that's radical.

Reshad: I can't say because we've done this, you have a good point, but that's
where we are now.

Luigi: Asked how many people read the draft – not many hands in the room
Please all read the documents we'll come back to this question

2. Ground-based LISP for the Aeronautical Telecommunications Network
  15 minutes (Cumulative Time: 55 Minutes)
  Reshad Rahman

Reshad presented as co-author

Background - Use of LISP to address the requirements of the worldwide
Aeronautical Telecommunications Network with Internet Protocol Services
(ATN/IPS) • International Civil Aviation Organization (ICAO) is proposing to
replace existing services with an IPv6 based infrastructure for Air Traffic
Management (ATM). • ATN/IPS handles Air Traffic Controllers (ATC) and Airline
Operation Controllers (AOC) • draft-haindl-ground-lisp-atn was presented at the
ICAO IPS Mobility Sub-Group • Builds on mechanisms defined in
draft-ietf-lisp-eid-mobility

The different types of exchanges were presented
- Aircraft registration and ground to air traffic with preference to a specific
region - forwarding path before the resolution by the map server and also after
resolution. (necessary for no packet drop) - optimized multi-link mobility

Next Steps:
Looking for comments from the wg

Peter Ashwood Smith: Is there any requirement for a ground-based wired
connection when the aircraft is at an airport?

Reshad: I don’t know Fred?

Fred Templin: So, the question was from ground-based to the aircraft's wired
link? They call that GW link actually. That's just another example of a link
that an airplane would use to route. It could be VHF or another link.  The ICAO
is actually meeting this week in Bangkok and I was there on Monday and
ground-based LISP is one of three proposals that they're looking at for what
they call the mobility solution. A second proposal is the simple BGP method
that I talked about last time. Now they've also brought proxy mobile ipv6 into
the into the picture. There are 3 solution proposals that are being looked at
and the selection will happen over the course of the coming months.

Dino: When you're parked at the gate and you have a wire connected that could
just be another mobility event right?  I think that's maybe what you're getting
to use the same machinery and it doesn't matter if it's wireless or wireline.
There will be a ground-based xTR that would have a new locator at the airport

Luigi: Is there any critical traffic that goes over these links? Because you
can imagine to actually duplicate the traffic' on the various links, meaning
that you increase the probability that arrives at the destination.

Reshad: I think we got comment like that.

Fabio: I think it's interesting to note one of the few optimizations that can
be done is using pub/sub that is the direction where we are trying to move the
protocol. I think it's a nice use case articulating the value the LISP. It's
probably confirming that some of the direction that the working group has been
going on to evolve.

Dino: I agree with Fabio. I'm kind of excited because the idea of the mobility
draft could be used for all these use cases. The ID mobility for aeronautical
application and the 5g proposal we're making is using the exact same mechanism.
The generality in the level of indirection is becoming quite useful for many
use cases with no new machinery being added.

3. VXLAN GPE - draft-brockners-ioam-vxlan-gpe-00.txt
    5 minutes (Cumulative Time:60 Minutes)
    Franck Brockners

In situ OAM in a nutshell
- Gather telemetry and OAM information along the path within the data packet,
(hence “in-situ OAM”) as part of an existing/additional header No extra
probe-traffic (as with ping, trace, ..) “Hybrid, Type-1 OAM” per RFC 7799 -
Generic, Transport independent data-fields for IOAM Scope: Per-hop,
specific-hops only, end-to-end Data fields include: Node IDs, interface IDs,
timestamps, sequence numbers, ... Encapsulation - IOAM data fields can be
embedded into a variety of transports, including: IPv6, SRv6, NSH, GRE, Geneve,
VXLAN-GPE ... Base IOAM document adopted by IPPM! • draft-ietf-ippm-ioam-data-01

Authors: Request Feedback

Joel: Lisp working group is not going to define alternative encapsulations.

Fabio: There are capabilities in 6833bis that can be used in other data planes.
We have separated the control plane and the data plane for LISP.  The question
is whether there are some capabilities in RFC 6823 Bis that can be used
independently from the transport.

Joel:  We're not going to get into defining works of other groups. We will
happily consult to some other group. If the NVO3 would like to be able to use
LISP as a control plane we would work with NVO3. I specifically do not want to
get into any risk of this working group trying to standardize other WG
fallouts. That's why I'm trying to be careful here.

Luigi: We are specifying a protocol that can be doing layer 2 overlays. I would
suggest from my point of view is can we look at RFC6833 and if you want to use
it with a different data plane that allows you to use define new features that
would not be available with the LISP encapsulation. That could be a draft you
can bring up to this working group.

Joel: New encapsulations are not in charter right now.

Luigi: We can certainly have a discussion on control plane for other data
planes. That’s all.

Dino:  Joel, so what if they said that the data that they gather from this data
plane, even though it's not chartered in the LISP working group, is data they
may want to store in the mapping system, that could be in charter?

Fabio: Adoption for this particular draft I don't think is on the table today.
I can bring up a draft where I try to specify how you can use 6833 with another
overlay. This is a discussion that we should have in the working group.

Franck Brockeners: We have running code for this very encapsulation in VPP
Fido. There is running code of this very encapsulation in hardware with a bunch
of chipset vendors we're using LISP implemented in open daylight for the
mapping system, where you basically set up tenant networks which are VxLAN
based and LISP controlled through OpenStack. So it is happening as we speak. 
We can say okay we don't want to have it here and but it's there in the
industry and it's happening. Let's make sure that we reflect what happens in
the industry and don't close our eyes and put our head in the sand.

Luigi: You mention you are using the LISP control plane. The working group
could be interested because we have charted the control plane to support
multiple encapsulations. The encapsulation itself: we are not chartered for it.

Uma Chunduri: I see this as a different way regardless of VxLAN data plane or
LISP native data plane; this gives LISP actually more OAM capabilities which is
good.

Dino: Does this data only get written to the packet by the encapsulator and
only read by the decapsulator?

Mickey Spiegel: We haven't really specified that in the document as it is right
now. But that seems to be a natural fit for something that would insert
information.

Joel:  The original ITR would put this in the packet, the RTRs would preserve
it and might processing, that would be a new functionality for the RTR, then
the ETR would process it and strip it.

Dino: I was kind of thinking the same.

Mickey Spiegel: All three of those ITR, RTR, and ETR would be adding there are
no data fields into this format and then when you end up reporting you're
getting information right every one of us

Dino: The reason I brought that up is because you may have an RTR topology
that's made up of a multicast distribution system. I'm wondering if you have
thought about this working on multicast branches?

Mickey Spiegel: It's certainly possible to do that.

Dino: If the RTR can rewrite the information that was put on by the ITR, as it
goes down this tree do the  spec allows additional appends to happen to the
packet?

Mickey Spiegel: If you're replicating the packet the information that was there
before will be the same, while the new information that you're adding may be
different.

Padma: I really like the OAM, I am worried about one thing. How we're going to
actually reconsider having to get it encrypted and who is reading their
information. How about eavesdroppers who actually look at it in the middle. I
know there's been so much of discussion both in SFC and other places about
monitoring and the abuse of monitoring have you thought about that?

Dino:  If this has to work with LISP-crypto then maybe the data plane did just
come in charter. The big question is an ITR prepends this packet data and
encrypts the packet, sends it to the RTR or ETR, let's say in RTR because it
seemed more interesting, there it decrypt and decaps then it can read the data
hopefully the data is only in memory so it's not exposed on the wire. So, the
question for the chairs is if they want this to work with LISP-crypto working
then you're asking this OAM stuff to go in the LISP encapsulation format or how
it works with the data planes that have been defined in this working group.

Padma:  Before you respond I want to say something else. What I'm worried is
when you said this is stored in the map server. Maybe that's not the way to go.
I think we need to think carefully about what to do with this information,
where it should be, who can read it.  I think there's a lot of things think
about before we actually make a decision.

Dino: There's no reason the data that's stored in the mapping system has to be
in plain text it could be encrypted.

Padma: I agree. You know just to say some of our latest woes is the fact that
this encryption is considered not enough by some people and that's why I'm kind
of erring on the side of caution before we actually say we will do this or we
will do that I think we have to look at the implications of what kind of
comments is going to come from other areas.

3. Publish/Subscribe Functionality for LISP -
draft-rodrigueznatal-lisp-pubsub-01.txt
  15 minutes (Cumulative Time: 75 Minutes)
  Fabio Maino

Publish/Subscribe Overview
• Map-Servers configured in proxy-reply mode
• xTRs provisioned with unique xTR-ID
• Subscription piggybacked on the Map-Request (no new messages)
• N-bit (notification) introduced in the EID-Record to ask for subscription
• Map-Reply returned if subscription not supported or rejected
• Map-Notify returned if subscription accepted
• Publication of mapping updates via Map-Notify
• Ack’ed with Map-Notify-Ack

Erik: Is the nonce of the Map-Notify is not the same as the map-Request.

Dino: The nonce should be returned in the Map-Notify.

Luigi: Why not using a bit? If you have an explicit bit you do not need to look
at TTL zero.

Dino:  If you process a map reply today with a zero TTL it basically allows you
to delete the map cache entry right away so when you get this map notify it's
the same code that you use.

Luigi: If you have a bit you don't even need to process the reply. I mean you
don't need to look at the TTL zero.

Dino: You're going to look at it anyway because you have to parse all the EID
records in there, because this map notify may have other entries in it.

Erik:  What is the lifetime of the subscriber table?  Is this soft state or
does it stay around forever?

Fabio: The TTL of the mapping or a detail of the subscription are the same.

Erik: If I have a mapping has a 24-hour lifetime the subscriptions would
implicitly be 24-hour lifetime and if you want to update, that seems to imply
that the map server now has to keep this in persistent storage for 24 hours so
that if it restarts it can still honor those subscriptions. That part of
reliability is important.  I guess there's two different things at least in my
mind the lifetime of that mapping as opposed to the lifetime of the
subscription.

Dino: I mean he's making a good point. If there's a XTR  that's registering a
prefix and that has a TTL , why is that TTL have the same relationship of a
subscriber. The subscriber may want to have notifications for less than that
time or maybe more than that time.

 4. LISP Traffic Engineering

  15 minutes (Cumulative Time: 90 Minutes)
  Yan Filyurin

Reshad: I understood what you mentioning for S- BFD are you just saying you're
going to be using as S-BFD or you need to extend the S-BFD as it's defined
today?

Yan: We don't necessarily want to extend S-BFD, but S- BFD has the capability
to probe individual paths. We are thinking of capitalizing this as a way for
S-BFD to be encapsulated in the LISP packet and use LISP as a capability to
probe.

Reshad: I thought you were trying to maybe exchange discriminators.

Yan: Possibility the discriminators. Could also be exchange IGP, but that I
don't think we've thought this through enough to really speak on it.

5. LISP on Android & iOS
  10 minutes (Cumulative Time: 100 Minutes)
  Oriol Mari

Oriol  Presented the Android  system

Sri Gundavelli: What is the trigger for your handover?

Oriol: We are using a framework of Apple. It gives us a system configuration
framework that we can register a notification system that the system when
detects some changes on the network configuration.

Sri: Does the framework allow you to specify if the RSSI value falls below
certain value?  Does it allow you that level of control? It allows you to
detect the change?

Oriol: Will follow offline.

Dino:  You are sending info requests and info replies that means it can support
going through NATs as well?

Oriol: We thought of NAT devices. Yes it works with them.

Dino: Can you keep both interfaces LTE and Wi-Fi up at the same time and make
it multi-homed and make it active-active?  Does the framework allow you to do
that?

Oriol: Yes you can. It means to double our procedure but I'm not sure if you
can use it at the same time both interfaces.

Dino: In other words at the remote  ITR can probe and find the best path and
come in on either direction that would be more useful. If the framework only
allows you to send on one that's not the end of the world, if you could receive
on both that would be cool okay.

Dino: Do you think it'll work over the Bluetooth interface as well? Would be
cool because then you can do peer-to-peer networking easily.

Oriol: I think that you can use it.

6. LISP Control-Plane ECDSA Authentication and Authorization -
draft-farinacci-lisp-ecdsa-auth-00.txt
    10 minutes (Cumulative Time: 110 Minutes)
    Dino Farinacci

Reshad: I haven't read your draft but what kind of performance impact do you
have because you're using public private key right?

Dino: This draft is only putting signatures in the packet there's no
encryption. We are only solving authentication authorization but now that we
have a public key system available we have the opportunity in the future to
decide when and where to encrypt.

Fabio: Is there an equivalent for LISP-crypto where you can use elliptic curve
for the diffie-hellman exchange and make it more efficient?

Dino: LISP-crypto already use elliptic curves.

Uma Chunduri: I think you used ECDSA for public key private key generation.
he's asking about the DH so that you can create the secure channel.

Dino:  There is another RFC that's the data plane and already support cipher
suite and uses EC with AES encryption and ChaCha 20 .

Albert: When you want to authorize a map request the map request will be
signed, then the map server will take the public key and hash it.

Dino: No. When the map request is signed the signature ID is there. When you
have the signature ID the hash is in the lower bits and is used as lookup key
to the mapping system to retrieve the public key.

Albert: How did the public key get there?

Dino: A third party registered that hashed distinguished name.

Joel: You have to worry about who's authorized to enter those?

Dino: When they send a map register they have to share a key to be accepted, so
it has to have a security association between itself.

Joel: One way to attack someone is to cause there to be a different public key
for them they can't register because their private key doesn't match the public
key.

Dino: It's always a good sanity check when somebody actually registers to use
the same hash algorithm to make sure that the hash and the public key actually
match. There's some other data that's in there too so it's just not the public
key.

Uma Chunduri: this is very good for LISP actually, it's giving basic security
properties.  What is important is also anonymous ID generation with one-way
hash but maybe we cannot with this approach. Multiple ephemeral IDs can be
generated, I'm not sure about. I think Bob was working on this.

Dino: I thought about this quite a bit. The ephemeral IDs from the other specs,
I think the conventional wisdom is that hashes are pretty random. Key
management is not a trivial matter so you have to consider that you know this
isn't an XTR. Should I give them 16 key pairs that they can just spin and use
and the answer is yes, they can do that for sending data packets.

Uma Chunduri: Is this one of the discussions we were having with Bob. We can
discuss offline how to do this action.

7. LISP for the Mobile Network - draft-farinacci-lisp-mobile-network-00.txt
    10 minutes (Cumulative Time: 120 Minutes)
    Dino Farinacci

Padma: This draft is also coupled with other documents which are looking at the
aspect of provisioning and how to integrate it with the 5g especially for the
mapping systems.  This draft is just part of the whole solution but there is
much more being published elsewhere

Sri: This is still an overlay solution right, I'm curious how do you see this
working with the 3gpp. Because you can enable the QOS part for a particular
flow, but how does that work?

Dino: The 6830 specifies that you copy the inner header QoS to the outer so
it's maintained across the core. The ToS bits in an ipv4 and the flow label in
the ipv6 is copied to the outer header when it can be. Meaning that a flow
label of 24 bits can't go into an outer ipv4 header with 8 ToS bits.

Sri: You can do the marking but my point is yet the PGW it has to allocate the
resources. Initially there was PGW1 it has allocated the network resources so
now after you hand over or you route the flows through a different path you're
no longer anchored through the same PGW so now I'm wondering how you move the
QOS

Dino: Like Padma said there's a lot of other specifications and there's a lot
of other machinery that's operating here. What we're trying to show here is a
way to get shortest paths on the data plane and pulling state from the mapping
database. There's a lot of other stuff that needs to be worked out and that's
why we want to go to all these standards groups that have expertise in this
area.

Sri: I understood that with the overlay approach you can find the optimized
route but my point is that you need to have some interworking with the 3gpp
signaling so that you can move the QoS.

Uma Chunduri: The mapping system here is one of the components in the 3gpp that
is what Padma was describing. It is described in it's a NGP document.

Padma: There are other documents that actually show how the actual registration
involves the mapping system in the 5g. These documents are currently under
review and so they're not ready yet but there are much more machinery behind
this. But the part that Dino is presenting today is just a data plane and we
know that on the 3GPPG GTP control plane there's a lot of discussions happening
right now and there's a lot of things in flux. But at least this shows one
solution without anchors which removes the triangular routing and that's what
we're really trying to push.

Yan: I assume that you guys are working on all the different aspects of service
function chaining to integrate into the solution.

Dino: As you know RTRs can be placed anywhere and since we know there's going
to be a lot of virtual functions that are going to be in the 5g Network we
could hop through them where necessary. We have to be a little bit careful
about that because we can suggest all this functionality, but as you take
additional hops it's going to affect this one millisecond latency. if that's
going to be in the data path there's going to be a huge cost to the end user
for special applications.

Yan: Many people are just interested in say placing traffic shaping devices.
People will want all kinds of things to control.

Dino: I do want to mention is that Peter and the guys up in Ottawa have done
some really good research on this. I'm using ID locator separation on a 5g
network and they've done it with some real devices and virtualized some stuff.
Maybe next IETF we can show you a demo.

<missed name>: I'm curious what kind of scaling number is in the mapping system
you would need for that kind of functionality for the mobiles

Dino: I have some slides of how to deploy a mapping system with a billion nodes
in it. I don't think the state is the scaling problem I think it's distributing
the map-request load across the mapping system and trying to fix DDoS attacks
of the mapping system is the thing that should keep us up at night and that's
the stuff that needs more people to think and look at.

Peter Smith: Just on the scale issue, we've been doing some experimentation
with pub/sub in conjunction with LISP-like data plane. We've been using
different massive scale already deployed already working on the billions scale
pub/sub systems and we're seeing one or two hundred millisecond response times
just using those existing systems. what Google and the others are doing is what
we could actually achieve with a worldwide scale mapping system so that it's
very promising and I invite you to look at our demonstration if you're if
you're interested.

Dino: Application level databases scale better than a DNS like structure like
DDT and I think we need to do experiments in this area to see what is better.
Now all these database schemes all have the same sort of problems they have to
deal with. I think some of the advantages of LISP DDT is that the same database
does not have to be store. The cost of that is that you have to go find the
information when you need it and do you want to pay the cost at that time. A
lot of people have said why don't you connect a bunch of map servers together
with Cassandra or the blockchain. Lot of research is ongoing trying to figure
this stuff out.

Uma Chunduri: Just one clarification for this question. It also depends on
where you are putting the mapping system.  Scale question doesn't come into
picture at all if it is a 4G system.  Today the P-GW region is 1000 kilometres
some cells and IoT's are connecting. In 5g the thousand of km are shrinking to
100 kilometers that's why your you PGW of mobility comes into picture and LISP
solving that that's the crucial problem. Session Continuity across P-GW is the
key problem here.

Erik: I was wondering if it's this goes forward do you think that there will be
additional security requirements?

Dino: I think it will be inevitable. Maybe Padma or Uma Chunduri Chunduri could
comment to that I asked the question yesterday a 5gangIP, if LISP crypto would
be required and how much you know how much encryption versus monitoring of
flows people need because that pendulum has to go back and forth. I'm not sure
how much security actually.

Uma Chunduri Chunduri:  that's a very valid question. The mapping if it is put
it into the providers control plane it has to have interfaces where it can
attach to the authentication.

Padma: One of the things that we've been looking is not only the placement of
where the mapping system is, it's how distributed it can be. There's one
question that we haven't really approached here is how do we leak those
prefixes and it's a little bit different from pub/sub as well because we will
have to really integrate with the 5g roaming scenarios.  Actually this is under
study right now at least by our team so anybody who wants to collaborate with
us is more than welcome.