* 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: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2009-Apr-28 —  
Chairs
 
 


IETF-105 lisp minutes

Session 2019-07-22 1330-1530: Notre Dame - lisp chatroom

Minutes

minutes-105-lisp-02 minutes



          IET 105
          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)
          =-=-=-=-=-=-=-=-=-
          
          
          Monday, July 22, 2019
          13:30 - 15:30, Afternoon Session I, 120 Minutes
          Room: Notre Dame
          
          - Administration
            Halpern/Iannone
            - Blue Sheets
            - Agenda Bashing
            - Status reports for WG drafts
              5 Minutes (Cumulative Time: 5 Minutes)
          
          
          Luigi:
          RFC 8113 this is now in the RFC queue just waiting for a missing
          reference
          . Yang model is under review a yang doctor, Chris Hopps, and
          there is a mismatch in the document between the model and the tree.
           Chris
          will contact the authors to show the issue so that this can be solved.
          
          
          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
            15 Minutes (Cumulative Time: 20 Minutes)
            Albert Cabellos
          
          Albert presented a summary  of the updates on 6830bis and 6833bis since
          last IETF.
          A new version of each of those documents both in June 2019
          was posted, hopefully addressed all the comments made by the reviewers.
           Changes summarized into four main items: Security, rate limiting, MTU,
          and other.
          
          
          Discussion:
          
          
          Fabio: Just trying to understand what are the next steps. We are waiting
          for the discuss comments for the latest version to be reviewed by Ben
          and Mirja.
          
          Deborah: Did you actually send them mails?
          
          Albert:  yes I did.
          
          Deborah: June?
          
          Albert: Yes. I can check it again.
          
          Deborah: If you can this week try to grab them and ask if they had
          a chance to look at it. I'll try to remind them - and definitely next
          week we'll get on or more because everybody's very busy right before
          the meetings but we try to get them to clear them. But if you can get
          them this week, it would be good.
          
          Albert: You are suggesting me to send them a friendly reminder right?
          
          Deborah: Just say you have time to meet this week
          
          
          Fabio: May be just one additional comment. On GPE I have a set of
          comments from Mirja that needs to be applied at document, and I just
          didn't have a chance to do those, but they're in the queue so I hope I
          can do it shortly after.
           I would like to keep these in with the review
          and aligned with the 6823bis and 6833bis.
          
          
          
          - LISP-Security (LISP-SEC)
              - https://tools.ietf.org/html/draft-ietf-lisp-sec-18
            10 Minutes (Cumulative Time: 30 Minutes)
            Fabio Maino
          
          
          Fabio presented the updates in response to comments from Benjamin Kaduk
          and Mohamed (Med) Boucadair.
          
          
          Discussion:
          
          
          Fabio: Not completely sure on the status of the LISP-SEC draft. Because
          we were told by the reviewers that the review should go together with
          the review of the bis documents. A bunch of comments received in Prague
          have been incorporated. We think that the next step is getting a feedback
          back from Ben and from the security Directorate.
          
          
          Luigi: If you check the data tracker this document is in the last call for
          two months.
          Clarification is needed on whether or not moving it forward.
          
          
          Deborah: It's really good that this is stable and I would give it a
          heads up,  when you say to Ben.
          
          Fabio:  So now you can have this document also to complete everything.
          
          Luigi: As far as I remember he was looking for our complete security
          solution for  LISP and this was kinda missing piece.
          
          
          Deborah: I will send him the heads-up for early review.
          
          
          
          Non WG Items
          
          - LISP Uberlays
              - https://tools.ietf.org/html/draft-moreno-lisp-uberlay-01
            20 Minutes (Cumulative Time: 50 Minutes)
            Alberto Rodriguez Natal
          
          Discussion:
          
          Luigi: Can I have several uberlays connecting different site overlays
          and these uberlays can interconnect between them?
          
          
          Alberto:  This is actually in the list of next steps. In the draft
          right now we consider a single overlay. We have discussed on what to do
          with multiple uberlays. That comes with a different set of requirements
          and assumptions that we need to evaluate.
          
          Dino: It turns out to have multiple uberlays is less desirable than
          to have good multi-home connectivity on the underlay that the uberlay
          realizes because the uberlay is just there to connect the edge points
          of the other overlays and nothing else.  It is not clear that you need
          separate policy where you need a separate uberlay  infrastructure to
          interconnect so that's why we first started off that we needed one.
          
          Luigi: I understand that you start  with the simple solution but my
          point is not that you need several uberlays. What can happen is it for
          whatever reason you have different overlay sites and they decide to
          interconnect. Let's say me and you and Alberto and Fabio we interconnect
          pairwise and we use different uberlay but  in the future we want all to
          interconnect we become big family. Now, what you do?  You deploy a new
          unique uberlay or you interconnect the uberlays?
          
          
          Dino: What you do is you interconnect the site overlays in another
          mapping system.
          
          
          Luigi: the uberlay?
          
          
          Dino: No, you connect all the site overlays you take all their any EIDs
          and you send them to a new mapping system and it looks like a regular
          overlay rather than to iterate this pattern again.
          
          
          Albert: I think that Luigi's question is that you have two completely
          separate uberlays like the picture you have here but two different ones
          so you have two overlays connected here to here right. Then at some
          point you want to bring the four different sites overlays together. You
          will have the two uberlays that used to be completely independent from
          each other, now aggregated so you will end up with a single uberlay that
          connects the four site overlays.
          
          
          Dino: Correct, you merge the uberlays but that's what I wasn't
          suggesting.  I was suggesting it's just one overlay, because the EIDs
          that are connecting this uberlay have their own local mapping system
          and they could register to a mapping system that's global and it just
          looks like a regular LISP overlay as we know it today.
          
          Luigi:  You kill at least one of the uberlay and you keep the other one.
          
          
          Dino: It is not clear, as you still need it anyway for the original
          reason.
          
          Luigi: This is something that must be discussed in the document.
          
          Alberto: I agree that we are not addressing yet the  use case where you
          have multiple overlays.
          
          Fabio: This work is coming out of the International Civil Aviation
          Organization. In that particular case for example the requirement is
          that there are some LISP domain that they will not become the same
          because there may be different providers. The first level  is trying
          to put them together with an uberlay, yet it is exactly trying to get
          everybody to talk to each other. Depending on how many domains you can
          go to a single overlay or a single uberlay or maybe to multiple.
          
          
          Luigi: I think in the draft needs to say something one way or another.
          
          
          Authors request discussion on the mailing list  and  would like to
          know if the working groups will take upon this draft and make it a work
          group item.
           Authors invite discussion on next steps points.
          
          
          Luigi: For clarification: what do you mean by improve state reduction
          in uberlay?
          
          
          Alberto: For instance, think that you have multiple ways to register.
          (on slide multi-overlay control plane) these sites at the border need
          to register the mappings from the local site overlays into the uberlay
          and you can take different approaches for that so you can register the
          mappings as you get them from the local site or you can try to aggregate
          as much as possible. If there are gaps, you need to register the gaps
          and so on. So we need to discuss which is the best way to reduce the
          state you need to release it into the uberlay.
          
          
          Luigi: Okay. If we did a very good job when we have a massive scalable
          mapping system you don't need this.
          
          
          Alberto: If you're talking about the overlay that's fine.
          
          Fabio: You can have an overlay that is gonna run at the planetary scale
          but there may be two organizations don't want to use the same mapping
          system.
          
          Alberto: Yes. Let's put it this way: if you don't want to aggregate
          anything that you're gonna really need then a mapping system that is
          able to scale to a global scale, so that's the kind of considerations
          that we need to think of.
          
          
          Dino: We can have the analogy with a single BGP process that's running
          with multiple VPNs. You can keep the VPNs separate but they're shared
          by one process and one routing protocol but if you ran two BGP routing
          process that are completely separate it may have a different topology
          altogether that would be the same as using uberlays.
          
          Luigi: Can you clarify to me know what is the difference between federated
          and decentralized?
          
          Alberto: The centralized  comes from some the discussion that we are
          having with Victor and the cloud guys. Latest discussion is about how the
          organization can deploy its own site in an overlay and then the uberlay
          is federated. So that no organization has control over the uberlay. Still
          under discussion lot of open questions still.
          
          
          Luigi: There is some work to do on this document. Still need much
          discussion on the mailing list if we want to go for the adoption.
          Should define what is missing  and discuss on the mailing list.
          
          
           Alberto: We need to agree on the scope of the draft and what it is not
           going to address.
          
          
          Luigi: Other than that, I don't think there is any other specific
          issue that should be covered.
          
          
          - LTR: A LISP Traceroute Tool
              - https://github.com/farinacci/lispers.net/blob/master/docs/ltr.pdf
            15 Minutes (Cumulative Time: 65 Minutes)
            Dino Farinacci
          
          Dino Presented a demo of the tool.
          
          Discussion:
          
          Albert: I guess that you infer that there is a map cache miss because
          you send a packet with a larger TTL and you don't see any next hop.
          
          Dino: The tool has nothing to do with the original traceroute, so it
          doesn't use TTL mechanisms at all. It's not written up in a draft,
          there's the source that you can look at.
          
          
          Albert: Do you have any plans to specify protocol changes that you
          need in order to implement that, because I understand that this doesn't
          work with a standard LISP.
          
          
          Dino: Right it would not.  It's absolutely true that the forwarding
          implementation has to change to understand the trace. We can certainly
          write a draft if the working groups interested in it.
          
          
          Prakash: Does it understand also the underlay the LISP packet is
          travelling on?
          
          
          Dino: It knows the number of hops. There is another tool called LOCator
          that can be used in conjunction. I am open for discussion on possible
          uses and integration of this tool and what information is useful.
          
          
          
          
          
          
          - LISP Mobile Node
              - Demo
            15 Minutes (Cumulative Time: 80 Minutes)
            Dino Farinacci
          
          Discussion:
          
          Luigi: Clarification: you have LISP mobile node on your iPhone but you
          do not live in Montreal, your iPhone is pointing to which PETR?
          
          Dino: Will show in the demo. It did work when I was sitting in
          Montreal. It worked on the cellular network
          .
          
          Luigi: how do you change it? Because basically you may have a long stretch
          if it's always the same PETR, I mean if it's your own then your traffic
          is going back to California, even if you are connecting to something
          that is here.
          
          
          Dino:  Yes. I already experimented where that was very interesting
          the RTT is doubled yes. You mean should the PETRs should be dynamically
          learned based on your physical location?
          
          
          Luigi: Yes. This could be an issue. We have to think about this.
          I'm not asking for a solution for now. Another thing RTRs are configured
          by gleaning?
          
          
          Dino: The XTRs are gleaned and the RTRs have a command saying glean
          the information from us.
          
          
          Joel: We have the document says not to do that.
          
          Dino: The document says not to do that in public domain.
          
          Luigi: We have to keep this in mind if you want to move to the document
          forward. We cannot have the basic specs that say you should not use this
          and another document is technology is based on something you should not
          use.
          
          
          Dino: I understand your point but we're not violating anything.
          
          Dino: Mobile node document  just assumes they're in this pristine
          environment which is not the Internet where the RLOCs that the mobile
          nodes registering are all in global space.  So I mean a lot of these
          documents don't reflect reality.
          
          
          Demo.
          
          Caveats discussed:
          - Lisp Mobile mode must send before it can receive
          - Latency exists to learn LISP-MN when it is discovered
          -Asymmetry problem
          
          Discussion:
          
          Prakash: Does RLOC Probing cause scalability issues in the network?
          
          Dino: Certainly less is better. Apple does a good job of testing the
          Wi-Fi signal and if it's not good it automatically switches to LTE to
          give you some better performance. Should we be smart enough to know that
          the PETR aren't doing well with RLOC probing, which may be your point,
          and maybe turn it off and then try to go native. But then you lose a
          session survivability multi-homing because the network connectivity isn't
          good. Your point is taken should you just RLOC probe a few of them. So
          maybe not all the phones in the world are gonna probe the same for RTRs
          or the same hundred RTRs they're going to be local based
          
          Prakash: How to exchange of LISP cryto keys?
          
          Dino: I don't know how we're gonna exchange lists crypto keys dynamically
          without RLOC probing but unless they're  PSK static or something like.
          
          
          Luigi:  How do you exchange keys?
          
          Dino: They are public keys it's diffie-hellman exchange it's like
          TLS does so it's no different. The private secret keys are built
          independently.
          
          Luigi: Crypto would be nice to see.
          
          
          Luig: I had a second question about multiple multiple IEDs and multi
          IID. When I install a new application I have to figure out which key ID
          to use which IID to use?
          
          
          Dino: Defaults to adding that but it could add any type of routes it
          have to be destination based. You would have to say anything that so if
          I'm a cisco employee anything that goes a Cisco use my VPN now. How to
          do it seamlessly for the user  is up to implementation.
          
          
          Luigi: Do you need to jailbreak your iPhone to install this stuff?
          
          
          Dino: You can download the latest version at the app store so if anybody
          wants to try it go ahead and I'll give you the addresses of the RTR
          actually you already know them.  So I'm expecting a DOS attack after this
          [Laughter]
          
          
          
          - Distributed Geo-Spatial LISP Blackboard for Automotive
              - https://tools.ietf.org/html/draft-barkai-lisp-nexagon-05
            20 Minutes (Cumulative Time: 100 Minutes)
            Sharon Barkai
          
          Discussion:
          
          Fabio: I  want to make a comment on why I think this use case is very
          interesting for LISP.  We are seeing a use case that brings together
          the use of mobility with an overlay, the use of the mapping system to
          map something not as traditional as EID/RLOC mapping as we have done so
          far and also that tries to take advantage of the locality of the service
          offer by the market servers that are storing the demand itself. Then on
          top of that, using signal free multicast to basically reach efficiently
          all the devices that are subscribed to a certain information. So it's a
          combination of use cases that are basically bringing together things that
          in the last few years we thought were possible with LISP.
          I agree that
          this is specific to this particular use case but I think is not very hard
          to think of other use cases that are not related to vehicle mobility and
          traffic road conditions that may have similar attributes. You may want to
          have a basic mapping service that is highly distributed available at the
          edge of the network that offers you quasi real-time information. I think
          this is very general in many application that we see coming. That's why I
          think there is a lot of value in working on this use case and basically
          trying to see how all the things that we have done in the LISP working
          group fit together and it would be interesting to see if there are new
          things that are needed. It's very nice to see that so far most of the
          requirements that Sharon articulated seems to be addressed by what we
          have in the overall LISP.
          
          Dino: If we just wanted to publish this as a use case and made it
          informational RFC what are the steps we have to go through?
          
          
          Joel:  The question of how to advance the document turns on a different
          point than the IETF procedures in terms of our Charter. It's okay we could
          publishing the informational document because this deals with geolocation
          topics. I'm trying to find out from the geolocation experts here at the
          IETF. We may want to make sure that appropriate review from the teams who
          have dealt with these problems before because this is not a new topic
          to the IETF. The usage is new but the general topic of communicating
          information about geo locations and such like his one that they've worked
          on a lot. I'm going this week to talk to some of the people who've been
          involved with that historically and figure out a good path because when
          speaking personally, not as chair, I like the work, as chair I need to
          figure out what the best way is to get the appropriate review.
          
          Sharon: It's true it's geo state but the thing here is that it's a
          brokered Network meeting.  It is shared state there's not very geo state
          
          
          Joel: Historically there's been sensitivity when we deal with geographic
          information so I want to make sure we get the review and involvement for
          people have been in that space and I don't care which working group ends
          up owning the problem. It may be that what we'll do is ask you to present
          this material at the ops area next time or something. I've got to talk
          to folks. I've talked to one of the ops ADs. It turns out Richard Barnes,
          whom I'm on another committee with, was very active in that area.
          
          Sharon: On a personal note  appreciate this peer review to keep grilling
          this thing.
          
          
          Joel: We're not gonna throw you out of LISP don't worry .
          
          
          Dino: Was that a response to making it informational or just any type
          of work?
          
          
          Joel: Just whatever type, it looks to me like it it's mostly
          informational it needs just to find a new LCAF but that's all and the
          LCAF for registration procedures would allow that but that's not in the
          picture as far as I'm concerned.
          
          



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