* 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 —  

IETF-102 lisp minutes

Session 2018-07-19 1330-1530: Van Horne - Audio stream - lisp chatroom


minutes-102-lisp-00 minute

          LISP WG @IETF102
          Chairs went over the agenda and the WG document updates.
          Chairs stressed the need for ALL authors to disclose IPR in a timely
          manner for documents to progress.  In some of the bis documents there
          are no disclosures but in the original documents there are IPR from
          Huawei. Therefore, the write up will state the original documents have
          IPR that may apply.
          o Non WG Items
          - LISP Data-Plane Telemetry - draft-farinacci-lisp-telemetry-00.txt
          Presenter: Dino Farinacci
          Dino presented a sneak preview of the draft.
          LISP xTR can characterize performance of the underlay, more performance
          data enables more informed decisions. The -00- draft is identifying the
          desirable parameters. Use of RLOC probe.
          Erik: We should consider the coloring for packets for measurement of
          packet loss.
          Dino: Good suggestion
          Luigi: The only ETR that can ask you about the telemetry data is the
          one talking to you why? Why others cannot ask you about telemetry of
          data on a mapping?
          Dino: We do not want to flood information to anybody that just request
          it. We want to actually sign map requests and validate them. If a source
          wants to make decisions unilaterally we do not need a management plane.
          - LISP Control-Plane ECDSA Authentication and Authorization -
           Presenter: Dino Farinacci
          Dino: Presented a brief overview.
          -       authenticate and authorize xTR using the mapping system
          -       How to sign map-registers/requests.
          -       How to store public-keys in MS and introduction of crypto-EIDs
          Joel: how does that look up on the hash fit …. where it’s supposed
          to be the tree is based on delegation, just arbitrarily map it on the
          tree or ?
          Dino: The hash that you look up is appended to an ascii string called
          hash. It is a distinguished name as the EID in the EID record and DDT
          can build hierarchy on any ascii character in any string.
          Erik: I can secure it because we have 120 bits
          Victor: have you considered multiple signatures
          You may want to be crisp of what you want to be signatures
          : Terminology EID/signer EID is confusing
          o WG Items
          - LISP YANG Model - draft-ietf-lisp-yang-08.txt
          Presenter: Reshad Rahman
          Reshad: went over the changes between 07 and 08 (see slides)
          Ready for WGLC
          Need more input from the WG
          For the chairs do we think after these changes that the document is ready
          Joel: is the document stable or not?
          o Non WG Items - continued
          - LISP Control Plane for SRv6 Endpoint Mobility -
          Presenter: Alberto Rodriguez-Natal
          Alberto presented the use of LISP-control plane for SRv6 basic ideas
          but there are refinements underway for next version.
          LISP is “where to go”
          SRv6 is for “how to go”
          Removed TE in version -01
          Disjoint resolution Slides
          Dino: Regarding to pub/sub MSMR even if the RLOC does not change but
          SR source route changes then it looks like a mobility that has to be
          Alberto: that is in the next model. Here we assume that the SR path is
          computed and is from egress and it is disjoint.
          Dino: This is sending a new precedent. In the EID mobility draft whenever
          the RLOC changes, we trigger map registers, pub/sub, data triggered
          SMRs. I do not remember if we say that if the contents of the RLOC record
          changes vs RLOC address changes.
          Joel: What they put in the RLOC address is not the segment route, it is
          the label for the policy for the segment route to go ask the PCE.
          Dino: I did not want to bring that up but that is another issue I have
          with two stage lookups
          Joel: The policy did not change so there are no changes in the mapping
          Dino: Not a criticism on SR. Look at this as just an EID mobility learnt
          over an MPLS cloud and the label switches for the underlay … that is
          the same case here where the RLOC does not change just the label changes
          because you have a new TE path. I do not know whether we have language
          about the characteristics of the underlay has changed.
          Joel: you have to trigger something to indicate that here there is
          nothing to change in the MS. Don’t know how you would do it.
          Joint resolution Slides
          Dino: what if the SR policy does not change but the reachability of a
          segment change.
          Darren dukes: PCE would then notice that change, compute a new path and
          notify the MSMR of the new path and that would then get distributed down
          to the ITR.
          Dino: All ITRS?
          Darren: All ITRs or all ITRs interested in this binding.
          Open Questions:
          Dino: I want you to give a statement about the 2-stage lookups.
          Alberto: In the draft, we have both single and 2-stage look ups as
          separate options. There will be refinements as we go forward.
          Dino: So, in the first model the SR is directly in the LCAF record.
          Alberto: In the first model the information needed to compute the SR
          path in the underlay is in the LCAF.
          Victor Moreno: Question on the single look up .. once you get the update
          from the PCE, is the thought to actually push the update to the ITRs or
          are you going to send a map notify the ETRs involved as well then let the
          SMR mechanism take place or is this restricted to pub/sub scenario only.
          Alberto: when there is a change on the policy, the PCE will notify
          the Map-Server, MS will see the change in RLOC information and it can
          do pub/sub.
          Victor: clear for pub/sub but not for SMR mechanism.
          Dino/and Victor: Need to look at the EID mobility draft to see if this
          cover this specific case.
          Dino: In reference to Luigi’s question on telemetry about why should
          the ETR give the information back to the ITR – this is a good example
          here where an ITR may have two RLOC records and two segment routes. So,
          you may want to RLOC probe twice to explore the different paths as these
          paths are sourced based you have this directionality problem.
          Luigi:  You do not use the  lisp encapsulation but you do not say
          anything in the document. In principle, you could use it and benefit
          from all the functionality it comes with.
          Alberto: Technically you could.
          Luigi: Clarification in the document would be desirable.
          Darren: Your question about doing LISP encap and SR traffic engineering
          may be on that needs to be looked at in there.
          Dino: Back to ABC slides. Glad Luigi brought this up as it begs another
          question. Why can’t A, B, and C be RTRs and you encapsulate at each
          point and if you do that you get RLOC probing between each component of
          this source route, this is exactly what LISP TE is doing with ELPs. So,
          one can argue why do you need SRv6 because if you put that RTR topology
          in there, the underlay between A-B and B-C can be a combination of IPv6
          and IPv4.
          Victor: you brought an interesting scenario where you can have SRv6 with
          LISP and no traffic engineering and in that case, what are your thoughts
          of subsuming the PCE functionality into the MSMR.
          Luigi: why PCE?  We could have PCE or the MS do it.
          - Ground-Based LISP for the Aeronautical Telecommunications Network -
          Presenter: Fred Templin
          Dino: You said the planes are multihomed .. Do they use both links at
          the same time?
          Fred: They can.
          Dino: What is the addressing when they are using both at the same time.
          Fred: They use the same EID over both links. You may have differentiated
          service code points for some traffic points.
          Dino: Have you considered both BGP and LISP at the same time?
          Fred: Yes
          Luigi: About ICAO, how soon will we know their decision? Are they
          considering the solution right now?
          Fred: ICAO is trying to push a solution adopted soon. But whether this
          solution is going to be a pure LISP or pure AERO or mobile IPv6 or a
          hybrid of those is still under process.
          Brian: Have you considered to have the planes as a mesh network to
          relay packets
          Fred: interesting idea. Are you thinking of air-to-air links? we think
          about that when we talk about drones but not so much about civil aviation
          -  A Decent LISP Mapping System - draft-farinacci-lisp-decent-00.txt
          Presenter: Colin Cantrell
          Joel: It seems there is a mix of at least two different sets of requests
          which come from different parties and it is confusing.  Map Registers
          that come from other ETRs. While the ETR is one of your DHT elements
          so it would not be sending Map-Registers. Their Map-Request which come
          from ITRs to Map-Requesters not Map-Servers and now who is going to prove
          work? Because the request has to go across the DHT to the authoritative
          node. Looks like he is going to ask the trusted party to end up doing
          work because the trusted party is getting besieged with requests which
          he has no way to ask for proof of work.
          Colin: it would be agnostic to the message and theoretically scale it
          based on the actual computation requirements of each message. That is
          still something that is being thought out.
          Joel: Doesn’t answer the question. My point is that Map-Requests come
          from ITRs to the edge of the mapping system. You haven’t talked about
          these entities and these are not asking for proof of work, so the proof
          of work is coming from the authoritative node. By the time you ask the
          authoritative node to ask for proof of work to somebody else then
          a.      Seems to be the wrong question
          b.      He is asking the wrong party – a trusted member of the MS and
          not the ITRs
          Unless you are also changing things so that the ITR as members of the
          mapping system?
          Colin: In a decentralized mapping system, the word trust is generally
          disregarded because anybody could be a malicious actor. This could
          mitigate that in the sense that even a Map-Server could be malicious.
          Joel: Then you are talking about a very different DDoS that everybody
          else worries me.
          Colin: There are a lot of different factors and do not have answers for
          all of them in this preliminary architecture to may be facilitate the
          idea of a potential use case.
          Dino: Separate all the XTRs being part of the MS from DoS attacking
          the MS because we could protect DoS attacking the MS when it is not
          decentralized. Think of MS today and how we could use proof of work to
          slow down attackers
          Joel: That is a major change .. not to the mapping system but to the
          interface which we have defined as stable. There is a difference between
          mapping system operation and we’ve structured this so the new mapping
          system is transparent through the external interfaces and changes to the
          external interfaces.  This looks like it takes changes to the external
          interfaces. It is not out of question but you want to make it clear if
          you want to present it here.
          Colin: from what I understand we would not need to modify too much
          of packet structure you would be able to use existing and check for
          zero bits.
          Joel: Need some extra messaging to about meeting constraints…
          Colin: that would be exactly the message on the Map-Reply .. We were
          talking about using some high order bits .. 64 bits …
          Dino: Right. The idea would be that the ETR would do the proof of work
          and the hash doesn’t have to be sent in the map register and only
          the nonce. We already send the nonce today. On the other side is guy
          who takes the nonce and hashes out the packet and determines if it is
          good/bad. Change the level of difficulty if we know we have a map notify
          which is an Ack for the register. The Map-Notify that you send back
          could have a difficulty value so as DoS attack increases the difficulty
          of proof of work increases.
          Joel: All I am saying is that you need to put something in the messages
          so that you know what is the difficulty level you got to meet.
          Victor:  Seems you have two things here the decentralization of the
          mapping system and this and you may need two separate documents.
          Joel: There is assumption that this is an environment in which not only
          are the XTRs highly distributed but any XTR is perfectly ok to claim to
          be service any EID as long as no one else is claiming to do so
          Colin: No. When you as a distributed ledger on top of this then there
          is a reputation system so that somebody’s claim is not just a claim
          out in the open abyss. You actually have a masterful verifiable trail of
          somebody’s trustworthiness that you can have a distributed trustless
          system by mathematical verification.
          Joel: then you will need to give a lot more details on how this will work.
          Joel: the relation of who is allowed to register and so on.
          : There is a lot of work going on and need to be careful how to separate
          the documents
          Dino: Albert and his team has been doing a lot of work on how blockchain
          technology in general and there are ideas on how to enhance the mapping
          system to do prefix openness and allocation …
          Rajiv: There was a need for DNS to begin with.
          Relying on third party? Does that reduce the efficacy?
          Colin: Not necessarily. DNS is just a convenient but it is possible not
          to rely of the DNS.
          :  possibility of being malicious on the other side.
          Colin: With consensus, you do not have to talk to one node but to
          multiple. They give you a list of malicious addresses. This is why
          you do a full validation of the ledger on your local node to verify
          all the cryptography so even if they try to send malicious data it can
          be detected.
          Rajiv: Assuming they do not have the majority.
          Colin: Yes. This is what is called civil attack, which requires a lot
          of computation power for proof of work and validation of state.
          Dino: People ask what is decentralized Internet? If you are using DNS,
          it depends on the third party. Where it is and who is managing it. I
          like to think of it this way and we use something like LISP Decent and
          every XTR is mapping system or a Map-Server. I like to think of it as
          a neighborhood of devices that have local connectivity If you do not
          have multicast you can still rely on DNS but where it is all local and
          trusted among that trust group of the neighborhood.
          DNS is decentralized in a trusted environment
          Joel: AFAIK none of the arguments for deployment for LISP match what
          you just described. DNS are usually scattered across the internet and
          not locally connected. If they service one data center (opposite case)
          then they are clustered and are under a single administrative control and
          don’t have a distributed trust problem. So be very careful describing
          the problem. Block chain have interesting properties.
          Colin: Supply chain management, auditability and immutability of data so
          that’s where you create trust and where mathematics is used to verify
          the truth. So, in a sense you could call block chain or distributed
          ledger a truth layer of the internet which is something that we do not
          really have now. The truth is determined by global consensus and the more
          people we have validating and that consensus, the more you could consider
          that truth, so it give layers of abstraction that help give an improved
          frame of reference. There is a significant improvement that can be done.
          Why decentralized internet? It makes it more robust and it removes it from
          central points of failure and also for central points of control. So,
          peer to peer networks are robust and have high percentage of uptime. We
          need fall back if a Map-Server gets put under a DDoS attack, you have a
          distributed mapping system now. There are trust issues associated with
          that but this is where the DLT hopefully can help. DLT relies on robust
          nature of peer to peer and sort of run less reliable on such network
          would require this distributed topology. The problem of getting the
          full mesh topology and what we have is what LISP is actually bridging
          for Nexus significantly. The decoupling of your routing locators and
          endpoint identifiers and being able to tie that to a cryptographic
          identity so that you can actually be reached and I can know somebody
          is somebody and that they can prove who they are by signing from the
          specific key in a signature chain and I can look up not just from the
          EID I can look up their whole track record if they validate it. It gives
          you a better auditable trail of events that you can use to create better
          selection bias.
          Dino: I just want to add to your last point, the idea here is that
          crypto–EIDs give you Identity at the network layer and crypto-currency
          wallets gives you this identity that is very changeable because you
          have different set of parameters when you change it at the application
          layer. The question is – can the security of this application layer
          help the network being more secure and vice versa. LISP security helps
          the application be more secure.
          Colin: That the idea with layers of abstraction, if you add a ledger layer
          on the OSI then that ledger layer can have an API that’s accessible
          from LISP layer or layer 3 which then be able to ask the ledger about
          certain things or certainly IDs or certain Map-Servers and be able to get
          actual data from there so that the network layer can be less spoofable
          and vice versa. When the ledger can actually recognize the IDs through
          that and have trust – they are going to know that nobody can spoof an
          ID. You can use a VPN or whatever but I know I am talking to the same
          EID and I see a cryptographic proof that this person is who they are
          based the distributed ledger.
          - Overflow Time/ Discussion
          Dino: what is the decision for the OAM document? Do we have or not an
          OAM document, if not are we losing the text we pulled out?
          Luigi: It is not blocking the bis documents because there is no reference.
          Sent an email to Dino and Albert on next steps.
          Dino: We are not questioning the effort of building a separate document
          but it is the principle of having it in the third place.
          Joel: We are trying to get everything else unstuck.
          Dino: We are at a stalemate.
          Joel: Moving forward without waiting for it.
          Dino: We are losing text.
          Joel: It can be recovered by somebody … but it doesn’t block getting
          to PS.
          Albert: Is it part of the charter or not?
          Joel: Yes, but it does not have to be part of getting to PS. We want it
          but where it was. If no one wants to write it what interest in the WG?
          Dino: Not a question of interest in the work. People have implemented
          that text. It is going to be lost and the only way to retrieve it would
          be to go back to the experimental 6830.
          Joel: No someone will write the RFC we want for standards track.
          Albert: For the text if it is in the right context has value. The right
          context was the rest of the RFC.  If we separate the text then we lose
          the context and value. It is does not mean that if no one wants to do
          it that the text has no value rather that you lose value of the text.
          Joel: Well this was not only the chairs arbitrarily deciding but the WG
          felt it is best to remove it and that’s why we are advancing without it.
          Pointers to IETF102 LISP Session:

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