* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lisp Status Pages

Locator/ID Separation Protocol (Active WG)
Rtg Area: Alia Atlas, Alvaro Retana, Deborah Brungard | 2009-Apr-28 —  
Chairs
 
 


IETF-100 lisp minutes

Session 2017-11-17 0930-1130: Olivia - Audio stream - lisp chatroom

Minutes

minutes-100-lisp-00 minute



          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  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
          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.
          
          : 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.
          
          



Generated from PyHt script /wg/lisp/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -