From nobody Sun Dec 11 08:50:59 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A40129435 for ; Sun, 11 Dec 2016 08:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciRIgAannz82 for ; Sun, 11 Dec 2016 08:50:55 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78EE1293E8 for ; Sun, 11 Dec 2016 08:50:54 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x190so63088507qkb.0 for ; Sun, 11 Dec 2016 08:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=U0ah7AlUopn28Yb9FOpn9GNnNFIliwFgfGdsXFqPU70=; b=uyt+0e67X631hvB+1xmnHAVN/vaHYjvJgX0AvI6mKqC01AC6Ye4sZ97kXa6KdeXZvs NcnqJ1fQXh1UR5loGffe5xwpVOQVyc3YLKjkSpm5t+Ug8bE07FJAzE3JUJ5l2+DO5csD SbJZvpGj7smMd1gCDDe0PW4kxIjQbbCa96pqqC3fkKc6+neP5U17+ur9LQDAE8dWS5aU b8rAEUn9vfSg6PDqBVk+0XzGvshKaa0g/Kom2lCwMgg3lzPSaxQ8gmgpCWVVzwhECC/V 9VSD0B8bpcvQsFoCuC0FBughytuQCuG1pN3fpIVS3vM8VqkWNzxkWW1cHVhg40jV1tAL 89bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U0ah7AlUopn28Yb9FOpn9GNnNFIliwFgfGdsXFqPU70=; b=Pu4OHKdxsRIOaEygmTRaQXOxl+gk/1roIzwfxSEdzyRlxaqWdEU6MMYr1MhbTkqoyA D7rYiq+htF28OizDXG10hI9Vv+ndSJWNks1oy422Px3arpdwZYo4elM6VzUUPH6L5Nm8 WI7XCSZC2vWmw23JR/DsQswltfSWSPn+fxGlduszTjje2dJiACotjwtE4LHHAd7cyoVE OWj0CYGMwgAoKPEe1ggOkQ1KAvDXpg/FQHdg7e4TcrawCxxPr8EuYSZ1nyAvoj6AGcIa 3k5HLyR710gFdrmC7H/k5SMrgD2k9RMOAh3GXrqmTkXnqGIy3B5La9XV9M32v3q+uCHo PL4Q== X-Gm-Message-State: AKaTC03eoX9X31XLFDeEnLI4K8OCnTDFGdVibN40ODbSJUOtiqqyZfpWIklF6SluzME2zkVHZbpXPMBONUsuXw== X-Received: by 10.55.78.146 with SMTP id c140mr76276254qkb.55.1481475053606; Sun, 11 Dec 2016 08:50:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.198 with HTTP; Sun, 11 Dec 2016 08:50:53 -0800 (PST) From: Padma Pillay-Esnault Date: Sun, 11 Dec 2016 08:50:53 -0800 Message-ID: To: ideas@ietf.org Content-Type: multipart/alternative; boundary=001a114a72de505da6054364ca42 Archived-At: Subject: [Ideas] Minutes of IDEAS side meeting @IETF97 X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 16:50:57 -0000 --001a114a72de505da6054364ca42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello IDEAS! Please find below the minutes of IDEAS side meeting @IETF97. Thanks to all of you who attended the meeting and to Les Ginsberg for taking minutes. Please take a look and let us know if there are any changes needed. Looking forward to your contributions. Padma IDEAS Side Meeting Minutes IETF97 1. Agenda Padma Pillay-Esnault (Huawei) - Introduction on problem statement for IDEAS (10 mins) Presented the problem statement draft and the Use cases. Robert Raszuk: Should we define what identity is? Padma: Agree. The document take a stab at this by defining identities and in which context. There is a table in the document that captures the different aspects of ID usage, allocation and its impact on a dynamic mapping system. Sam Aldrin: What is primary focus? What problem are you really trying to solve? Narrow the scope - or are we trying to define a problem because we have a solution? Padma: The primary focus is the design and deployment of a dynamic mapping system. The Problem statement discusses in detail the problems we are trying to solve. Among those many problems is Session continuity in mobility which is important as we have more and more mobile modes in cellular as well as ip mobility(DC). Another important problem that can be solved and is discussed in the paper is Cross-silo communication. Encourage everyone to read the document. Luigi: We have multiple encaps and mappings and want to manage in a common way. But what is a common ID? Please clarify. Padma: In this case we are not necessarily looking for a common single ID. What we are trying to do is to map an ID to location. So that we can have the Identity dissociated with the locator so that mobility is fully supported. What we are proposing is to have a common control plane that have access to a mapping system used by all. It is not very practical to deploy one global mapping system per protocol or application. Luigi: Do we have to solve who is allocating the ID? Maybe we do not have to solve this problem. Padma: Well it depends. We have both the case for public and private IDs. For public IDs to be used by a common control plane, we will require some rules. Luigi: But what form will the ID take? Dino: Different EID types for different purposes. Hopefully they will be used for different purposes. Should it be geographical, first come first served, assigned at birth,...many types allocated differently. L2 overlays have the MAC address. ID allocation independent of database. ~General discussion about EID types and mapping systems. Bob Moskowitz: I am the Last member of the EID cabal. :-) Many discussions have been already What characteristics required of an EID? What is good/bad? Capturing that would be good. There is two decades of experience available =E2=80=93 would be good to make use of that. Padma: There is a table in the draft which captures some aspects of this discussion. How are we actually using IDs today? And how it should be used or restricted. Can we use ID properties to provide better security for example? Georgios: Take into account use cases in 5G and IoT, since they will impose requirements that we did not have up to now. ********************************************************** Tom Herbert ( Facebook) - The ILA protocol and NMS (10 mins) Scale to 100=E2=80=99s of billion aggregate mappings No aggregation assumed, 1%change per second Able to attach ancillary data to mapping Bob: Is this intended to be globally unique? Tom: Globally unique in a domain. Bob: with 7B population w 64 bit # 74% probability of collision. This must be accounted for. Will post the formula for calculating likelihood of collision. Tom: We do have a method to generate unique identifiers. Covers 20 years of experience. Mapping system detects conflicts at registration. Bob: Agreed. But 10 devices/person gives high probability of collisions Kiran: Scope of identifier determined by locator? Tom: Identifiers unique for a domain. Reverse translation requires locator to map back to the original prefix. Ingress/Egress translation. Both sides have to agree on the pairing. Kiran Makhijani: If age out of cache how can you detect? Tom: If we lose ILA routers need to have other ILA addresses available. An open issue Kiran Makhijani: Need to have reliability solution base requirements related to NMS ************************************************ Dino Farinacci ( Lispers) - LISP Mapping system, How it works? (10 mins) Presented LISP Site to access of mapping System, Site Registration 10 years of experience and DDT mapping server. Hierarchical network structure based on EID Allocation 3 levels of hierarchy to get 1billion registrations: 1 Million for 1 MS Multiple mapping systems Tom: With DNS have to wait for resolution - looks like you have same issue w LISP DDT? Dino: Solved by LISP has default cache in ITR. Albert: if you don=E2=80=99t was to resolve, you can set default route to p= roxy RTR which has all the mappings Fabio: Proxy DNS - you send to the router which has all the information. Dino points that if there are too many mappings In LISP we can use proxy ETRs , where requests can be distributed. Tom: In ILA had too many mappings in one device and now ILA does something similar. ************************************************ Gerry Forster ( UoSurrey) - ETSi NGP: GTP, Mobility & Flat 5G Architecture( 15 mins) Presented the mobile network as being most successful system, however GTP is expensive and adds to the cost for whoever is paying for spectrum. The user data is tunneled at least 3 times and GTP need to be updated for mobility. Smaller native headers (most of the time). Presented UoS work. Association-based secure membership of each level of network access Scalable addressing (16 bit most of the time, 52 bit global). 3-level ID-based Mobility (Cluster, Inter-Cluster, Network) Routing tables are local, but indexed for gateway function by 3-level ID lookup (not DNS, but intelligent network hierarchy and Meta-Data). Transmis= sion is tailored by profile to level of access, access type and networking level Lookups/ routes are through intelligent use of meta-data based =E2=80=98Con= text=E2=80=99 =3D ID Enabled Networking Dino: Can we assign IPv6 address but use a 16 bit address? Gerry : Yes - can virtualize end-to-end. Gerry: New protocol for access networks - can do the same for wifi. Dino: Only limit is 65K connections at one time. Gerry: Limit the number of translations or compromise the delay. ************************************************ Fabio Maino(Cisco) - Deployment experience of Mapping Systems ( 10 mins) Presented various use cases and deployment experience Internet based VPN, IPv6 transition, BGP free multihoming, DC host mobility Up to now mapping system in the router. Based on current requirements it is needed to bring mapping system out of the router. ************************************************ Dave Meyer (UoOregon/Brocade) - Machine Learning and Network Mapping System ( 15 Mins) ??: How did you get the parameters from networking? Are they addresses Dave: Just flattened the number - used different parameters e.g. number of map requests? Other parameters - will need to learn what works in the network case. ************************************************ A. Cabellos, J Vilanova & F Maino (UoCatalunya, Ecole P. Lausanne, Cisco) - A Blockchain-based Mapping System (15 mins) Padma: Have you looked at scalability? Fabio: Yes - scales well. ??: Is it clear that use cases are enforcing new requirements other than are provided by LISP (for example)? Will problem scope be different than in LISP? What might be the advantage of IDEAS work rather than LISP? Padma: Out of time - take it to the list. How can we be most useful? Need to work on defining the exact scope. ??:Will it be a BOF? Padma: Not sure yet. 2. Admin & Location Date: Thursday, 17th November 2016 Time : 6:00 - 8:00pm Venue: Studio2 Mailing list: IDEAS List address: ideas@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dideas To subscribe: https://www.ietf.org/mailman/listinfo/ideas Related areas: RTG, OPS Scribe: Les Ginsberg Number of attendees: 40+3. 3. Related Documents and Reads: https://tools.ietf.org/html/draft-padma-ideas-problem-statement-00 https://tools.ietf.org/html/draft-herbert-nvo3-ila-03 https://tools.ietf.org/html/rfc6830 https://tools.ietf.org/html/rfc6833 http://www.3gpp.org/release-14 --001a114a72de505da6054364ca42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello IDEAS!

=C2=A0

Please find below the minutes of IDEAS side = meeting @IETF97.

Thanks to all of you who attended the meeting and to= =C2=A0Les Ginsberg for taking minutes.

=C2=A0

Please take a look and l= et us know if there are any changes needed.


Looking forward to your contributions.

=

Padma<= u>



IDEAS Side Meeting Minutes=C2=A0 IETF97<= /u>

<= /u>=C2=A0

=C2=A0

1. Agenda=C2=A0

Padma Pillay-Esnault (Huawei) - Introd= uction on problem statement for IDEAS (10 mins)

Presented the probl= em statement draft and the Use cases.

=C2=A0

Robert Raszuk: Sho= uld we define what identity is?

Padma: Agree. The document take a sta= b at this by defining identities and in which context. There is a table in = the document that captures the different aspects of ID usage, allocation an= d its impact on a dynamic mapping system.

=C2=A0

Sam Aldrin: Wh= at is primary focus? What problem are you really trying to solve? Narrow th= e scope - or are we trying to define a problem because we have a solution?<= u>

Padma: The primary focus is the design and deployment of a dynamic ma= pping system.

The Problem statement discusses in detail the problems = we are trying to solve. Among those many problems is Session continuity in = mobility which is important as we have more and more mobile modes in cellul= ar as well as ip mobility(DC). Another important problem that can be solved= and is discussed in the paper is Cross-silo communication. Encourage every= one to read the document.

=C2=A0

Luigi: We have multiple encaps= and mappings and want to manage in a common way.

But what is a commo= n ID? Please clarify.

=C2=A0

Padma: In this case we are not nec= essarily looking for a common single ID. What we are trying to do is to map= an ID to location. So that we can have the Identity dissociated with the l= ocator so that mobility is fully supported. What we are proposing is to hav= e a common control plane that have access to a mapping system used by all. = It is not very practical to deploy one global mapping system per protocol o= r application.

=C2=A0

Luigi: Do we have to solve who is alloc= ating the ID? Maybe we do not have to solve this problem.

=

Padma: Well= it depends. We have both the case for public and private IDs. For public I= Ds to be used by a common control plane, we will require some rules.=

= Luigi: But what form will the ID take?

Dino: Different EID types for = different purposes. Hopefully they will be used

for different purpo= ses. Should it be geographical, first come first served,

<= p class=3D"MsoNormal" style=3D"font-size:12.800000190734863px">assigned at = birth,...many types allocated differently.

L2 overlays have the MAC a= ddress.

ID allocation independent of database.

=C2=A0=

~Ge= neral discussion about EID types and mapping systems.

=C2=A0

Bo= b Moskowitz: I am the Last member of the EID cabal. :-)

Many discussi= ons have been already What characteristics required of an EID? What is good= /bad? Capturing that would be good. There is two decades of experience avai= lable =E2=80=93 would be good to make use of that.

Padma: There is a = table in the draft which captures some aspects of this discussion.

Ho= w are we actually using IDs today? And how it should be used or restricted.=

Can we use ID properties to provide better security for example?<= /u>

Georgios: Take into account use cases in 5G and IoT, since they will imp= ose requirements that we did not have up to now.

=C2=A0

******= ****************************************************

=

Tom Herbert= ( Facebook) - The ILA protocol and NMS (10 mins)

Scale to 100=E2=80= =99s of billion aggregate mappings

No aggregation assumed, 1%change p= er second

Able to attach ancillary data to mapping

<= p class=3D"MsoNormal" style=3D"font-size:12.800000190734863px">=C2= =A0

Bob: Is this intended to be globally unique?

Tom: Globally uniqu= e in a domain.=C2=A0

Bob: with 7B population w 64 bit # 74% probabili= ty of collision.

This must be accounted for. Will post the formula fo= r calculating likelihood of collision.

Tom: We do have a method to ge= nerate unique identifiers.=C2=A0

Covers 20 years of experience.=C2=A0= =C2=A0

Mapping system detects conflicts at registration.

Bob: A= greed. But 10 devices/person gives high probability of collisions=

Kir= an: Scope of identifier determined by locator?

Tom: Identifiers uniqu= e for a domain.=C2=A0

Reverse translation requires locator to map bac= k to the original prefix.

Ingress/Egress translation. Both sides have= to agree on the pairing.

Kiran Makhijani: If age out of cache how ca= n you detect?

Tom: If we lose ILA routers need to have other ILA addr= esses available.

An open issue

Kiran Makhijani: Need to have re= liability solution base requirements related to NMS

=C2=A0<= /u>

****= ********************************************

Dino Farinacci ( Li= spers) - LISP Mapping system, How it works? (10 mins)

Presented LISP = Site to access of mapping System, Site Registration

10 years of exper= ience and DDT mapping server.

Hierarchical network structure based on= EID Allocation

3 levels of hierarchy to get 1billion registrations: = 1 Million for 1 MS

Multiple mapping systems

=C2=A0

Tom: W= ith DNS have to wait for resolution - looks like you have same issue=

= w LISP DDT?

Dino: Solved by LISP has default cache in ITR.<= /u>

Albe= rt: if you don=E2=80=99t was to resolve, you can set default route to proxy= RTR which has all the mappings

Fabio: Proxy DNS - you send to the ro= uter which has all the information.

Dino points that if there are too= many mappings In LISP we can use proxy ETRs , where requests can be distri= buted.

Tom: In ILA had too many mappings in one device and now ILA do= es something similar.

=C2=A0

************************************************

Gerry Forster ( UoSurrey) - ETSi NGP: GTP, Mobili= ty=C2=A0 & Flat 5G Architecture( 15 mins) Presented the mobile network = as being most successful system, however GTP is expensive and adds to the c= ost for whoever is paying for spectrum. The user data is tunneled at least = 3 times and GTP need to be updated for mobility.=C2=A0= Smaller native headers (most of the time).

=C2=A0

Presen= ted UoS work.=C2=A0

Association-based secure membership of each level of network access

Scalable addressing (16 bit most of the time, = 52 bit global). 3-level ID-based Mobility (Cluster, Inter-Cluster, Network)=

Routing tables are local, but indexed fo= r gateway function by 3-level ID lookup (not DNS, but intelligent network h= ierarchy and Meta-Data).=C2=A0Transmission is t= ailored by profile to level of access, access type and networking level

Lookups/ routes are through intelligent use = of meta-data based =E2=80=98Context=E2=80=99 =3D ID Enabled Networking=C2= =A0

=C2=A0

Dino: Can we assign IPv6 address but use a 16= bit address?

Gerry : Yes - can virtualize end-to-end.<= /p>

Gerry: N= ew protocol for access networks - can do the same for wifi.

Dino: Onl= y limit is 65K connections at one time.

Gerry: Limit the number of tr= anslations or compromise the delay.

=C2=A0

*******************= *****************************

Fabio Maino(Cisco) - Deployment ex= perience of=C2=A0 Mapping Systems ( 10 mins)

Presented various use ca= ses and deployment experience Internet based VPN, IPv6 transition, BGP free= multihoming, DC host mobility

Up to now mapping system in the router= . Based on current requirements it is needed to bring mapping system out of= the router.

=C2=A0

**************************************= **********

Dave Meyer (UoOregon/Brocade) - Machine Learning=C2=A0 and= Network Mapping System=C2=A0 ( 15 Mins)

??: How did you get the para= meters from networking? Are they addresses

Dave: Just flattened the n= umber - used different parameters e.g. number of

map requests? Other= parameters - will need to learn what works in the network case.<= /u>

****= ********************************************

A. Cabellos, J Vila= nova & F Maino (UoCatalunya, Ecole P. Lausanne, Cisco) - A Blockchain-b= ased Mapping System (15 mins)=C2=A0

Padma: Have you looked at scalabi= lity?

Fabio: Yes - scales well.

??: Is it clear that use cases = are enforcing new requirements other than are provided by LISP (for example= )?

Will problem scope be different than in LISP? What might be the ad= vantage of IDEAS work rather than LISP?

Padma: Out of time - take it = to the list. How can we be most useful?

Need to work on defining the = exact scope.

??:Will it be a BOF?

Padma: Not sure yet.

2. Ad= min & Location=C2=A0

Date: Thursday, 17th November 2016

Time :=C2=A06:00 - 8:00pm

Venue:= Studio2

Mailing list: IDEAS

List address:=C2=A0ideas@ietf.org

Archive:=C2= =A0https://mailarchive.ietf.org/arch/search/?email_list=3Dideas

To subscribe:=C2=A0https://www.ietf.org/mailma= n/listinfo/ideas

Related areas: RTG, OPS=C2=A0

<= p class=3D"MsoNormal" style=3D"font-size:12.800000190734863px">Scribe: Les = Ginsberg

Number of attendees: 40+3.=C2=A0


3. Related Documents and Reads:=

= https://tools.ietf.org/html/draft-padma-ideas-pr= oblem-statement-00

https://tools.ietf.org/html/dr= aft-herbert-nvo3-ila-03

https://tools.ietf.org/html/rfc6830<= u>

htt= ps://tools.ietf.org/html/rfc6833

http://www.3gpp.org/release-14<= /p>

= =C2=A0

--001a114a72de505da6054364ca42-- From nobody Sun Dec 11 09:03:15 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B951293FF for ; Sun, 11 Dec 2016 09:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxk5FLb3-qfH for ; Sun, 11 Dec 2016 09:03:11 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA52C1293E8 for ; Sun, 11 Dec 2016 09:03:10 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id p16so57783731qta.0 for ; Sun, 11 Dec 2016 09:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GdiDTu/MhlivKQqhkwfGszrzGy0IamYT2u6dTENuj1w=; b=lAl/CFeeHIHEIOWa2BKxbaQzdkiPVEK9JSJOOhecGdcahH8YUezMSoP9zNyxAMgKpv ca+Nok7epT1ZlXQ21qUy7xpr5W9M7EBYW8uT1BDGzzeFm1m/viZGX3+jTFwf0WJF99Rl JfF+ncXT+V5qVr6+6ZXuyUCmTcJyjeJRiZhJklBRtyNmGUJUcGFH5QbWwUJVWWupmibc 9K442J47tOp5m9vFU+PsV6vxENQcbZzVZ8abIHPa0gqnsbCIvXyCfSPe75kXmdEifK8P axd3YJaE4MRtNv0z+c9UOeJ4InX0hJoh8oHme7dhsK4Y+wzigg9nzTKgmMxnCmKJ+vXs 0n9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GdiDTu/MhlivKQqhkwfGszrzGy0IamYT2u6dTENuj1w=; b=mb6hxcQsnPxXa+RSEb3RfrmatqCjynbgKkcupQNpP5wxu2xQYcOb0uXtK+0W0TJ8uA m7KTP18zqA4XJpCK1F4KcMjsBckscDQYrVjcrALtjNwLxeo+b678ctgznJ74WquRVbqt REBuTXHMHPfYBK4QlX4jOkWEnPnXlIMOiPnY3rdDpUySATfEeLGzTa7UNcP7OxGEb5cG qF0WbAo6MuNuM8CaT9j9N3dz1mY9R6Di69L44HjJnFdWg/WynQdUz+qqwmgTIUb1hbu3 FRLTjA1/I1e61D7cM6KyJbJOaBFnY3juyMO7Y7wYqe7Rq2dkCjvSP8Uozu2/X7Sy157B YbWw== X-Gm-Message-State: AKaTC00l78yDcWJDDDFpGU8ku8o49biGL+OLW+87UQK7t07PCyC64XioBkmCR5qF4RyzC5uMPvCgjbAybjfO3A== X-Received: by 10.200.52.204 with SMTP id x12mr85471610qtb.193.1481475789960; Sun, 11 Dec 2016 09:03:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.198 with HTTP; Sun, 11 Dec 2016 09:03:09 -0800 (PST) In-Reply-To: References: From: Padma Pillay-Esnault Date: Sun, 11 Dec 2016 09:03:09 -0800 Message-ID: To: Robert Moskowitz Content-Type: multipart/alternative; boundary=001a1137ba20343e31054364f609 Archived-At: Cc: ideas@ietf.org, Padma Pillay-Esnault Subject: Re: [Ideas] Computing collisions X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 17:03:13 -0000 --001a1137ba20343e31054364f609 Content-Type: text/plain; charset=UTF-8 Hello Bob Thanks for sending this formula. If we assume that the population is not necessarily a flat space and that it is in different separate instances, this could help reduce the collision. Per the ideas problem statement draft, we have discussed about the different types of devices and whether we could have some policy on what they can do. Eg. a camera should not be shopping for clothes or access bank accounts .... wouldn't it make sense to put them in different instances with different access policies? What are your thoughts on this? Padma On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz wrote: > Here is the equation: > > probability of collision = 1 - e^{-k^2/(2n)} > > Where n is your max population size (e.g. 2^64) > > and k is your deployed population (e.g. 7B) > > Bob > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > --001a1137ba20343e31054364f609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Bob

Thanks for sending this formu= la.

If we assume that the population is not necess= arily a flat space and that it is in different separate instances, this cou= ld help reduce the collision.

Per the ideas proble= m statement draft, we have discussed about the different types of devices a= nd whether we could have some policy on what they can do. Eg. a camera shou= ld not be shopping for clothes or access bank accounts .... wouldn't it= make sense to put them in different instances with different access polici= es?

What are your thoughts on this?
Padm= a

On T= hu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz <rgm-ietf@htt-consult= .com> wrote:
Here is the eq= uation:

probability of collision =3D 1 - e^{-k^2/(2n)}

Where n is your max population size (e.g. 2^64)

and k is your deployed population (e.g. 7B)

Bob

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas

--001a1137ba20343e31054364f609-- From nobody Sun Dec 11 09:15:44 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA6B12946E; Sun, 11 Dec 2016 09:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNI9ik6A-KEf; Sun, 11 Dec 2016 09:15:40 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6158C129479; Sun, 11 Dec 2016 09:15:40 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n204so63290762qke.2; Sun, 11 Dec 2016 09:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=k7BVP0pwg4/KYayEJ/yX8Mb1v+XjC+j2iacsXGUkSyw=; b=iMIhvDR/iAxuI/OyNFe+jplMLyokPUbsXi6quS9MCKo7bFz+I4ZAAiBChtNkToDgVq obc1rqtOmN0l/gDSiMQamYwraSoSu6oNfbjWCDjyLLh9iDd/X1ThETYVEcMD854x7aea zGycE1TOHl9Rqa9N90WpfGv8IdKYf4eMMcDuC4Cc7SRnAbk5xsqHqbICng9DWVDnHMvb TNq4u5HzepEqUbvlJ3AE/x6pNMsijK/qwDfula0sdyhfm8F0WEd37miQFSSRCiP7EafX XUkPiAB1oYBleUdp6Z70Kwxhy3vo4MPBhoWrhu1Wv6HLAPYTUem48DP3D+f2NQyfz1lc tLdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=k7BVP0pwg4/KYayEJ/yX8Mb1v+XjC+j2iacsXGUkSyw=; b=WbT8qQxZphCL66s1YYpmXIf3HSeqQfB6vyKlMrNz+nUBAxewgttv3d+U8xw4WSQSIk 2b7rnMDILe1c8E8/d7ldhkOyntfpg3VXY342F/AnOVG+vWbpMDyX2DpbhIAaI5pFxIs2 nyGOUr+DZFRlijyNuX4vhLugXixFxi5vOxQ9fzP4xXQBT+2GzV1PL+3NqLLQMWe3hf7h J0MnbOS/o36JlQbDu+CEkAjl6c0DTS5d97PI70D06k+PGLu1SAnIpDSAm+yC56NgRkoN Dz5KtWkdRln6E4rhENe5t+kBm50f7vcr9Yd92Z4qPt8leomPJy8OUupqa/oco7WXewH8 MbNA== X-Gm-Message-State: AKaTC02DwYs5NUGy5wlpbjZr9RU3fwpn4UUkISLyI9ACQPZYNvhi6Cv3vuXqc1mhfsY1z1PonvI8otjCf46zBg== X-Received: by 10.55.183.197 with SMTP id h188mr84595413qkf.107.1481476539342; Sun, 11 Dec 2016 09:15:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.198 with HTTP; Sun, 11 Dec 2016 09:15:38 -0800 (PST) From: Padma Pillay-Esnault Date: Sun, 11 Dec 2016 09:15:38 -0800 Message-ID: To: LISP mailing list list Content-Type: multipart/mixed; boundary=94eb2c06af0adf0261054365226e Archived-At: Cc: ideas@ietf.org Subject: [Ideas] FW: Minutes of IDEAS side meeting @IETF97 X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 17:15:43 -0000 --94eb2c06af0adf0261054365226e Content-Type: multipart/alternative; boundary=94eb2c06af0adf025e054365226c --94eb2c06af0adf025e054365226c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. Feel free to forward. Looking forward to working with you all Padma *From:* Ideas [mailto:ideas-bounces@ietf.org] *On Behalf Of *Padma Pillay-Esnault *Sent:* Sunday, December 11, 2016 8:51 AM *To:* ideas@ietf.org *Subject:* [Ideas] Minutes of IDEAS side meeting @IETF97 Hello IDEAS! Please find below the minutes of IDEAS side meeting @IETF97. Thanks to all of you who attended the meeting and to Les Ginsberg for taking minutes. Please take a look and let us know if there are any changes needed. Looking forward to your contributions. Padma IDEAS Side Meeting Minutes IETF97 1. Agenda Padma Pillay-Esnault (Huawei) - Introduction on problem statement for IDEAS (10 mins) Presented the problem statement draft and the Use cases. Robert Raszuk: Should we define what identity is? Padma: Agree. The document take a stab at this by defining identities and in which context. There is a table in the document that captures the different aspects of ID usage, allocation and its impact on a dynamic mapping system. Sam Aldrin: What is primary focus? What problem are you really trying to solve? Narrow the scope - or are we trying to define a problem because we have a solution? Padma: The primary focus is the design and deployment of a dynamic mapping system. The Problem statement discusses in detail the problems we are trying to solve. Among those many problems is Session continuity in mobility which is important as we have more and more mobile modes in cellular as well as ip mobility(DC). Another important problem that can be solved and is discussed in the paper is Cross-silo communication. Encourage everyone to read the document. Luigi: We have multiple encaps and mappings and want to manage in a common way. But what is a common ID? Please clarify. Padma: In this case we are not necessarily looking for a common single ID. What we are trying to do is to map an ID to location. So that we can have the Identity dissociated with the locator so that mobility is fully supported. What we are proposing is to have a common control plane that have access to a mapping system used by all. It is not very practical to deploy one global mapping system per protocol or application. Luigi: Do we have to solve who is allocating the ID? Maybe we do not have to solve this problem. Padma: Well it depends. We have both the case for public and private IDs. For public IDs to be used by a common control plane, we will require some rules. Luigi: But what form will the ID take? Dino: Different EID types for different purposes. Hopefully they will be used for different purposes. Should it be geographical, first come first served, assigned at birth,...many types allocated differently. L2 overlays have the MAC address. ID allocation independent of database. ~General discussion about EID types and mapping systems. Bob Moskowitz: I am the Last member of the EID cabal. :-) Many discussions have been already What characteristics required of an EID? What is good/bad? Capturing that would be good. There is two decades of experience available =E2=80=93 would be good to make use of that. Padma: There is a table in the draft which captures some aspects of this discussion. How are we actually using IDs today? And how it should be used or restricted. Can we use ID properties to provide better security for example? Georgios: Take into account use cases in 5G and IoT, since they will impose requirements that we did not have up to now. ********************************************************** Tom Herbert ( Facebook) - The ILA protocol and NMS (10 mins) Scale to 100=E2=80=99s of billion aggregate mappings No aggregation assumed, 1%change per second Able to attach ancillary data to mapping Bob: Is this intended to be globally unique? Tom: Globally unique in a domain. Bob: with 7B population w 64 bit # 74% probability of collision. This must be accounted for. Will post the formula for calculating likelihood of collision. Tom: We do have a method to generate unique identifiers. Covers 20 years of experience. Mapping system detects conflicts at registration. Bob: Agreed. But 10 devices/person gives high probability of collisions Kiran: Scope of identifier determined by locator? Tom: Identifiers unique for a domain. Reverse translation requires locator to map back to the original prefix. Ingress/Egress translation. Both sides have to agree on the pairing. Kiran Makhijani: If age out of cache how can you detect? Tom: If we lose ILA routers need to have other ILA addresses available. An open issue Kiran Makhijani: Need to have reliability solution base requirements related to NMS ************************************************ Dino Farinacci ( Lispers) - LISP Mapping system, How it works? (10 mins) Presented LISP Site to access of mapping System, Site Registration 10 years of experience and DDT mapping server. Hierarchical network structure based on EID Allocation 3 levels of hierarchy to get 1billion registrations: 1 Million for 1 MS Multiple mapping systems Tom: With DNS have to wait for resolution - looks like you have same issue w LISP DDT? Dino: Solved by LISP has default cache in ITR. Albert: if you don=E2=80=99t was to resolve, you can set default route to p= roxy RTR which has all the mappings Fabio: Proxy DNS - you send to the router which has all the information. Dino points that if there are too many mappings In LISP we can use proxy ETRs , where requests can be distributed. Tom: In ILA had too many mappings in one device and now ILA does something similar. ************************************************ Gerry Forster ( UoSurrey) - ETSi NGP: GTP, Mobility & Flat 5G Architecture( 15 mins) Presented the mobile network as being most successful system, however GTP is expensive and adds to the cost for whoever is paying for spectrum. The user data is tunneled at least 3 times and GTP need to be updated for mobility. Smaller native headers (most of the time). Presented UoS work. Association-based secure membership of each level of network access Scalable addressing (16 bit most of the time, 52 bit global). 3-level ID-based Mobility (Cluster, Inter-Cluster, Network) Routing tables are local, but indexed for gateway function by 3-level ID lookup (not DNS, but intelligent network hierarchy and Meta-Data). Transmis= sion is tailored by profile to level of access, access type and networking level Lookups/ routes are through intelligent use of meta-data based =E2=80=98Con= text=E2=80=99 =3D ID Enabled Networking Dino: Can we assign IPv6 address but use a 16 bit address? Gerry : Yes - can virtualize end-to-end. Gerry: New protocol for access networks - can do the same for wifi. Dino: Only limit is 65K connections at one time. Gerry: Limit the number of translations or compromise the delay. ************************************************ Fabio Maino(Cisco) - Deployment experience of Mapping Systems ( 10 mins) Presented various use cases and deployment experience Internet based VPN, IPv6 transition, BGP free multihoming, DC host mobility Up to now mapping system in the router. Based on current requirements it is needed to bring mapping system out of the router. ************************************************ Dave Meyer (UoOregon/Brocade) - Machine Learning and Network Mapping System ( 15 Mins) ??: How did you get the parameters from networking? Are they addresses Dave: Just flattened the number - used different parameters e.g. number of map requests? Other parameters - will need to learn what works in the network case. ************************************************ A. Cabellos, J Vilanova & F Maino (UoCatalunya, Ecole P. Lausanne, Cisco) - A Blockchain-based Mapping System (15 mins) Padma: Have you looked at scalability? Fabio: Yes - scales well. ??: Is it clear that use cases are enforcing new requirements other than are provided by LISP (for example)? Will problem scope be different than in LISP? What might be the advantage of IDEAS work rather than LISP? Padma: Out of time - take it to the list. How can we be most useful? Need to work on defining the exact scope. ??:Will it be a BOF? Padma: Not sure yet. 2. Admin & Location Date: Thursday, 17th November 2016 Time : 6:00 - 8:00pm Venue: Studio2 Mailing list: IDEAS List address: ideas@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dideas To subscribe: https://www.ietf.org/mailman/listinfo/ideas Related areas: RTG, OPS Scribe: Les Ginsberg Number of attendees: 40+3. 3. Related Documents and Reads: https://tools.ietf.org/html/draft-padma-ideas-problem-statement-00 https://tools.ietf.org/html/draft-herbert-nvo3-ila-03 https://tools.ietf.org/html/rfc6830 https://tools.ietf.org/html/rfc6833 http://www.3gpp.org/release-14 --94eb2c06af0adf025e054365226c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI.=C2=A0Feel free to forward.

Looking forward to working with you= all
Padma
<= div class=3D"gmail_quote">

=C2=A0

From: Ideas [m= ailto:ideas-bou= nces@ietf.org] On Behalf Of Padma Pillay-Esnault
Sent: Sunday, December 11, 2016 8:51 AM
To: ideas@ietf.o= rg
Subject: [Ideas] Minutes of IDEAS side meeting @IETF97=

=C2=A0

Hello IDEAS!<= u>

=C2=A0=

Please find below th= e minutes of IDEAS side meeting @IETF97.

Thanks to all of you= who attended the meeting and to=C2=A0Les Ginsberg for taking minutes.

=C2=A0=

Please take a look a= nd let us know if there are any changes needed.

=C2=A0=

Looking forward to y= our contributions.

Padma<= /span>

=C2=A0

=C2=A0

IDEAS Side Meeting M= inutes=C2=A0 IETF97

=C2=A0=

=C2=A0=

1. Agenda=C2=A0

Padma Pillay-Esnault= (Huawei) - Introduction on problem statement for IDEAS (10 mins)=

Presented the proble= m statement draft and the Use cases.

=C2=A0=

Robert Raszuk: Shoul= d we define what identity is?

Padma: Agree. The do= cument take a stab at this by defining identities and in which context. The= re is a table in the document that captures the different aspects of ID usage, allocation and its impact on a dynamic mapping system= .

=C2=A0=

Sam Aldrin: What is = primary focus? What problem are you really trying to solve? Narrow the scop= e - or are we trying to define a problem because we have a solution?

Padma: The primary f= ocus is the design and deployment of a dynamic mapping system.

The Problem statemen= t discusses in detail the problems we are trying to solve. Among those many= problems is Session continuity in mobility which is important as we have more and more mobile modes in cellular as well as ip = mobility(DC). Another important problem that can be solved and is discussed= in the paper is Cross-silo communication. Encourage everyone to read the d= ocument.

=C2=A0=

Luigi: We have multi= ple encaps and mappings and want to manage in a common way.

But what is a common= ID? Please clarify.

=C2=A0=

Padma: In this case = we are not necessarily looking for a common single ID. What we are trying t= o do is to map an ID to location. So that we can have the Identity dissociated with the locator so that mobility is fully suppor= ted. What we are proposing is to have a common control plane that have acce= ss to a mapping system used by all. It is not very practical to deploy one = global mapping system per protocol or application.

=C2=A0=

Luigi: Do we have to= solve who is allocating the ID? Maybe we do not have to solve this problem= .

Padma: Well it depen= ds. We have both the case for public and private IDs. For public IDs to be = used by a common control plane, we will require some rules.

Luigi: But what form= will the ID take?

Dino: Different EID = types for different purposes. Hopefully they will be used

for different purpos= es. Should it be geographical, first come first served,

assigned at birth,..= .many types allocated differently.

L2 overlays have the= MAC address.

ID allocation indepe= ndent of database.

=C2=A0=

~General discussion = about EID types and mapping systems.

=C2=A0=

Bob Moskowitz: I am = the Last member of the EID cabal. :-)

Many discussions hav= e been already What characteristics required of an EID? What is good/bad? C= apturing that would be good. There is two decades of experience available =E2=80=93 would be good to make use of that.

Padma: There is a ta= ble in the draft which captures some aspects of this discussion.<= /u>

How are we actually = using IDs today? And how it should be used or restricted.

Can we use ID proper= ties to provide better security for example?

Georgios: Take into = account use cases in 5G and IoT, since they will impose requirements that w= e did not have up to now.

=C2=A0=

********************= **************************************

Tom Herbert ( Facebo= ok) - The ILA protocol and NMS (10 mins)

Scale to 100=E2=80= =99s of billion aggregate mappings

No aggregation assum= ed, 1%change per second

Able to attach ancil= lary data to mapping

=C2=A0=

Bob: Is this intende= d to be globally unique?

Tom: Globally unique= in a domain.=C2=A0

Bob: with 7B populat= ion w 64 bit # 74% probability of collision.

This must be account= ed for. Will post the formula for calculating likelihood of collision.

Tom: We do have a me= thod to generate unique identifiers.=C2=A0

Covers 20 years of e= xperience.=C2=A0=C2=A0

Mapping system detec= ts conflicts at registration.

Bob: Agreed. But 10 = devices/person gives high probability of collisions

Kiran: Scope of iden= tifier determined by locator?

Tom: Identifiers uni= que for a domain.=C2=A0

Reverse translation = requires locator to map back to the original prefix.

Ingress/Egress trans= lation. Both sides have to agree on the pairing.

Kiran Makhijani: If = age out of cache how can you detect?

Tom: If we lose ILA = routers need to have other ILA addresses available.

An open issue=

Kiran Makhijani: Nee= d to have reliability solution base requirements related to NMS

=C2=A0=

********************= ****************************

Dino Farinacci ( Lis= pers) - LISP Mapping system, How it works? (10 mins)

Presented LISP Site = to access of mapping System, Site Registration

10 years of experien= ce and DDT mapping server.

Hierarchical network= structure based on EID Allocation

3 levels of hierarch= y to get 1billion registrations: 1 Million for 1 MS

Multiple mapping sys= tems

=C2=A0=

Tom: With DNS have t= o wait for resolution - looks like you have same issue=

w LISP DDT?

Dino: Solved by LISP= has default cache in ITR.

Albert: if you don= =E2=80=99t was to resolve, you can set default route to proxy RTR which has= all the mappings

Fabio: Proxy DNS - y= ou send to the router which has all the information.

Dino points that if = there are too many mappings In LISP we can use proxy ETRs , where requests = can be distributed.

Tom: In ILA had too = many mappings in one device and now ILA does something similar.

=C2=A0=

********************= ****************************

Gerry Forster ( UoSu= rrey) - ETSi NGP: GTP, Mobility=C2=A0 & Flat 5G Architecture( 15 mins) = Presented the mobile network as being most successful system, however GTP is expensive and adds to the cost for whoever is paying for sp= ectrum. The user data is tunneled at least 3 times and GTP need to be updat= ed for mobility.=C2=A0Smaller native headers (most of the time).

=C2=A0=

Presented UoS work.= =C2=A0

Assoc= iation-based secure membership of each level of network access

Scala= ble addressing (16 bit most of the time, 52 bit global). 3-level ID-based M= obility (Cluster, Inter-Cluster, Network)

Routi= ng tables are local, but indexed for gateway function by 3-level ID lookup = (not DNS, but intelligent network hierarchy and Meta-Data).=C2=A0Transmission is tailored by profile to level of access, access type and networking leve= l

Looku= ps/ routes are through intelligent use of meta-data based =E2=80=98Context= =E2=80=99 =3D ID Enabled Networking=C2=A0

=C2=A0=

Dino: Can we assign = IPv6 address but use a 16 bit address?

Gerry : Yes - can vi= rtualize end-to-end.

Gerry: New protocol = for access networks - can do the same for wifi.

Dino: Only limit is = 65K connections at one time.

Gerry: Limit the num= ber of translations or compromise the delay.

=C2=A0=

********************= ****************************

Fabio Maino(Cisco) -= Deployment experience of=C2=A0 Mapping Systems ( 10 mins)

Presented various us= e cases and deployment experience Internet based VPN, IPv6 transition, BGP = free multihoming, DC host mobility

Up to now mapping sy= stem in the router. Based on current requirements it is needed to bring map= ping system out of the router.

=C2=A0=

********************= ****************************

Dave Meyer (UoOregon= /Brocade) - Machine Learning=C2=A0 and Network Mapping System=C2=A0 ( 15 Mi= ns)

??: How did you get = the parameters from networking? Are they addresses

Dave: Just flattened= the number - used different parameters e.g. number of=

map requests? Other = parameters - will need to learn what works in the network case.

********************= ****************************

A. Cabellos, J Vilan= ova & F Maino (UoCatalunya, Ecole P. Lausanne, Cisco) - A Blockchain-ba= sed Mapping System (15 mins)=C2=A0

Padma: Have you look= ed at scalability?

Fabio: Yes - scales = well.

??: Is it clear that= use cases are enforcing new requirements other than are provided by LISP (= for example)?

Will problem scope b= e different than in LISP? What might be the advantage of IDEAS work rather = than LISP?

Padma: Out of time -= take it to the list. How can we be most useful?

Need to work on defi= ning the exact scope.

??:Will it be a BOF?=

Padma: Not sure yet.=

=C2=A0=

2. Admin & Locat= ion=C2=A0

Date: Thursday, 17th= November 2016

Time :=C2=A06:00 - 8:00pm

Venue: Studio2

Mailing list: IDEAS<= u>

List address:=C2=A0<= a href=3D"mailto:ideas@ietf.org" target=3D"_blank">ideas@ietf.org

Archive:=C2=A0https://mailarchive.ietf.org/arch/search/?email_list= =3Dideas

To subscribe:=C2=A0<= a href=3D"https://www.ietf.org/mailman/listinfo/ideas" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/ideas

Related areas: RTG, = OPS=C2=A0

Scribe: Les Ginsberg=

Number of attendees:= 40+3.=C2=A0

=C2=A0=

3. Related Documents= and Reads:

https://tools.ietf.org/html/draft-padma-ideas-problem-statement= -00

https://too= ls.ietf.org/html/draft-herbert-nvo3-ila-03

https://tools.ietf.org/html/<= wbr>rfc6830

https://tools.ietf.org/html/<= wbr>rfc6833

http://www.3gpp.org/release-14=

=C2=A0=


--94eb2c06af0adf025e054365226c-- --94eb2c06af0adf0261054365226e Content-Type: text/plain; charset=US-ASCII; name="ATT00002.txt" Content-Disposition: attachment; filename="ATT00002.txt" Content-Transfer-Encoding: base64 Content-ID: <1F561182C838AA40A70F9AC78D7BE3F0@huawei.com> X-Attachment-Id: 2808fa1db41272f3_0.1 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkZWFzIG1h aWxpbmcgbGlzdA0KSWRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRlYXMNCg== --94eb2c06af0adf0261054365226e-- From nobody Tue Dec 13 05:36:19 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90741296B9 for ; Tue, 13 Dec 2016 05:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiglEewUXQXM for ; Tue, 13 Dec 2016 05:36:14 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA761296B7 for ; Tue, 13 Dec 2016 05:36:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C207762331; Tue, 13 Dec 2016 08:36:13 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iEByRRQHg902; Tue, 13 Dec 2016 08:35:58 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DBCFF6232C; Tue, 13 Dec 2016 08:35:57 -0500 (EST) To: Padma Pillay-Esnault References: From: Robert Moskowitz Message-ID: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> Date: Tue, 13 Dec 2016 08:35:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------59E9495B4F82C671D9241BC2" Archived-At: Cc: ideas@ietf.org Subject: Re: [Ideas] Computing collisions X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 13:36:18 -0000 This is a multi-part message in MIME format. --------------59E9495B4F82C671D9241BC2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Here is some results. On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote: > Hello Bob > > Thanks for sending this formula. > > If we assume that the population is not necessarily a flat space and > that it is in different separate instances, this could help reduce the > collision. > > Per the ideas problem statement draft, we have discussed about the > different types of devices and whether we could have some policy on > what they can do. Eg. a camera should not be shopping for clothes or > access bank accounts .... wouldn't it make sense to put them in > different instances with different access policies? > > What are your thoughts on this? Let's work with a 24 bit ID space which is a population of 16,777,216 Let's then assume a random distribution of 2^14 (16,384) devices. This is a 99.97% probablity of a collision. A sure thing. Now let's assume that there are 256 (2^8) classes of devices and that the population is evenly divided. That is 64 devices per class. We now have reduced our ID space to 16 bits (65,536), but the probablity of a collision with only 64 devices is 3.08%! But if the division is not equal between the classes and one class has 512 devices the probablity jumps up to 84.67%; again an almost sure thing. So we can see from this little exercise that dividing our ID space into groupings can actually reduce the collision risk. Two caveats are clear though. How many classes to use (you can see my effort at this in draft-moskowitz-hierarchical-hip) and what if one class out classes all the rest? You still need to manage collisions. You just may be telling fewer losers to select a new ID. Now if instead you are talking about reusing your ID space on the assumption that these devices are NEVER interacting and thus never 'seeing' the inevitable collisions, then, yes, reuse the ID space. But we all know what assume also spells. > Padma > > On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz > > wrote: > > Here is the equation: > > probability of collision = 1 - e^{-k^2/(2n)} > > Where n is your max population size (e.g. 2^64) > > and k is your deployed population (e.g. 7B) > > Bob > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > > > --------------59E9495B4F82C671D9241BC2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Here is some results.


On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote:
Hello Bob

Thanks for sending this formula.

If we assume that the population is not necessarily a flat space and that it is in different separate instances, this could help reduce the collision.

Per the ideas problem statement draft, we have discussed about the different types of devices and whether we could have some policy on what they can do. Eg. a camera should not be shopping for clothes or access bank accounts .... wouldn't it make sense to put them in different instances with different access policies?

What are your thoughts on this?

Let's work with a 24 bit ID space which is a population of 16,777,216

Let's then assume a random distribution of 2^14 (16,384) devices.  This is a 99.97% probablity of a collision.  A sure thing.

Now let's assume that there are 256 (2^8) classes of devices and that the population is evenly divided.  That is 64 devices per class.  We now have reduced our ID space to 16 bits (65,536), but the probablity of a collision with only 64 devices is 3.08%!

But if the division is not equal between the classes and one class has 512 devices the probablity jumps up to 84.67%; again an almost sure thing.

So we can see from this little exercise that dividing our ID space into groupings can actually reduce the collision risk.  Two caveats are clear though.  How many classes to use (you can see my effort at this in draft-moskowitz-hierarchical-hip) and what if one class out classes all the rest?

You still need to manage collisions.  You just may be telling fewer losers to select a new ID.

Now if instead you are talking about reusing your ID space on the assumption that these devices are NEVER interacting and thus never 'seeing' the inevitable collisions, then, yes, reuse the ID space.  But we all know what assume also spells.


Padma

On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
Here is the equation:

probability of collision = 1 - e^{-k^2/(2n)}

Where n is your max population size (e.g. 2^64)

and k is your deployed population (e.g. 7B)

Bob

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


--------------59E9495B4F82C671D9241BC2-- From nobody Tue Dec 13 06:09:59 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C412958A for ; Tue, 13 Dec 2016 06:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slc0LbpIJ6nV for ; Tue, 13 Dec 2016 06:09:55 -0800 (PST) Received: from mail-wj0-x231.google.com (mail-wj0-x231.google.com [IPv6:2a00:1450:400c:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FC11296E8 for ; Tue, 13 Dec 2016 06:09:55 -0800 (PST) Received: by mail-wj0-x231.google.com with SMTP id tk12so101669538wjb.3 for ; Tue, 13 Dec 2016 06:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=wwQoMeLunGKNkSxyJQi8OP66HmDXGXYsrIt0kU9++3I=; b=n3PdV5NhHkyjLQ7BfpqcWRFDUvGyPch/EFJhIPHWYGbGx41y9+zDfppOk4X/AE5LGf 7lczPouhqwSF68Tu7JYMDvx95nmegbU+PrxVqgUDTLE0Hj+ukZWP6A1XHpWleticpuls kinJ/Ug3WZFGxNZGev4WwP5aaadKTN4v9awCRc7FNlavyr1GxH26ULSS2Ayr0Tbrymx3 P9NGIJQyF4IWBfBLvRO4JO+w/YKbosCNIAcJmJWwbk+WZRJRu/M5ykH1N+k0JH9Ge/6e sQm3GPEIlPxPwv6t6aaGCBpxL6dYVy5WnT/A4VRocGt4vrJJnVrEylQkLEFMakd1TvPS hcHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=wwQoMeLunGKNkSxyJQi8OP66HmDXGXYsrIt0kU9++3I=; b=fH+BXSdMipybwv4ZEwgcbu+vJdYXD6EgWBDroTMBlxir0rFe2jZiWRlixq4+ZkTYrk 8JcUgDQLTnmroU13XUFTitDbCzaHHYN6VJtbLwo9TiD4I+x87d6kUIKrKBqJtYGeD/yX 3FJL/2kjEk/UGxHWrfPllXQE3swDwbjm2NRlzEn4jpfQeOGqjBrByRMjLxHhFOeQLr8T 6CJB4LB8/JqxW12ggrkNMxlLG6x/+UXIekouN5dQf7UCCD0JgSfN1hYas6fS0m/Yfd1b FSdY6W5/i8nzBxckeiR+SzosCcdWqtyucdtqPgYaTp7+2ZgiGNnYzXtOgTo9hKW1EaMS d8bQ== X-Gm-Message-State: AKaTC03IRAzSWzBqKFTBTnW2a2XQ+RcBKJOrpL0NsMtCncWhppFTFE15Lw/qan25faQylw== X-Received: by 10.194.58.237 with SMTP id u13mr37359042wjq.10.1481638193531; Tue, 13 Dec 2016 06:09:53 -0800 (PST) Received: from [192.168.2.131] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id b3sm62445523wjy.40.2016.12.13.06.09.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 06:09:53 -0800 (PST) To: Robert Moskowitz , Padma Pillay-Esnault References: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> From: Stewart Bryant Message-ID: <0f4117fb-1c93-7475-fd4c-004384c1e8f5@gmail.com> Date: Tue, 13 Dec 2016 14:09:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> Content-Type: multipart/alternative; boundary="------------93D18C8F19BDAE85524F2823" Archived-At: Cc: ideas@ietf.org Subject: Re: [Ideas] Computing collisions X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 14:09:58 -0000 This is a multi-part message in MIME format. --------------93D18C8F19BDAE85524F2823 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Of course there cannot be any human intervention in the selection process or the odds of a collision will go up hugely. Stewart On 13/12/2016 13:35, Robert Moskowitz wrote: > > Here is some results. > > > On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote: >> Hello Bob >> >> Thanks for sending this formula. >> >> If we assume that the population is not necessarily a flat space and >> that it is in different separate instances, this could help reduce >> the collision. >> >> Per the ideas problem statement draft, we have discussed about the >> different types of devices and whether we could have some policy on >> what they can do. Eg. a camera should not be shopping for clothes or >> access bank accounts .... wouldn't it make sense to put them in >> different instances with different access policies? >> >> What are your thoughts on this? > > Let's work with a 24 bit ID space which is a population of 16,777,216 > > Let's then assume a random distribution of 2^14 (16,384) devices. This > is a 99.97% probablity of a collision. A sure thing. > > Now let's assume that there are 256 (2^8) classes of devices and that > the population is evenly divided. That is 64 devices per class. We > now have reduced our ID space to 16 bits (65,536), but the probablity > of a collision with only 64 devices is 3.08%! > > But if the division is not equal between the classes and one class has > 512 devices the probablity jumps up to 84.67%; again an almost sure thing. > > So we can see from this little exercise that dividing our ID space > into groupings can actually reduce the collision risk. Two caveats > are clear though. How many classes to use (you can see my effort at > this in draft-moskowitz-hierarchical-hip) and what if one class out > classes all the rest? > > You still need to manage collisions. You just may be telling fewer > losers to select a new ID. > > Now if instead you are talking about reusing your ID space on the > assumption that these devices are NEVER interacting and thus never > 'seeing' the inevitable collisions, then, yes, reuse the ID space. > But we all know what assume also spells. > > >> Padma >> >> On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz >> > wrote: >> >> Here is the equation: >> >> probability of collision = 1 - e^{-k^2/(2n)} >> >> Where n is your max population size (e.g. 2^64) >> >> and k is your deployed population (e.g. 7B) >> >> Bob >> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas >> >> >> > > > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas --------------93D18C8F19BDAE85524F2823 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Of course there cannot be any human intervention in the selection process or the odds of a collision will go up hugely.

Stewart


On 13/12/2016 13:35, Robert Moskowitz wrote:

Here is some results.


On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote:
Hello Bob

Thanks for sending this formula.

If we assume that the population is not necessarily a flat space and that it is in different separate instances, this could help reduce the collision.

Per the ideas problem statement draft, we have discussed about the different types of devices and whether we could have some policy on what they can do. Eg. a camera should not be shopping for clothes or access bank accounts .... wouldn't it make sense to put them in different instances with different access policies?

What are your thoughts on this?

Let's work with a 24 bit ID space which is a population of 16,777,216

Let's then assume a random distribution of 2^14 (16,384) devices. This is a 99.97% probablity of a collision. A sure thing.

Now let's assume that there are 256 (2^8) classes of devices and that the population is evenly divided. That is 64 devices per class. We now have reduced our ID space to 16 bits (65,536), but the probablity of a collision with only 64 devices is 3.08%!

But if the division is not equal between the classes and one class has 512 devices the probablity jumps up to 84.67%; again an almost sure thing.

So we can see from this little exercise that dividing our ID space into groupings can actually reduce the collision risk. Two caveats are clear though. How many classes to use (you can see my effort at this in draft-moskowitz-hierarchical-hip) and what if one class out classes all the rest?

You still need to manage collisions. You just may be telling fewer losers to select a new ID.

Now if instead you are talking about reusing your ID space on the assumption that these devices are NEVER interacting and thus never 'seeing' the inevitable collisions, then, yes, reuse the ID space. But we all know what assume also spells.


Padma

On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
Here is the equation:

probability of collision = 1 - e^{-k^2/(2n)}

Where n is your max population size (e.g. 2^64)

and k is your deployed population (e.g. 7B)

Bob

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas




_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas

--------------93D18C8F19BDAE85524F2823-- From nobody Tue Dec 13 10:35:52 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E5F129435 for ; Tue, 13 Dec 2016 10:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hnIctQ52MWa for ; Tue, 13 Dec 2016 10:35:49 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64707129641 for ; Tue, 13 Dec 2016 10:35:49 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id y68so6374618pfb.1 for ; Tue, 13 Dec 2016 10:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zHXxINJB20I3OlT+oMDTFNUtSxcVJFOgswp7yndAsbc=; b=xwrw48FIErrMwtqWyxkh0y1IwqylRwK9SfRkt3l1XE9QXT+FcPra95l7s83cul/U9x vnEcAooZVkzAfNwaysl9PVjnJsY7hnsHVN3eGUd67UcaHOYd/h+oDiLgAvf43X9nolYD 6cPcNxcLVgYtqv34lWe52C+W5QvJ6S1QKG8FqqyPgx6xJuN2JtH+Ypm/tl6ZvZoBuYeu dHsj/6UNy7+ei2whczks7Srm0SZRSRvYoqT9bTqhB95O1Giwyv1NQgreVDXavQXtSuzp G0gBqCqnqCJcEST3KinX/Oo+135O+Wm5AYjoK/36ZHLV0wL20iLKFFoIr2yBRiMreVPU 918Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zHXxINJB20I3OlT+oMDTFNUtSxcVJFOgswp7yndAsbc=; b=U8ECtrisP7x2Io/YN6RYmE2q2CWjkHiUC6i/DiUajZFsevTgwKAAoQC4LQWPrfToL4 h9szIEW815HEG5mKJqdVdxaMPP0JDs3w4WgWg0dKg0WKZgA2g3Aay4zFT61ZoriMjEUW 2hAB6Kn3mbH1xBNYbfqo5+p5iHjiCjh3KyqPLAf8WnOkdMo+tzYvNbjnyCU0lUZvQrZA sQOu7IzGoG2bZ6+6KjNG+938nqQKxnf7+w5f86LfLW4ffLSv+pXSY1eg6mGKh1jA0oOj JFrtFxJhMUZjrBfGu/biQNwSL8A27+Za+iSYJiC8f9Tu39Q4ePiKh6ONUyZhqwR1OlM/ Ic2Q== X-Gm-Message-State: AKaTC02VmRUU3SrMesuWPOYIZFJGkWz7szKYmFE/frH0GZjPHcT/GlSUR6Ze9s3ELkwvIw== X-Received: by 10.98.144.86 with SMTP id a83mr103312883pfe.107.1481654148398; Tue, 13 Dec 2016 10:35:48 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id y2sm81547380pff.82.2016.12.13.10.35.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 10:35:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> Date: Tue, 13 Dec 2016 10:35:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6AA7A937-AEC5-4E6F-9D87-87BC257EF9F8@gmail.com> References: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Padma Pillay-Esnault , ideas@ietf.org Subject: Re: [Ideas] Computing collisions X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 18:35:51 -0000 In LISP, an xTR registers with a 128-bit xTR-ID. This is not the EID. So = we could have an xTR register with a random EID it chooses. Then the = map-server determines it is a collision because another xTR-ID has = registered with that same EID. The map-server could select a random EID = and check locally if it collides. If it doesn=E2=80=99t, then the xTR = registers with a new EID (and makes appropriate interface address = assignments locally). Note the draft-farinacci-lisp-eid-anonymity-01 specs that ephemeral-EIDs = can be used. So when an xTR decided to choose a random IPv6 address as = an EID and registers. It can ask the map-server if it collides. Today, = the map-server Acks Map-Register messages, but it could Nak and say = =E2=80=9Cgo get a new random ephemeral-EID=E2=80=9D. I like this = approach better because the allocation happens at the sites within their = own address prefix range and gives you some obfuscation at the same = time. If people thing the second approach makes sense, I can spec out in the = above draft how Map-Servers could NAK when there are collisions. Please = comment. Dino > On Dec 13, 2016, at 5:35 AM, Robert Moskowitz = wrote: >=20 > Here is some results. >=20 > On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote: >> Hello Bob >>=20 >> Thanks for sending this formula. >>=20 >> If we assume that the population is not necessarily a flat space and = that it is in different separate instances, this could help reduce the = collision. >>=20 >> Per the ideas problem statement draft, we have discussed about the = different types of devices and whether we could have some policy on what = they can do. Eg. a camera should not be shopping for clothes or access = bank accounts .... wouldn't it make sense to put them in different = instances with different access policies? >>=20 >> What are your thoughts on this? >=20 > Let's work with a 24 bit ID space which is a population of 16,777,216 >=20 > Let's then assume a random distribution of 2^14 (16,384) devices. = This is a 99.97% probablity of a collision. A sure thing. >=20 > Now let's assume that there are 256 (2^8) classes of devices and that = the population is evenly divided. That is 64 devices per class. We now = have reduced our ID space to 16 bits (65,536), but the probablity of a = collision with only 64 devices is 3.08%! >=20 > But if the division is not equal between the classes and one class has = 512 devices the probablity jumps up to 84.67%; again an almost sure = thing. >=20 > So we can see from this little exercise that dividing our ID space = into groupings can actually reduce the collision risk. Two caveats are = clear though. How many classes to use (you can see my effort at this in = draft-moskowitz-hierarchical-hip) and what if one class out classes all = the rest? >=20 > You still need to manage collisions. You just may be telling fewer = losers to select a new ID. >=20 > Now if instead you are talking about reusing your ID space on the = assumption that these devices are NEVER interacting and thus never = 'seeing' the inevitable collisions, then, yes, reuse the ID space. But = we all know what assume also spells. >=20 >=20 >> Padma >>=20 >> On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz = wrote: >> Here is the equation: >>=20 >> probability of collision =3D 1 - e^{-k^2/(2n)} >>=20 >> Where n is your max population size (e.g. 2^64) >>=20 >> and k is your deployed population (e.g. 7B) >>=20 >> Bob >>=20 >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas >>=20 >=20 > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Tue Dec 13 11:12:51 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB9F129472 for ; Tue, 13 Dec 2016 11:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAXuHio8nqRf for ; Tue, 13 Dec 2016 11:12:48 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73AAE129445 for ; Tue, 13 Dec 2016 11:12:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 81E75622FE; Tue, 13 Dec 2016 14:12:46 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Cxk7-qInsXHH; Tue, 13 Dec 2016 14:12:42 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id E097262301; Tue, 13 Dec 2016 14:12:41 -0500 (EST) To: Dino Farinacci References: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> <6AA7A937-AEC5-4E6F-9D87-87BC257EF9F8@gmail.com> From: Robert Moskowitz Message-ID: Date: Tue, 13 Dec 2016 14:12:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <6AA7A937-AEC5-4E6F-9D87-87BC257EF9F8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Padma Pillay-Esnault , ideas@ietf.org Subject: Re: [Ideas] Computing collisions X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 19:12:50 -0000 On 12/13/2016 01:35 PM, Dino Farinacci wrote: > In LISP, an xTR registers with a 128-bit xTR-ID. This is not the EID. So we could have an xTR register with a random EID it chooses. Then the map-server determines it is a collision because another xTR-ID has registered with that same EID. The map-server could select a random EID and check locally if it collides. If it doesn’t, then the xTR registers with a new EID (and makes appropriate interface address assignments locally). > > Note the draft-farinacci-lisp-eid-anonymity-01 specs that ephemeral-EIDs can be used. So when an xTR decided to choose a random IPv6 address as an EID and registers. It can ask the map-server if it collides. Today, the map-server Acks Map-Register messages, but it could Nak and say “go get a new random ephemeral-EID”. I like this approach better because the allocation happens at the sites within their own address prefix range and gives you some obfuscation at the same time. > > If people thing the second approach makes sense, I can spec out in the above draft how Map-Servers could NAK when there are collisions. Please comment. That is basically what I do with Hierarchical HITs. The device registers its HIT with the owner of the Hierarchy point. The owner (HDA) then either accepts the HIT or rejects with a 'Hierarchical HIT Already Registered' message (see sec 6.4). Since it might be the case that device is registering, there is a difference between duplicate HI (Either a register, so something bad is happening to make it possible for two devices to select the same HI) and HIT collision with different HI. Note that it is possible for a device to register one HI to two different HDAs. Due to the algorithm for HIT generation, these will not only have different HDA values, but the hash component will be different. However a device may well choose different HIs for different registrations for privacy reasons. > > Dino > >> On Dec 13, 2016, at 5:35 AM, Robert Moskowitz wrote: >> >> Here is some results. >> >> On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote: >>> Hello Bob >>> >>> Thanks for sending this formula. >>> >>> If we assume that the population is not necessarily a flat space and that it is in different separate instances, this could help reduce the collision. >>> >>> Per the ideas problem statement draft, we have discussed about the different types of devices and whether we could have some policy on what they can do. Eg. a camera should not be shopping for clothes or access bank accounts .... wouldn't it make sense to put them in different instances with different access policies? >>> >>> What are your thoughts on this? >> Let's work with a 24 bit ID space which is a population of 16,777,216 >> >> Let's then assume a random distribution of 2^14 (16,384) devices. This is a 99.97% probablity of a collision. A sure thing. >> >> Now let's assume that there are 256 (2^8) classes of devices and that the population is evenly divided. That is 64 devices per class. We now have reduced our ID space to 16 bits (65,536), but the probablity of a collision with only 64 devices is 3.08%! >> >> But if the division is not equal between the classes and one class has 512 devices the probablity jumps up to 84.67%; again an almost sure thing. >> >> So we can see from this little exercise that dividing our ID space into groupings can actually reduce the collision risk. Two caveats are clear though. How many classes to use (you can see my effort at this in draft-moskowitz-hierarchical-hip) and what if one class out classes all the rest? >> >> You still need to manage collisions. You just may be telling fewer losers to select a new ID. >> >> Now if instead you are talking about reusing your ID space on the assumption that these devices are NEVER interacting and thus never 'seeing' the inevitable collisions, then, yes, reuse the ID space. But we all know what assume also spells. >> >> >>> Padma >>> >>> On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz wrote: >>> Here is the equation: >>> >>> probability of collision = 1 - e^{-k^2/(2n)} >>> >>> Where n is your max population size (e.g. 2^64) >>> >>> and k is your deployed population (e.g. 7B) >>> >>> Bob >>> >>> _______________________________________________ >>> Ideas mailing list >>> Ideas@ietf.org >>> https://www.ietf.org/mailman/listinfo/ideas >>> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas From nobody Tue Dec 13 14:47:30 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31A3129C4A for ; Tue, 13 Dec 2016 14:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe5ZV_d-nEdh for ; Tue, 13 Dec 2016 14:47:26 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A202B129C40 for ; Tue, 13 Dec 2016 14:47:26 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n21so1679956qka.3 for ; Tue, 13 Dec 2016 14:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TkVbFKuylS2Tceti7HnrfFeHrBTJ0H9e4R3pP1kNFLY=; b=NubiETYh3nXjB6NGUTugYJjxjzoEOnxUr/qiu1h0sZAoEA/EKvNsASBdrJzvGYnDaU 6t6rml5Idy0Z80MIeNHUcagZGVpoAcG2kf15PFQOwNtLGksmYPy4BmQmBFkSDVKMNzQq 0wbOX0TUpbL/ZJCZGPSACSiQbP/8pn1E19DenBf/yY9xE+QtVoduanBw1SNFeDd3kfEp OiGfgxZOqmqGnaITxEtPGahqI+quy6I2+uk3L5ooYJDrq+3uyTHzC+BKZikYApJD3V5q 9XbX6LehoyzhcfZB9l+S1ycEly75h1RhblbS0QdKVJIhnjxAhYyeLTxhsWpsKYzn5s5Y rZBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TkVbFKuylS2Tceti7HnrfFeHrBTJ0H9e4R3pP1kNFLY=; b=SYU7eUPRcfuEQHgdtc03BcZbHeUJcRqGhrzaeoIVMsjYTVz5DRuezB2++Jypmb9y3D 9+PqY0pptk1XgeOKDZ2X2IeRE+stTCdh2ahzP0y+BzMywYb8bRQrWwur5DjSI69LAm0p J8n6SGlFgor6cu46nj+VhwZ1WS8f/Tk1oVAhhDpOcBU+ZbhwdX21Ak3PqbaXq9PIuLRC b7+lSIPjV5bog4v5wfogMaEp++tq8LUIotc12HsknZ2jCfArO3egqGeQSpEu16ev7xNS o3G7paGpZEoJGfm5Drc9+jzFBX88hGK9JQtPFv4lv/c4nBgp0cpYNCzudnb1+VTilMmr zPFA== X-Gm-Message-State: AKaTC02jpCJybbvNSnA2FNRo00Nagi65Sik1kt+jY9ts78aOGWYCLoM8Q9P8dSGpzgc1yogxJCkhnpRj2mzADQ== X-Received: by 10.55.190.66 with SMTP id o63mr84947723qkf.254.1481669245805; Tue, 13 Dec 2016 14:47:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.198 with HTTP; Tue, 13 Dec 2016 14:47:25 -0800 (PST) In-Reply-To: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> References: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> From: Padma Pillay-Esnault Date: Tue, 13 Dec 2016 23:47:25 +0100 Message-ID: To: Robert Moskowitz Content-Type: multipart/alternative; boundary=94eb2c04395c122bf80543920126 Archived-At: Cc: ideas@ietf.org, Padma Pillay-Esnault Subject: Re: [Ideas] Computing collisions X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 22:47:29 -0000 --94eb2c04395c122bf80543920126 Content-Type: text/plain; charset=UTF-8 It is interesting to see that with an intelligent spread we actually can reduce the collision probability significantly. Will add some text regarding this in the next iteration of the problem statement. Padma On Tue, Dec 13, 2016 at 2:35 PM, Robert Moskowitz wrote: > Here is some results. > > On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote: > > Hello Bob > > Thanks for sending this formula. > > If we assume that the population is not necessarily a flat space and that > it is in different separate instances, this could help reduce the collision. > > Per the ideas problem statement draft, we have discussed about the > different types of devices and whether we could have some policy on what > they can do. Eg. a camera should not be shopping for clothes or access bank > accounts .... wouldn't it make sense to put them in different instances > with different access policies? > > What are your thoughts on this? > > > Let's work with a 24 bit ID space which is a population of 16,777,216 > > Let's then assume a random distribution of 2^14 (16,384) devices. This is > a 99.97% probablity of a collision. A sure thing. > > Now let's assume that there are 256 (2^8) classes of devices and that the > population is evenly divided. That is 64 devices per class. We now have > reduced our ID space to 16 bits (65,536), but the probablity of a collision > with only 64 devices is 3.08%! > > But if the division is not equal between the classes and one class has 512 > devices the probablity jumps up to 84.67%; again an almost sure thing. > > So we can see from this little exercise that dividing our ID space into > groupings can actually reduce the collision risk. Two caveats are clear > though. How many classes to use (you can see my effort at this in > draft-moskowitz-hierarchical-hip) and what if one class out classes all > the rest? > > You still need to manage collisions. You just may be telling fewer losers > to select a new ID. > > Now if instead you are talking about reusing your ID space on the > assumption that these devices are NEVER interacting and thus never 'seeing' > the inevitable collisions, then, yes, reuse the ID space. But we all know > what assume also spells. > > > Padma > > On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz < > rgm-ietf@htt-consult.com> wrote: > >> Here is the equation: >> >> probability of collision = 1 - e^{-k^2/(2n)} >> >> Where n is your max population size (e.g. 2^64) >> >> and k is your deployed population (e.g. 7B) >> >> Bob >> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas >> > > > --94eb2c04395c122bf80543920126 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is interesting to see that with an intelligent spread w= e actually can reduce the collision probability significantly.
Will add= some text regarding this in the next iteration of the problem statement.

Padma


On Tue, Dec 13, 2016 at 2:35 PM,= Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
=20 =20 =20

Here is some results.


On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote:
Hello Bob

Thanks for sending this formula.

If we assume that the population is not necessarily a flat space and that it is in different separate instances, this could help reduce the collision.

Per the ideas problem statement draft, we have discussed about the different types of devices and whether we could have some policy on what they can do. Eg. a camera should not be shopping for clothes or access bank accounts .... wouldn't it make sense to put them in different instances with different access policies?

What are your thoughts on this?

 Let's work with a 24 bit ID space which is a population of 16,777,216

Let's then assume a random distribution of 2^14 (16,384) devices.= =C2=A0 This is a 99.97% probablity of a collision.=C2=A0 A sure thing.

Now let's assume that there are 256 (2^8) classes of devices and that the population is evenly divided.=C2=A0 That is 64 devices per class.=C2=A0 We now have reduced our ID space to 16 bits (65,536), but the probablity of a collision with only 64 devices is 3.08%!

But if the division is not equal between the classes and one class has 512 devices the probablity jumps up to 84.67%; again an almost sure thing.

So we can see from this little exercise that dividing our ID space into groupings can actually reduce the collision risk.=C2=A0 Two caveat= s are clear though.=C2=A0 How many classes to use (you can see my effort = at this in draft-moskowitz-hierarchical-hip) and what if one class ou= t classes all the rest?

You still need to manage collisions.=C2=A0 You just may be telling fewe= r losers to select a new ID.

Now if instead you are talking about reusing your ID space on the assumption that these devices are NEVER interacting and thus never 'seeing' the inevitable collisions, then, yes, reuse the ID spa= ce.=C2=A0 But we all know what assume also spells.


Padma

On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
Here is the equation:

probability of collision =3D 1 - e^{-k^2/(2n)}

Where n is your max population size (e.g. 2^64)

and k is your deployed population (e.g. 7B)

Bob

_______________________________________________
Ideas mailing list
Ideas@ietf.= org
https://www.ietf.org/mailman/listinfo/id= eas



--94eb2c04395c122bf80543920126-- From nobody Tue Dec 13 15:48:30 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBD7129C5B for ; Tue, 13 Dec 2016 15:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD7fCZCjhREH for ; Tue, 13 Dec 2016 15:48:15 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825B8129C4D for ; Tue, 13 Dec 2016 15:48:09 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id p16so2854995qta.0 for ; Tue, 13 Dec 2016 15:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1VG5bxG7HqPsri4EYIm5+BSGxBbEiXuHTVNmGfjEIz0=; b=W8UcqK0pYB4lP801v/rV1DI+GTndCmVBlk1PKgvImtSdGYYgS9jPcfp8jx+9bgOy5u sp6PwGXAiqlO4PJPDmKuhLVw+kSMMfGpuiu93gFeidVjjg59Q1+5X2J/sVnXQatEsLJH oWMYWMh9p3GFZloQblKSFZFIXdl/UX2yxcJfz+RHbupKncZZp6KWYfyD2kOe2VOuV7qC Evkr8UBLltapY9XuDtD5qcSM12TmR2+EW1f4F5XHz54jqBCID6JsTZOEfS/W5Ce84xyU x1Bkft3i0sOSEzO8Vd9WUeZxwyyjMuCUskTleZDLlprcH+XHrIB3JLd2cIGM8Dnq1oMY Ob+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1VG5bxG7HqPsri4EYIm5+BSGxBbEiXuHTVNmGfjEIz0=; b=K+1bdTfxcGwxkFQaKASp0afiWVUg3m36KRxaKkp9VcjNiPFuEpgR4XydcpTG0N9jBJ c9nc5Wy8v+fIz0r+X2+b2d7dhPGawih8jOgqWGZtCDmwOimnnxGZMDoDOp0zRgVLPZtY X5aUjUThrG5NcJvt2+II8q2mHk6Ago+gQ+JBp1cNHFnW+71+HIg8DFMrpaVLEe5LFUV5 Ha0BRjlmGXIoDGql4W9dB/CHT3X/oN54xyBTQoc0YoMDAVP9MT8q0sOgFhG9MkIC72U6 rUqhHJWB+tyDp8VvXTGxj8myL6J+yUq9JrK2IcwMSGBPQmvoJO/VE3r6/M3oWVquxqBg wcdQ== X-Gm-Message-State: AKaTC02VWERZiakdhMWYth1IusIhFxsjymCMwK9SCE7vspBuFlK8EAiCYyLOWn+KSHm2IwCon3Pv9q4NjMi4BQ== X-Received: by 10.237.37.77 with SMTP id w13mr96475111qtc.197.1481672888505; Tue, 13 Dec 2016 15:48:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.18 with HTTP; Tue, 13 Dec 2016 15:48:08 -0800 (PST) In-Reply-To: <6AA7A937-AEC5-4E6F-9D87-87BC257EF9F8@gmail.com> References: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> <6AA7A937-AEC5-4E6F-9D87-87BC257EF9F8@gmail.com> From: Tom Herbert Date: Tue, 13 Dec 2016 15:48:08 -0800 Message-ID: To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Padma Pillay-Esnault , Robert Moskowitz , ideas@ietf.org Subject: Re: [Ideas] Computing collisions X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 23:48:23 -0000 On Tue, Dec 13, 2016 at 10:35 AM, Dino Farinacci wrot= e: > In LISP, an xTR registers with a 128-bit xTR-ID. This is not the EID. So = we could have an xTR register with a random EID it chooses. Then the map-se= rver determines it is a collision because another xTR-ID has registered wit= h that same EID. The map-server could select a random EID and check locally= if it collides. If it doesn=E2=80=99t, then the xTR registers with a new E= ID (and makes appropriate interface address assignments locally). > > Note the draft-farinacci-lisp-eid-anonymity-01 specs that ephemeral-EIDs = can be used. So when an xTR decided to choose a random IPv6 address as an E= ID and registers. It can ask the map-server if it collides. Today, the map-= server Acks Map-Register messages, but it could Nak and say =E2=80=9Cgo get= a new random ephemeral-EID=E2=80=9D. I like this approach better because t= he allocation happens at the sites within their own address prefix range an= d gives you some obfuscation at the same time. > > If people thing the second approach makes sense, I can spec out in the ab= ove draft how Map-Servers could NAK when there are collisions. Please comme= nt. > That sounds a lot like what we do in ILA. The identifier is split into a registry number and identifier within that. In our case each host is assigned a unique 24 bit registry number, and then each host can independently create identifiers. For the latter we just take a timestamp. Assuming a rate of 100 identifiers per second being allocated we have 21.8 years before wraparound (described appendix B of ILA draft). We'll also check when the identifier is registered with the map system, but in this case collisions should pretty much be nonexistent. Tom > Dino > >> On Dec 13, 2016, at 5:35 AM, Robert Moskowitz = wrote: >> >> Here is some results. >> >> On 12/11/2016 12:03 PM, Padma Pillay-Esnault wrote: >>> Hello Bob >>> >>> Thanks for sending this formula. >>> >>> If we assume that the population is not necessarily a flat space and th= at it is in different separate instances, this could help reduce the collis= ion. >>> >>> Per the ideas problem statement draft, we have discussed about the diff= erent types of devices and whether we could have some policy on what they c= an do. Eg. a camera should not be shopping for clothes or access bank accou= nts .... wouldn't it make sense to put them in different instances with dif= ferent access policies? >>> >>> What are your thoughts on this? >> >> Let's work with a 24 bit ID space which is a population of 16,777,216 >> >> Let's then assume a random distribution of 2^14 (16,384) devices. This = is a 99.97% probablity of a collision. A sure thing. >> >> Now let's assume that there are 256 (2^8) classes of devices and that th= e population is evenly divided. That is 64 devices per class. We now have= reduced our ID space to 16 bits (65,536), but the probablity of a collisio= n with only 64 devices is 3.08%! >> >> But if the division is not equal between the classes and one class has 5= 12 devices the probablity jumps up to 84.67%; again an almost sure thing. >> >> So we can see from this little exercise that dividing our ID space into = groupings can actually reduce the collision risk. Two caveats are clear th= ough. How many classes to use (you can see my effort at this in draft-mosk= owitz-hierarchical-hip) and what if one class out classes all the rest? >> >> You still need to manage collisions. You just may be telling fewer lose= rs to select a new ID. >> >> Now if instead you are talking about reusing your ID space on the assump= tion that these devices are NEVER interacting and thus never 'seeing' the i= nevitable collisions, then, yes, reuse the ID space. But we all know what = assume also spells. >> >> >>> Padma >>> >>> On Thu, Nov 17, 2016 at 1:48 AM, Robert Moskowitz wrote: >>> Here is the equation: >>> >>> probability of collision =3D 1 - e^{-k^2/(2n)} >>> >>> Where n is your max population size (e.g. 2^64) >>> >>> and k is your deployed population (e.g. 7B) >>> >>> Bob >>> >>> _______________________________________________ >>> Ideas mailing list >>> Ideas@ietf.org >>> https://www.ietf.org/mailman/listinfo/ideas >>> >> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Tue Dec 13 20:33:29 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3295129562 for ; Tue, 13 Dec 2016 20:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX8jpk9rOWjv for ; Tue, 13 Dec 2016 20:33:25 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7622612948E for ; Tue, 13 Dec 2016 20:33:25 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 3so1013593pgd.0 for ; Tue, 13 Dec 2016 20:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=69wkSBVZXI18bfkER8HaN/kag4nC4YFe8pkJ7LAYTWY=; b=v5/xrUQv2jK0+SEwtQGoIAEjOh871ylW/gpq7v80uNw+4yvirmevjxfXtefJSzB/cd Z9drcYvTlcsJCy0+V3VCefSmLvkHuw4FD190WMswb0jW3x6687MTIZrf1MCKdSCbFy+b yKO0/ej+p98lCWlNq9wScyStoKANZPnGDL/BrQq0VkA9k6jU2jU20lRtCrS8lCMP24v8 EV67quVOBcRqWsZLbr3WQ9L3kPEQTR2fOeargWI5BM4gx8W+/mClaynWQGOGuLrCQJzY 1ZvgYrnJsUxJxvHuHs51ioOaiQe9tfLbMS0ToAC/eFo3Wwi012qlOBVMI0kUZJDjvB2G HwwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=69wkSBVZXI18bfkER8HaN/kag4nC4YFe8pkJ7LAYTWY=; b=ASlh503892y//uYQcpdgRVhUGxAi/unlnY02t2uX9PCKPMZ4N9lcnOX9xSSxRJ71+T AP5UXP7K0S544hSw/lE+Upic1mbgPrlef4iCJGAphzJf8zVtb/lx6XJUq4qKXiZuzcTc mERVsECegRjnN3gPoiDSqdsciNUYl6vvRB5vMeLEJLOLeouLaXVFIKqXCl3kyl3hnPGb 0HP1bk0fPyUKJrLNflPMn/NzgrReATRuNpvvrcMeyyt9u7G5+EZAoPe4MFevDEwP9+ED /ENeEZg4enmIW/BH+9kmC1CeGL8EPFu5cwAj1qgQezVw2A2Qhvty+ZYV3gjydqvec9H9 CTkQ== X-Gm-Message-State: AKaTC016mzt34IztqYg+DsYnzDaoilSgZ60fbjnbybbIm6RVFeJG58QGUHjvOl//vWiGEA== X-Received: by 10.84.197.1 with SMTP id m1mr204814104pld.159.1481690005096; Tue, 13 Dec 2016 20:33:25 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:945:7274:9118:f6b4? ([2603:3024:151c:55f0:945:7274:9118:f6b4]) by smtp.gmail.com with ESMTPSA id x4sm83708385pgc.14.2016.12.13.20.33.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 20:33:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: Date: Tue, 13 Dec 2016 20:33:23 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <83be2a30-1b46-2397-976e-6e2736921e19@htt-consult.com> <6AA7A937-AEC5-4E6F-9D87-87BC257EF9F8@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Padma Pillay-Esnault , Robert Moskowitz , ideas@ietf.org Subject: Re: [Ideas] Computing collisions X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 04:33:27 -0000 > That sounds a lot like what we do in ILA. The identifier is split into > a registry number and identifier within that. In our case each host is > assigned a unique 24 bit registry number, and then each host can > independently create identifiers. For the latter we just take a > timestamp. Assuming a rate of 100 identifiers per second being > allocated we have 21.8 years before wraparound (described appendix B > of ILA draft). We'll also check when the identifier is registered with > the map system, but in this case collisions should pretty much be > nonexistent. A good algorithm. Nice job. Dino