Re: [Ideas] [lisp] IDEAS @IETF98 Minutes

[Sharon <[e-mail]>]

Discussed these 2 ID networking items with Albert and others, perhaps this is a good thread:

1. MAMBO - 

Map-Assisted Measurnent Based Overlay
The notion here is that identity based overlays offer global (map-assisted) choices hop by hop underlays do not. One factor in making these choices can be by measuring the pearson correlation coefficient (pcc) between the tunnels. If considered when selecting between VTEP X or VTEP Y to reach a multi home EID or a load balanced EID it can double-quadruple overall overlay capacity. 

2. Lisp-Lambda -
A serverless (or virtual-appliance-less) alternative to service function chaining which is hard to scale and dev-ops. Its done by mapping flows at the ITR, ETR, or STR (segment) to queues, and using the mapping to invoke the (cached) function on the flow queue packets rather then hair pining the packets in and out of function virtual appliances. Saves nic-ram-nic-ram... costly lifting.

There are reference implementations and simulations to both if theres interest. 


--szb

> On Apr 13, 2017, at 12:01 AM, Padma Pillay-Esnault <[e-mail]> wrote:
> 
>  
> 
> 
> Please find below the minutes of the meeting.
> 
> Many thanks to our two scribes: Toerless Eckert and Uma Chunduri.
> 
> 
> If you have any comments/corrections please let us know.
> 
> Thanks
> 
> Padma
> 
> 
> 
> IDEAS Side Meeting Minutes 
> 
>  
> 
> 1. Slides
> 
> Please find below a pointer to the slides
> 
> https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp=sharing
> 
>  
> 
>  
> 
> 2. Agenda 
> 
> 2.1. Introduction and Problem Statement for IDEAS  - Padma Pillay-Esnault
> 
>  
> 
> https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-01.txt    
> 
>  
> 
> IDEAS Introduction
> 
>  
> 
> IDEAS aims to be the forum where common issues across all ID Enabled Networks can be discussed.
> 
>  Goals:
> 
> -       to create awareness
> 
> -       to present the work proposed in IDEAS
> 
> -       A generic architecture that is scalable, extensible, robust, secure, and flexible for future ID enabled networks
> 
> -        to sollicit comments and feedback from the community on the drafts
> 
> -       to call for new contributions
> 
>   
> 
> Problem Statement
> 
> Motivation: Why Now?
> 
> ID solutions can address diverse areas
> 
>             IOT, M2M communication, Discovery, privacy, Latency, Virtualization
> 
> Beneficial to have standardized common infra across ID protocols
> 
>  
> 
> Key Issues Identified
> 
> Lack of common Infrastructure cause harder to deploy a common solution E2E
> 
>   -       No Common Management due to disjoint nature
> 
>   -       No Common/consistent policy framework
> 
>   -       Risk of fragmented communication
> 
>  Identifier Lifecycle
> 
>   -       No guidance or allocation scheme for public IDs
> 
>   -       Agreed upon ID format and scope in cross-domain communication
> 
>   -       Recycling IDs
> 
>   -       Better address merging of networks
> 
>  Security of Mapping Systems
> 
>   -       Secured access to the MS
> 
>   -       data integrity, Confidentiality, Anonymity, Access control
> 
>   -       DDOS attack prone
> 
>  
> 
> Proposal
> 
> -       To investigate the opportunity of a new specification effort to address some specific problems from an ID Enabled Networks perspective.
> 
> -       To find a common solution and infrastructure that can be shared by current protocols and facilitate the introduction of new ID-based services while avoiding rehashing the same problems again each time a new service pops up
> 
> -       Generic Resilient ID Services (GRIDS) infrastructure with standardized access and multiple services.  The services include
> 
>       -       secured registration
> 
>       -       discovery
> 
>       -       updates with data integrity,
> 
>       -       mapping and resolution capabilities,
> 
>       -       define relationships between IDs or group of IDs
> 
>       -       access control policy and security
> 
> - Other Related Work/ Groups
> 
>        - LISP (ALT, DDT)
> 
>        - HIP uses DNS
> 
>        - NVO3 WG
> 
>  
> 
> Questions:
> 
> Eric Nordmark: What’s unclear is what is out of scope re. Identifier. Are you considering "what is an identifier", clearly this is not about URI, how about IP in IP with IPsec ? Is one of them an identifier the other one a locator. Even LISP was not clear cut between locator/identifier as one could be routed locally.
> 
>  
> 
> Padma Pillay-Esnault: Regarding scope, the way we thinking about this, there can be multiple scopes with multiple allocation systems. The range of solutions is so vast that it may not be appropriate to only have one solution. Plenty options of where to put it and how to put. GRIDS can be used as local, proximity, global instance just as possible to have Private ID.
> 
>  
> 
> Bob Moskovitz: Concept of Identity and Identifier is important and  I have been involved and saw some form of this for the last 20 years may be more. It really does to be discussed in the list. Definitely it needs to be fleshed out a lot more about
> 
> what identifiers are, should be part of the work, tough problem with lots of opinions.
> 
>  
> 
>  
> 
> 2.2. Requirements for Generic Resilient Identity Services (GRIDS) in IDEAS  - Alex Clemm
> 
>  
> 
> https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt
> 
>  
> 
> - This is the core infrastructure document which captures all requirements
> 
>      - Talked on Core components of GRIDS
> 
>      - GRIDS-MS, GRIDS-IS are covered
> 
>      - Grouping and Meta data are not described yet
> 
>      - Identity and Identifier definitions elaborated
> 
>      - Talked in details about mapping services
> 
>      - Identity related services are detailed
> 
>           - Structured and unstructured identifiers
> 
>           - Grouping related services
> 
>      - Requirement (Distribution, Redundancy, Performance and Scale..)
> 
>      - Key performance requirements
> 
>      - Security requirements
> 
>      - GRIDS should be able to be deployed in private space as well as in public domain
> 
>  
> 
> - The naming evolved from mapping system, which was too functionally constrained.
> 
>  
> 
> Questions: 
> 
> Ravi Ravindran: Trying to understand scope: trying to expand LISP ?
> 
> What is the scope ? 
> 
>  
> 
> Alex Clemm: No, not planning to just "expand lisp", that should be done in LISP WG. Some of those questions are better answered in the use cases, clear which ones are not resolved by LISP.
> 
>  
> 
> Benjamin Damm: How is this different from Multicast DNS ?
> 
>  
> 
> Bob Moskovitz: I can totally implement everything in GRIDS in DNS but that would not be a great idea but there would be a lot of
> 
> problems, DDoS, etc.. Think that metadata is not optional but must be called mandatory. Determined by use case.
> 
>  
> 
> Alex Clemm: Note taken
> 
>  
> 
> Dino Farinacci:  rfc8060 defines multiple RLOC types, eg: LISP can support those. Does this look like multicast DNS ? No, this is network layer mapping information mapping addresses to addresses.
> 
>  
> 
> Eric Nordmark: Multicast DNS is a local service, this is meant to be global.
> 
>  
> 
>  
> 
> 2.3. A Blockchain-based Mapping System - Jordi Paillisse 
> 
> - Blockchain is decentralized and secured
> 
>      - Add blocks of data one after other
> 
>      - Blockchain work flow
> 
>      - Transaction with a data, Senders Signature and Senders Public Key to a P2P network
> 
>      - Properties
> 
>         - Decentralized, No prior trust is required
> 
>            Data can be added but not modifiable
> 
>      - Basic Idea
> 
>         - Store mappings in blockchain
> 
>         - EID prefixes are distributed to all participants
> 
>      - Pros and Cons
> 
>         - Infrastructure less, Decentralized, fast lookup, secure, no prior trust, simple rekeying
> 
>         - Cons
> 
>             - Slow updates, costly boot strapping
> 
>      - Comparison with LISP DDT
> 
>         - No Infra, easy management
> 
>      - Issues with RPKI
> 
>          - Anonymity (prefix linked to owner name)
> 
>          - Revocation issues (block chain doesn’t use certificates)
> 
>      - Scalability
> 
>          - Growth similar to BGP Churn
> 
>          - Prefix delegation + Mappings
> 
>      - Design considerations
> 
>            - Bitcoin is too restrictive
> 
>            - New technologies - More scalable and more contracts
> 
>      - Dedicated chains..
> 
>  
> 
> Questions:
> 
> Toerless Eckert: what is the incentive model for participants to deploy the necessary infrastructure for this system ? In bitcoin, the security is achieved  through tremendous amount of calculation, the cost for that hardware is financed by handing out bitcoins for successful calculations. Do we need to hand out IPv4 addresses to pay for IDEAS bitchain calculations ?
> 
>  
> 
> Jordi Paillisee: Good question, there are some new blockchain methods with other incentive structures. See references on last slide of the slide deck.
> 
> Regarding incentive it is about security.
> 
>  
> 
> Dino Farinacci: 
> 
> When a new registration added (Say Jordi first and then 100000 more records added. Now the entry moved to the end. This solution will have
> 
> complete history of movements. Q1: can the really old stuff be chopped off. Q2: if RLOCs change etc. is it not really slow when you need to look through a lot of other newer mappings ?
> 
> Jordi Paillisee : Q1 Answer: It can be mitigated through implementation
> 
> Q2 answer: implementation detail. Database should have latest data for all entities, not in sequential order of evens.
> 
>  
> 
> Manu Sporny: Blockchain developer. Referring to blockchain group (w3c-blockain group) met in the morning, sees overlap with that work, how could we create alignment. Whom to talk to coordinate ? 
> 
> Padma Pillay-Esnault: Let’s discuss this offline.
> 
>  
> 
> 2.4. Use Cases for IDEAS - Tom Herbert
> 
> https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt
> 
>  
> 
> - Mapping essentially a distributed key/value store
> 
>        - Key is fixed size per mapping DB
> 
>       - Maps "virtual address" to "physical address"
> 
>        - Mapping table is assumed to be distributed and possibly shared for load
> 
>        - Rate of entry is important characteristic
> 
>  
> 
>        - Use Cases:
> 
>               - Common Control plane
> 
>               - Mobility
> 
>               - Network Virtualization (for network simplification)
> 
>               - Heterogeneous Multi-Access (hetnet)
> 
>               - Security
> 
>               - Device Discovery
> 
>        - Mobility
> 
>            - Map entity to its current location for forwarding
> 
>            - Variants         
> 
>                - Encap: IP Mobility, IPIP, GTP etc..
> 
>                - ID/LOC: LISP, ILA
> 
>            - Properties
> 
>        - Mobility sub-cases
> 
>            - Within a single mobile network
> 
>            - Mobility between mobile networks
> 
>            - Multi-homed devices
> 
>            - Hetnet environments
> 
>            - Whole networks are mobile (WIFI in bus)
> 
>        - Network Virtualization
> 
>            - Variants
> 
>               - Encap: Map virtual IP address to Physical address
> 
>               - ID/LOC split
> 
>            - Properties
> 
>               - Mostly in DC
> 
>        - Address resolution static tunnels
> 
>            - Could be used as alternative means to resolve L2/L3
> 
>        - Host Routes
> 
>            - A network could implement virtualization simply by creating a host route
> 
>  
> 
> Questions:
> 
> Bob Moskovitz: We have been mobile since 1993. We need to start looking at mobility as baseline. Would almost challenge in discussion the starting point. Take rate of mobility (how fast it can move) as distinguishing attribute.
> 
>  
> 
> Tom Herbert: Agree. How quickly is my "device" going from one network to another. With higher rate, updates become a problem. Also get more and more use cases where latency becomes an issue. Hope we could avoid relying on a distributed system. Control path is critical system, keeping everything in sync with low latency and secure, reliable, available. Can we design this system with applicability across different use cases.
> 
>  
> 
> Mike McBride: There are applications like AR/VR that have strict requirements hopefully, that is also included in use cases.
> 
>  
> 
> Tom Herbert: Yes this has been discussed in the draft.
> 
>  
> 
> Padma Pillay-Esnault: Yes there different strict requirements depending on the different use cases. Earlier there was a question regarding IOT use cases. The requirements may vary for example depending if the type of IOT device. If it battery  operated (supposed to last 10 years) then it may have only one way communication (such as a pet tracker or sensor) and may even be on non-IP. In some cases proximity and context may be important too.
> 
>  
> 
> 2.5. Mobility First and Global Name Resolution Service - Parishad Karimi
> 
> https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt
> 
>  
> 
> -Name based communications
> 
>       - Name based Architectures IP ==> LISP, HIP at IETF MF and NDN (in academia)
> 
>       - MF - Mobility First Background
> 
>          - MF started in 2010 under NSF, FIA
> 
>       - MF Protocol Layers
> 
>           - GUID (global Unique Identifiers)
> 
>           - We seek to use global name resolution system for resolution
> 
>       - Name Resolution Requirements
> 
>           - Low propagation and response Latency
> 
>           - Storage and load scalability
> 
>           - Security and reliability
> 
>           - Extensibility and flexibility
> 
>      - Structure of mapping should not be limited
> 
>      - Why can’t DNS can be supported (DNS Deficiencies)
> 
>           - TTL based caching
> 
>           - High Mobility makes caching ineffective
> 
>           - Static Placement of AUTH Servers
> 
>           - Reliance on hierarchal (relating root)
> 
>      - For MF we have looked into DMAP and GMAP and Auspice
> 
>      - Comparison of all three systems
> 
>      - Conclusion - We need a global mapping system with MF project
> 
>  
> 
>  
> 
> 2.6 Conclusion & Next steps - Padma Pillay-Esnault
> 
> Where do we want to go from here ?
> 
> Next Steps Slide:
> 
> - We need more collaboration from the community and looking forward for more participation on topics such as Blockchain and distributed trust, Late binding, Fast Caching, Security, DDOS protection ....
> 
>  
> 
> - Let’s take discussions to the alias
> 
> - Discuss the scope of work 
> 
>  
> 
> 3. Other Info
> 
> Mailing list: IDEAS
> 
> List address: [e-mail]
> 
> Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas
> 
> To subscribe: https://www.ietf.org/mailman/listinfo/ideas
> 
>  
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp