From heinerhummel@aol.com Tue Dec 4 01:52:50 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0327521F8720 for ; Tue, 4 Dec 2012 01:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GwRTW2ew7sf for ; Tue, 4 Dec 2012 01:52:49 -0800 (PST) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by ietfa.amsl.com (Postfix) with ESMTP id EEFFF21F8717 for ; Tue, 4 Dec 2012 01:52:48 -0800 (PST) Received: from mtaomg-db03.r1000.mx.aol.com (mtaomg-db03.r1000.mx.aol.com [172.29.51.201]) by imr-ma01.mx.aol.com (Outbound Mail Relay) with ESMTP id 6C1C738000372 for ; Tue, 4 Dec 2012 04:52:48 -0500 (EST) Received: from core-dqe005a.r1000.mail.aol.com (core-dqe005.r1000.mail.aol.com [172.29.162.81]) by mtaomg-db03.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 220E7E000087 for ; Tue, 4 Dec 2012 04:52:48 -0500 (EST) References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <50A2D6BC.602@joelhalpern.com> To: rrg@irtf.org In-Reply-To: X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CFA01C401EE2C5_12C8_11C23C_webmail-m180.sysops.aol.com" X-Mailer: AOL Webmail 37208-STANDARD Received: from 178.27.21.1 by webmail-m180.sysops.aol.com (64.12.224.137) with HTTP (WebMailUI); Tue, 04 Dec 2012 04:52:47 -0500 Message-Id: <8CFA01C40155D41-12C8-49F61@webmail-m180.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Tue, 4 Dec 2012 04:52:48 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1354614768; bh=DJ/IvsmUxRaI72DiyC7aPDxstwRKedUx9NMQ0ZOQfYA=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=W9thl0yIx2q7mq4i/9YEK5PfGcJUEVBv9gdRXJAc8aTg2zih8KpLxXIfYvnnibpR/ Eqn4CtRP2r8qptEnbr7Xsz9zuHjJRssn/aNkZNeIFE7ceFeCVZXhd5DZrWowaQDTRy uw2gbQAOtoJ3idcppE4A38dQNGDTP4EZxtZE+xg4= X-AOL-SCOLL-SCORE: 0:2:455968224:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c950bdc7f02607 Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 09:52:50 -0000 This is a multi-part message in MIME format. ----------MB_8CFA01C401EE2C5_12C8_11C23C_webmail-m180.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" The recent storm in a glass of water has calmed down again. Silence has ret= urned. I think the outcome of the RRG doesn't satisfy most of the participants (be= sides few exceptions) and should not thrill the IAB at all.Precious time by= the years has been wasted. The problem due to the IPv4 address depletion t= urns out to be much worse than the scalability problem.=20 LISP appears to be a pull-variant replacing the legacy push-model. Loc-id-s= plit is something else: E.g. my TARA model which doesn't do EID-to-RLOC ma= pping nor disseminate such info (neither by pull nor by push) to make sure= that the packet is sent to the right ETR. It simple complies with Elvis Pr= esley's "Return to sender, address unknown, noch such number, no such phone= ..." if it were sent to the wrong/ not anymore up-to-date ETR - =20 or would append a broadcast search inside the surrounding geopatch. There is more missing: how to use TTL, peeping into the inner header ?:-( H= ow to form and use a Multicast-Locator, or an Anycast-Locator ? How would i= t handle a roaming Multicast-sender?=20 Above all however there is no working strategy to deal with the situation w= here ipv4 is not globally unique anymore. Neither LISP nor ILNP have so far= presented a solution. And the RRG has never discussed the theoretical b= asics !!! In principle the 4 octet sized ipv4 address must be extended.My p= roposal: by two additional leading octets - in mind. This doesn't mean that= they have to be placed directly in front of the 4 octets. Particularly, t= he value =3D 0000H might be equivalent to "the two octets aren't placed an= ywhere at all". But other values might be placed somewhere (e.g. being par= t of the locator).=20 In the (current) TARA concept it would be the geopatch number in the range = 1:64800, resp. the number 64801 for well-known Anycast, and 64802 for well-= known Multicast. There are problems by the numbers. Enough for just the networking layer (TC= P should take care by itself when ipv4 looses its globally uniqueness )! I am not a friend of ipv6 either. Just to share my worries: Imagine a multi= cast instance where sender and receivers are roaming, where sender and rece= ivers are a mix of ipv4 and ipv6 users, in a world where ipv4 has lost glob= ally uniqueness. Brrrrh. Hibernation is not the right answer. Heiner _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg =20 ----------MB_8CFA01C401EE2C5_12C8_11C23C_webmail-m180.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" 
The=
 recent storm in a glass of water has calmed down again. Silence has return=
ed.
I think the outcome of the RRG doesn't=
 satisfy most of the participants (besides few exceptions) and should not t=
hrill the IAB at all.Precious tim=
e by the years has been wasted. The problem due to the IPv4 address depleti=
on turns out to be much worse than the scalability problem. 
=
LISP appears to be a pull-variant replacing the legacy push-model. Loc-id-s=
plit is something else: E.g. my TARA model which  doesn't=
 do EID-to-RLOC mapping nor  disseminate such info (neither by pull nor by =
push) to make sure that the packet is sent to the right ETR. It simple complies with Elvis Presley's "Return=
 to sender, address unknown, noch such number, no such phone..." if it were=
 sent to the wrong/ not anymore up-to-date  ETR -  
<=
span class=3D"Apple-style-span" style=3D"font-family: Arial, Helvetica, san=
s-serif; font-size: small; ">or would append a broadcast search inside the surrounding geopatch.
There is more missing: how to use TTL, =
peeping into the inner header ?:-( How to form and use a Multicast-Locator,=
 or an Anycast-Locator ? How would it  handle a roaming Multicast-sender? 
Above all however there is no working strategy to deal with t=
he situation where ipv4 is not globally unique anymore. Neither LISP nor IL=
NP have so far    presented a solution.  proposal: by two additional leading octets - in mind. This does=
n't mean that they have to be placed directly in front of the 4 octets.  Pa=
rticularly, the value =3D 0000H might =
be equivalent to "the two octets  aren't placed anywhere at all". But other=
 values might be placed somewhere  (e.g. being part of the locator). <=
/span>
In the (current) TARA concep=
t it would be the geopatch number in the range 1:64800, resp. the number 64=
801 for well-known Anycast, and 64802 for well-known Multicast.
There are problems by the numbers. Enou=
gh for just the networking layer (TCP should take care by itself when ipv4 =
looses its globally uniqueness )!
I am not a friend of ipv6 either. Just to share my worries: Imagine a=
 multicast instance where sender and receivers are roaming, where sender an=
d receivers are a mix of ipv4 and ipv6 users, in a world where ipv4 has los=
t globally uniqueness. Brrrrh.
Heiner


















_______________________________________________
rrg mailing list
rrg@irtf.org
http=
://www.irtf.org/mailman/listinfo/rrg
----------MB_8CFA01C401EE2C5_12C8_11C23C_webmail-m180.sysops.aol.com-- From heinerhummel@aol.com Tue Dec 4 04:06:16 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CDB21F86EE for ; Tue, 4 Dec 2012 04:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiV647oqit7M for ; Tue, 4 Dec 2012 04:06:16 -0800 (PST) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by ietfa.amsl.com (Postfix) with ESMTP id C653A21F86EC for ; Tue, 4 Dec 2012 04:06:15 -0800 (PST) Received: from mtaomg-mb01.r1000.mx.aol.com (mtaomg-mb01.r1000.mx.aol.com [172.29.41.72]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id qB4C67rK011113 for ; Tue, 4 Dec 2012 07:06:07 -0500 Received: from core-dqe005a.r1000.mail.aol.com (core-dqe005.r1000.mail.aol.com [172.29.162.81]) by mtaomg-mb01.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 3B000E00008A for ; Tue, 4 Dec 2012 07:06:07 -0500 (EST) References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <50A2D6BC.602@joelhalpern.com> <8CFA01C40155D41-12C8-49F61@webmail-m180.sysops.aol.com> <8CFA01D531ECFEC-12C8-49FBC@webmail-m180.sysops.aol.com> <8CFA02E6231FFC6-1CD8-3CA@webmail-d166.sysops.aol.com> To: rrg@irtf.org In-Reply-To: <8CFA02E6231FFC6-1CD8-3CA@webmail-d166.sysops.aol.com> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CFA02EE018862F_1CD8_D21_webmail-d166.sysops.aol.com" X-Mailer: AOL Webmail 37242-STANDARD Received: from 178.27.21.1 by webmail-d166.sysops.aol.com (205.188.252.78) with HTTP (WebMailUI); Tue, 04 Dec 2012 07:06:07 -0500 Message-Id: <8CFA02EE00A3DE3-1CD8-3FB@webmail-d166.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Tue, 4 Dec 2012 07:06:07 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1354622767; bh=hE8KscE8HwdZOhMeIVx03V1us9JZ3DRd+3X0GNs0qcY=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=EkzH3fgA0INgXkSnb2NywPUd9xpaK+RefBSUswgwNDQjKehzNsz57T7jngnxwTfSi uXLaWnajq9ucopO3fI8A+fnoH6NGqSAObPktNGLxYrmY1V3Gzd8i4R6bbNJwMf+YwL Huqg/wCEFTDMUgPGsvHXxg5Irg61aoaXC0I22y8U= X-AOL-SCOLL-SCORE: 0:2:441982688:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294850bde72f25ce Subject: [rrg] RRG to hibernation (resent) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 12:06:16 -0000 This is a multi-part message in MIME format. ----------MB_8CFA02EE018862F_1CD8_D21_webmail-d166.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" The recent storm in a glass of water has calmed down again. Silence has ret= urned. I think the outcome of the RRG doesn't satisfy most of the participants (be= sides few exceptions) and should not thrill the IAB at all. Precious time by the years has been wasted. The problem due to the IPv4 add= ress depletion turns out to be much worse than the scalability problem.=20 LISP appears to be a pull-variant replacing the legacy push-model. Loc-id-s= plit is something else: E.g. my TARA model which doesn't do EID-to-RLOC mapping nor disseminate such info (neither by pull nor by push) to make su= re that the packet is sent to the right ETR. It simple complies with=20 Elvis Presley's "Return to sender, address unknown, noch such number, no su= ch phone..." if it were sent to the wrong/ not anymore up-to-date =20 ETR - or would append a broadcast search inside the surrounding geopatch. There is more missing: how to use TTL, peeping into the inner header ?:-( H= ow to form and use a Multicast-Locator, or an Anycast-Locator ?=20 How would it handle a roaming Multicast-sender?=20 Above all however there is no working strategy to deal with the situation w= here ipv4 is not globally unique anymore.=20 Neither LISP nor ILNP have so far presented a solution. And the RRG has = never discussed the theoretical basics !!!=20 In principle the 4 octet sized ipv4 address must be extended.My proposal: b= y two additional leading octets - in mind.=20 This doesn't mean that they have to be placed directly in front of the 4 o= ctets. Particularly, the value =3D 0000H might be equivalent to=20 "the two octets aren't placed anywhere at all". But other values might be = placed somewhere (e.g. being part of the locator).=20 In the (current) TARA concept it would be the geopatch number in the range = 1:64800, resp. the number 64801 for well-known Anycast,=20 and 64802 for well-known Multicast. There are problems by the numbers. Enough for just the network layer (TCP s= hould take care by itself when ipv4 looses its globally uniqueness )! I am not a friend of ipv6 either. Just to share my worries: Imagine a multi= cast instance where sender and receivers are roaming, where sender=20 and receivers are a mix of ipv4 and ipv6 users, in a world where ipv4 has l= ost globally uniqueness. Brrrrh. Hibernation is not the right answer. Heiner _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg =20 =20 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg =20 =20 =20 ----------MB_8CFA02EE018862F_1CD8_D21_webmail-d166.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" 

The recent storm in a glass of water=
 has calmed down again. Silence has returned.
I think the outcome of the =
RRG doesn't satisfy most of the participants (besides few exceptions) and s=
hould not thrill the IAB at all.
Precious time by the ye=
ars has been wasted. The problem due to the IPv4 address depletion turns ou=
t to be much worse than the scalability problem. 
LISP appears to be a pull-variant replacing =
the legacy push-model. Loc-id-split is something else: E.=
g. my TARA model which  doesn't do EID-to-RLOC
mapping nor  disseminate su=
ch info (neither by pull nor by push) to make sure that the packet is sent =
to the right ETR. It simple complies with 
Elvis Presley's "Return to sender, addre=
ss unknown, noch such number, no such phone..." if =
it were sent to the wrong/ not anymore up-to-date  
ETR -  or would There is more missing: how to use TTL, peeping into the inner header ?:-( =
How to form and use a Multicast-Locator, or an Anycast-Locator ? 
How would it  handle a=
 roaming Multicast-sender? 


Above all however there is no working strategy to deal with =
the situation where ipv4 is not globally unique anymore. 
= 
And the RRG has never discussed the theoretical basi=
cs !!! 
In principle the 4 octet sized ipv4 =
address must be extended.My proposal: by two additional leading octets - in mind.&n=
bsp;
This doesn't mean that they have to be placed directly i=
n front of the  4 octets.  Partic=
ularly, the value =3D 0000H might be e=
quivalent to 
"the two octets  aren't placed anywhere at=
 all". But other values might be placed somewhere  =
(e.g. being part of the locator). 
In the (current) TARA=
 concept it would be the geopatch number in the range 1:64800, resp. the nu=
mber 64801 for well-known Anycast, 
and 64802 for well-k=
nown Multicast.
=


There are problems by the numbers. Enough for just the netwo=
rk layer (TCP should take care by itself when ipv4 looses its globally uniq=
ueness )!
I am not a friend of ipv6 either. Just to share my =
worries: Imagine a multicast instance where sender and receivers are roamin=
g, where sender 
and receivers are a mix of ipv4 and ipv=
6 users, in a world where ipv4 has lost globally uniqueness. Brrrrh.=





Hibernation is not the right answer.
Heiner




































_______________________________________________
rrg mailing list
rrg@irtf.org
http=
://www.irtf.org/mailman/listinfo/rrg
=20
=20 
________________________________________=
_______
rrg mailing list
rrg@irtf.org
http=
://www.irtf.org/mailman/listinfo/rrg
=20
=20
----------MB_8CFA02EE018862F_1CD8_D21_webmail-d166.sysops.aol.com-- From wherrin@gmail.com Tue Dec 4 05:42:25 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E0021F898B for ; Tue, 4 Dec 2012 05:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKI8wd89i9Qa for ; Tue, 4 Dec 2012 05:42:24 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1DB21F8941 for ; Tue, 4 Dec 2012 05:42:24 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n9so5055974oag.13 for ; Tue, 04 Dec 2012 05:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=5PFDKqwwBKgS2CNELP+arsbGukbZ09eXpUMqWGkC70Y=; b=MvsFe8UAHsWSC2Ib4pfPgaG3eDyqxVVNj2W7a/IAPjPLgIsc1wNklB30HhCCtp7SDp IYwj+qbXfblSUQiLX8Gf+GKNBbPfv+qPQ8365T4smvUauOy7yUIK/X2A0WLm3yBDfqBk WAAd7sqIX9Sf9pahD2xLThHjNe3Ctd/gTrVBthZa+IpZOz+ZgQdMFYx3tzPqYhy8xvL1 CsfpLNWSAiX8blpj1MVwh/kdqOxCssrTdOajjF9q/3+hcEOKQsEf3b4YZV/T3lYl31cL QlSSzoiTSLrnes0CLwGo8jO0Uww49QDx9jJw5brLRD9O8GDjZFpixjn3+Ix+ayPQDhor rVug== Received: by 10.60.32.39 with SMTP id f7mr11209359oei.86.1354628543621; Tue, 04 Dec 2012 05:42:23 -0800 (PST) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.182.96.233 with HTTP; Tue, 4 Dec 2012 05:42:03 -0800 (PST) In-Reply-To: <8CFA01C40155D41-12C8-49F61@webmail-m180.sysops.aol.com> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <50A2D6BC.602@joelhalpern.com> <8CFA01C40155D41-12C8-49F61@webmail-m180.sysops.aol.com> From: William Herrin Date: Tue, 4 Dec 2012 08:42:03 -0500 X-Google-Sender-Auth: RgV-KwbfFoOs4CmI0xU8BmLWi1g Message-ID: To: heinerhummel@aol.com Content-Type: text/plain; charset=ISO-8859-1 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 13:42:25 -0000 On Tue, Dec 4, 2012 at 4:52 AM, wrote: > Above all however there is no working strategy to deal with the situation > where ipv4 is not globally unique anymore. Neither LISP nor ILNP have so far > presented a solution. And the RRG has never discussed the theoretical basics > !!! In principle the 4 octet sized ipv4 address must be extended.My > proposal: by two additional leading octets - in mind. This doesn't mean that > they have to be placed directly in front of the 4 octets. Particularly, the > value = 0000H might be equivalent to "the two octets aren't placed anywhere > at all". But other values might be placed somewhere (e.g. being part of the > locator). Hi Heiner, I think the day for this has past. For better or for worse IPv6 is slowly happening. However, if we were going to extend IPv4 with more bits, here's one strategy: http://bill.herrin.us/network/ipxl.html Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From heinerhummel@aol.com Tue Dec 4 09:58:25 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F1E21F8C86 for ; Tue, 4 Dec 2012 09:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcWpYOtZZObW for ; Tue, 4 Dec 2012 09:58:24 -0800 (PST) Received: from imr-da01.mx.aol.com (imr-da01.mx.aol.com [205.188.105.143]) by ietfa.amsl.com (Postfix) with ESMTP id 444F221F8C80 for ; Tue, 4 Dec 2012 09:58:24 -0800 (PST) Received: from mtaomg-mb05.r1000.mx.aol.com (mtaomg-mb05.r1000.mx.aol.com [172.29.41.76]) by imr-da01.mx.aol.com (Outbound Mail Relay) with ESMTP id 891D31C00010C; Tue, 4 Dec 2012 12:58:23 -0500 (EST) Received: from core-dqe005a.r1000.mail.aol.com (core-dqe005.r1000.mail.aol.com [172.29.162.81]) by mtaomg-mb05.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 6CB1BE000088; Tue, 4 Dec 2012 12:58:19 -0500 (EST) References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <50A2D6BC.602@joelhalpern.com> <8CFA01C40155D41-12C8-49F61@webmail-m180.sysops.aol.com> To: bill@herrin.us In-Reply-To: X-MB-Message-Source: WebUI Received: from 178.27.21.1 by webmail-d070.sysops.aol.com (205.188.92.108) with HTTP (WebMailUI); Tue, 04 Dec 2012 12:58:18 -0500 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CFA060139454F9_380_D72D_webmail-d070.sysops.aol.com" X-Mailer: AOL Webmail 37242-STANDARD Message-Id: <8CFA060139454F9-380-3AAD@webmail-d070.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Tue, 4 Dec 2012 12:58:18 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1354643900; bh=jtAjjr2KvDiP0J15c4ZL9AfU0AxVFDU1FGagSdhWbIs=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=IYo656AKUIOC6BoGLpilG1NALPnnu77gTGreHatvsf2fno7MXovNClME9leipNczR 0e/Nu25Znsn/FaeoI9P2iKgBZ9jayNT0sPOf79wa+boow4HZtajrNfNgN4uSZiAueI Ylqqk/0Js2dJWxGyyvdERkWC5FWOKLFGbrBk7pbg= X-AOL-SCOLL-SCORE: 0:2:504844544:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294c50be39bb0771 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 17:58:25 -0000 This is a multi-part message in MIME format. ----------MB_8CFA060139454F9_380_D72D_webmail-d070.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Bill, you wrote: "I think the day for this has past. For better or for worse IPv6 is slowly happening".=20 Well, without any concept how to fill 16 octets with routable information s= uch that all users can be mobile while being involved in unicast or=20 anycast or multicast. "However, if we were going to extend IPv4 with more bits, here's one strategy:" http://bill.herrin.us/network/ipxl.html =20 I also thought about the option field, though not as fine-tuned as you did.= And: that the leading octets might be placed=20 there and eventually moved from there to some other place like to a locator= and vice versa. First of all however that in the abstraction we have to extend ipv4 with leading octets. = =20 Regards, Heiner -----Original Message----- From: William Herrin To: heinerhummel Cc: rrg Sent: Tue, Dec 4, 2012 2:42 pm Subject: Re: [rrg] RRG to hibernation On Tue, Dec 4, 2012 at 4:52 AM, wrote: > Above all however there is no working strategy to deal with the situation > where ipv4 is not globally unique anymore. Neither LISP nor ILNP have so = far > presented a solution. And the RRG has never discussed the theoretical bas= ics > !!! In principle the 4 octet sized ipv4 address must be extended.My > proposal: by two additional leading octets - in mind. This doesn't mean t= hat > they have to be placed directly in front of the 4 octets. Particularly, = the > value =3D 0000H might be equivalent to "the two octets aren't placed any= where > at all". But other values might be placed somewhere (e.g. being part of = the > locator). Hi Heiner, I think the day for this has past. For better or for worse IPv6 is slowly happening. However, if we were going to extend IPv4 with more bits, here's one strategy: http://bill.herrin.us/network/ipxl.html Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 =20 ----------MB_8CFA060139454F9_380_D72D_webmail-d070.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" 
Bill, you wrote:
"I think the day for this has past. For better or for worse IPv6 is
slowly happening". 
Well, without any conc=
ept how to fill 16 octets with routable information such that all users can=
 be mobile while being involved in unicast or 
<=
tt>anycast or multicast.



"However, if we were going to extend IPv4 with more
bits, here's one strategy:"
= http://bill.herrin.us/network/ipxl.html
 
I also thought about the option fi=
eld, though not as fine-tuned as you did. And: that the leading octets migh=
t be placed 
there and eventually moved fr=
om there to some other place like to a locator and vice versa. First of all=
 however  that  in the abstraction we have to
e=
xtend ipv4  with leading octets.                                           =
          
Regards,
=






On Tue, Dec 4, 2012 at 4:52 AM,  <heinerhummel@aol.com> wrote:
> Above all however there is no working strategy to deal with the situat=
ion
> where ipv4 is not globally unique anymore. Neither LISP nor ILNP have =
so far
> presented a solution. And the RRG has never discussed the theoretical =
basics
> !!! In principle the 4 octet sized ipv4 address must be extended.My
> proposal: by two additional leading octets - in mind. This doesn't mea=
n that
> they have to be placed directly in front of the 4 octets.  Particularl=
y, the
> value =3D 0000H might be equivalent to "the two octets  aren't placed =
anywhere
> at all". But other values might be placed somewhere  (e.g. being part =
of the
> locator).

Hi Heiner,

I think the day for this has past. For better or for worse IPv6 is
slowly happening. However, if we were going to extend IPv4 with more
bits, here's one strategy:

http:=
//bill.herrin.us/network/ipxl.html

Regards,
Bill Herrin


--=20
William D. Herrin ................ h=
errin@dirtside.com  bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
----------MB_8CFA060139454F9_380_D72D_webmail-d070.sysops.aol.com-- From swb@internet2.edu Tue Dec 4 10:20:31 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00CE21F8CA1 for ; Tue, 4 Dec 2012 10:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZrPBwSGqki9 for ; Tue, 4 Dec 2012 10:20:29 -0800 (PST) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by ietfa.amsl.com (Postfix) with ESMTP id 6759421F8CA6 for ; Tue, 4 Dec 2012 10:20:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id D5F8E100007; Tue, 4 Dec 2012 13:20:28 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-mlCVF2gb73; Tue, 4 Dec 2012 13:20:28 -0500 (EST) Received: from swbi2mbp.local (cpe-67-241-75-185.twcny.res.rr.com [67.241.75.185]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id 078B9100001; Tue, 4 Dec 2012 13:20:27 -0500 (EST) Message-ID: <50BE3EEB.20700@internet2.edu> Date: Tue, 04 Dec 2012 13:20:27 -0500 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tony Li References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> In-Reply-To: <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:20:31 -0000 On 11/13/12 03:21, Tony Li allegedly wrote: > > On Nov 12, 2012, at 11:49 PM, Christian Huitema wrote: > >>> No. Today if you have a set of PA prefixes and your address changes from >> one >>> to another, your TCP connections all break. >> >> That's true, has been for quite some time, and yet nobody seems to be doing >> much about it. Which makes you wonder how big of a problem that is in >> practice. If applications were really hurting, you would hear complaints >> from application developers. But you don't. The applications that need >> reliable long duration sessions incorporate some trivial checkpoint and >> restart mechanism, or some pretty elaborate consistency protocols for big >> databases. They probably would do that no matter what the reliability of >> TCP, as long as it is not "perfect." And PA renumbering is probably not very >> high in their list of "stuff that occasionally break TCP." > > > They don't do PA renumbering. They do PI instead. Clearly checkpoint and restart are not sufficient, otherwise they could do PA easily. I don't know who "they" is but applications that want to be robust across network changes have their own identity-related functions. They have done their own loc/id split, for the identities that matter to them (app/session level), and use it to sustain sessions. They don't care about or need what this list is talking about. swb From swb@internet2.edu Tue Dec 4 10:26:55 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAB221F8CA9 for ; Tue, 4 Dec 2012 10:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOTO4UOQrNge for ; Tue, 4 Dec 2012 10:26:54 -0800 (PST) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by ietfa.amsl.com (Postfix) with ESMTP id D847C21F8C70 for ; Tue, 4 Dec 2012 10:26:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id 84327100001; Tue, 4 Dec 2012 13:26:54 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5PAXCAWtSe2; Tue, 4 Dec 2012 13:26:54 -0500 (EST) Received: from swbi2mbp.local (cpe-67-241-75-185.twcny.res.rr.com [67.241.75.185]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id C887A100007; Tue, 4 Dec 2012 13:26:53 -0500 (EST) Message-ID: <50BE406C.3020205@internet2.edu> Date: Tue, 04 Dec 2012 13:26:52 -0500 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dae Young KIM References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <50A2D6BC.602@joelhalpern.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:26:55 -0000 On 11/13/12 20:17, Dae Young KIM allegedly wrote: > OK, Shim6 is not an LIS. But, the shim is between L3 and L4 while a > session shim would be between L4 and APP. Usually that's handled in libraries used by apps. We don't use X.200 layering much. From dwing@cisco.com Tue Dec 4 10:54:48 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D084021F8CCC for ; Tue, 4 Dec 2012 10:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.704 X-Spam-Level: X-Spam-Status: No, score=-109.704 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMlF9LiRRT45 for ; Tue, 4 Dec 2012 10:54:47 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7418721F8CC8 for ; Tue, 4 Dec 2012 10:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6907; q=dns/txt; s=iport; t=1354647287; x=1355856887; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=vIje9Ui1hFYF9H+oQgoMlr1hJc1ajfca2jIwMFaiyTQ=; b=fF+xljeGcSRsZmDswYLjsmKtqmTq4bHJizhd/tuDNp3EYGWvFYZOnL2r 2mzpWMKzPSd2I7deF9/vJmJFuts5j5qcGNVi0ewME1eZusrHJohIBG5ws JHuFk3mjmIbuOPJchqrAmyLyNJZM05pspN3s0kdCVBqMZFtdoVex1LCbX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoGACJGvlCrRDoH/2dsb2JhbABEg0e6aBZzgh4BAQECAQEIAg4iLwEUBwEDAgkOAwQBAQEnBxktAwEFCAIEARILBQmHcQUNsD2QXow3BYQ8A4hfhRqICoEcjyuDEw X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="65635408" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 04 Dec 2012 18:54:46 +0000 Received: from DWINGWS01 ([10.156.17.137]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB4Isjko008923; Tue, 4 Dec 2012 18:54:45 GMT From: "Dan Wing" To: "'Robin Whittle'" , "'RRG'" References: <50A19CA4.8000007@firstpr.com.au> <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> <50A1CB11.4050809@firstpr.com.au> <78553EF9-D0D4-4914-89CC-E9CC1F435FDB@castlepoint.net> <50A1DF3F.6020801@firstpr.com.au> <05AD8FE9-B1D1-4694-9F69-61260B0FC1DA@castlepoint.net> <50A1F7CF.2080402@firstpr.com.au> In-Reply-To: <50A1F7CF.2080402@firstpr.com.au> Date: Tue, 4 Dec 2012 10:54:46 -0800 Message-ID: <020201cdd250$d44bb380$7ce31a80$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbQgB0+8qM2Z7HuWkH6YzgzeuABQJDxHSPAO0NRKgBxaaE7wCRT1fpAR9wJVYBe4CeiAL8bi2TlhUhkMA= Content-Language: en-us Subject: Re: [rrg] Happy Eyeballs RFC6555: app changes so dual-stack IPv4/6 is usable X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:54:48 -0000 > -----Original Message----- > From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of > Robin Whittle > Sent: Monday, November 12, 2012 11:34 PM > To: RRG > Subject: Re: [rrg] Happy Eyeballs RFC6555: app changes so dual-stack > IPv4/6 is usable > > Short version: Discussing the implementation of Happy Eyeballs or > something similar to it in the operating system, rather > than in the application. > > Hi Shane, > > You wrote: > > >> It seems that applications need to be altered, by the addition of a > >> Happy Eyeballs algorithm, to provide reliable performance when the > >> dual-stack host is connected to both IPv4 and IPv6. This is > >> unfortunate, but not surprising - since these are two separate > Internets. > > > No. Note that Mac OS X _operating_system_ implements a form of Happy > > Eyeballs. Thus, there is no need for apps on top of OS X to implement > > it. IMO, the only reason apps such as Firefox & Chrome have > > implemented Happy Eyeballs is because Windows does not implement Happy > > Eyeballs, so the apps vendors were forced to work around it. > > > > This illustrates the fundamental conundrum we're facing. Apps vendors > > are making up for the deficiencies of the underlying operating system > > network stacks. If we give the O/S vendors something to latch on to, > > then it makes everyone's lives improved. > > Maybe it is difficult or perhaps impossible to implement Happy Eyeballs > or the like in the OS in a manner which never causes problems, no matter > the nature of the application. > > The example algorithm in section 6 of RFC 6555 involves sending a SYN to > the IPv6 address (assuming the address policy for the host prefers IPv6, > which I understand is typically the case for a dual-stack OS), waiting > 300ms and then sending a SYN to the IPv4 address if there was no > response in that time. From Australia, and especially on a 3G/4G mobile > link, 300ms is a rather short time in which to expect a response from > servers in most of the world. Hi. Happy Eyeballs co-author here. For a good long while, both Firefox and Chrome will initiate a connection to the next IP address after 250ms-300ms. This has worked, with little notice or fanfare, for years and years. For Happy Eyeballs, this mechanism was modified to be aware of the IP address family so that the second connection is always on the other address family. > Assuming the IPv6 address does produce an > ACK which arrives later than 300ms, then the host is sending out two > SYNs instead of one, and likely receiving two SYNs too. This is > something of an extra burden on a 3G/4G link. User experience tends to be in conflict with battery life and network utilization. RFC6555 only suggests timers; different timers could be imagined. And Apple's implementation tweaks itself to become sensitive to the actual connection times seen over v4 and over v6. > Though Happy Eyeballs is documented for TCP, the Wikipedia page mentions > it being used to choose between TCP and SCTP. I don't think it could > work with UDP, since there is no SYN/ACK arrangement. ICE (RFC5245) runs over UDP and was built for NAT traversal and has a request/response semantic (to determine if a path is viable). It is used for IPv6 transition (see RFC6157), and there is ongoing work to suggest implementations be more aggressive in trying both address families instead of trying a huge list of (broken) IPv6 candidate addresses (see draft-reddy-mmusic-ice-happy-eyeballs). > A Happy Eyeballs- > like algorithm could be implemented for UDP with the involvement of the > server, but this would have to be at the application level. For UDP, you need a request/response protocol. Almost all UDP protocols are request/response (DNS, NTP, ICE (RFC5245)). > Perhaps this means that dual-stack problems it is intended to solve > can't be solved for UDP-based protocols without suitable application > changes for the client and server. Or, the OS could learn that TCP is not working well to a certain IPv"X" subnet, but is working well using IPv"Y". That is exactly what Apple's OS-based implementation of Happy Eyeballs learns. > This article from 2011-11-12 may not reflect the current behavior of the > "Happy Eyeballs" algorithm (it is actually a different algorithm) in OS- > X: > > https://labs.ripe.net/Members/emileaben/hampered-eyeballs > > however it does mention how it works, or worked, and some problems which > arose, presumably with applications which use the traditional > getaddrinfo() call, rather than another methods which are apparently > unique to OS-X. > > "It looks like OS X Lion makes debugging connectivity issues to > dual-stacked websites a royal pain, with the associated cost for > support staff. While the Mac OS X Lion + Safari combination looks > to be a true "Happy Eyeballs" implementation, the combination of > OS X Lion with anything that just uses getaddrinfo() does not make > the eyeballs much happier it seems." > > "If the way Mac OS X implemented 'Happy Eyeballs'-like functionality > becomes more widespread (please don't do this Microsoft!) it will > cause perfectly fine dual-stack hosts with roughly equal performance > over both protocols, to select the legacy IPv4 protocol in roughly > half of the cases. This makes the IPv6 capacity in networks > under-used and that is bad for a few reasons: > > This page reports on problems with OS-X 10.7 (Lion) in April this year. > > http://shibboleth.net/pipermail/dev/2012-April/000651.html > > From 2012-08-10 more reports of trouble with OS-X and particular > browsers - Safari and Firefox: > > > http://www.jumpertz.net/1/post/2012/11/going-cross-eyed-with-happy- > eyeballs.html > > A 2012-09-11 Cisco presentation doesn't mention any difficulties: > > http://www.data.proidea.org.pl/euronog/2edycja/materials/Krzysztof_Mazep > a-IPv4_vs_IPv6-Happy_Eyeballs.pdf > > Geoff Huston and George Michaelson (2012-04-16) mention various items of > interest to these questions and mention problems with the OS-X > implementation. > > https://ripe64.ripe.net/presentations/78-2012-04-16-ripe64.pdf > > > This is not a proper survey of the field. I am just suggesting that it > may not be straightforward to implement the Happy Eyeballs algorithm in > the OS, especially considering that various apps may access the OS in > different ways, may be doing their own version of Happy Eyeballs etc. > and that the OS approach might upset some assumptions made in higher > level protocols. Yes, it's very difficult to do Happy Eyeballs in the OS. Especially that every application has a different definition of what it considers "happiness". -d From tony.li@tony.li Tue Dec 4 11:18:54 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A42E21F8CA0 for ; Tue, 4 Dec 2012 11:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJLhN-riZBwc for ; Tue, 4 Dec 2012 11:18:53 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id AF95121F8C97 for ; Tue, 4 Dec 2012 11:18:53 -0800 (PST) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta01.emeryville.ca.mail.comcast.net with comcast id XSpW1k05u0EPchoA1XJt2Q; Tue, 04 Dec 2012 19:18:53 +0000 Received: from [10.155.35.198] ([128.107.239.234]) by omta01.emeryville.ca.mail.comcast.net with comcast id XXGe1k00C547xYo8MXGgs0; Tue, 04 Dec 2012 19:16:51 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <50BE3EEB.20700@internet2.edu> Date: Tue, 4 Dec 2012 11:16:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> To: Scott Brim X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354648733; bh=uLYZHx8j5+K/TlGPMg/46XyEaPKuicwCOtaBFCuNXDw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=jdMHN3DKhz2fq6bW175DnyoCEzzLT1cdmdl3dQFrBns4ck3bRbskQbu2bc+A2/7o3 eUn0KbaDNGY/Dju2xDScKDBl3tkScf53vpzZU/z/MFV5RvITh5sa5/Su6pgHeL7M0R xYwELZE76oA8Op2lETmLCtU+/MgGKV+tMba2eV4YzRhYh7YgVt38whnwNqd1ZMYTJe MQmP2sM/6yq7tOKtXs93O/Z/c0yOuGIaVOqVnLfYgHd60X/uzl7y2CcKVDUwTryMKw 1/jAtTmL9DCckirvWvxEE13sXOB9bis8Wz8jz/iN3SiUEPWSeGooe3L5MatVKJ640d jLvYdsQNvvm0w== Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:18:54 -0000 On Dec 4, 2012, at 10:20 AM, Scott Brim wrote: > I don't know who "they" is but applications that want to be robust > across network changes have their own identity-related functions. = They > have done their own loc/id split, for the identities that matter to = them > (app/session level), and use it to sustain sessions. They don't care > about or need what this list is talking about. Hi Scott, Doesn't that strike you as a layering violation? Shouldn't a stack = shield applications from having to create these mechanisms? Regards, Tony From dykim6@gmail.com Tue Dec 4 15:02:58 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA32F21F8BD9 for ; Tue, 4 Dec 2012 15:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DICKDl5QvQ6O for ; Tue, 4 Dec 2012 15:02:58 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3270421F871F for ; Tue, 4 Dec 2012 15:02:58 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3050113qcs.13 for ; Tue, 04 Dec 2012 15:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ur6JzRHbzrKP8AxQO8SoDwpmGiD9P7JG3JUKsENz8pw=; b=fx4E+TcYrQiVz+16dIuB6aZCaMhjqw32Zap1PoSZj0echv3eVgTTrmBnvz53HdVUfl M041iizFncxdatuCnhSavMcRP4IE+5bvG0rEcbm2aU5xwlWXtllrnPfiZtm5cXRMNiOJ lnfJ590Y9aP+ZdYn3iNNDMsiATqWdaSHrzkDola5IPAwuMMWGo1104lqtYPjUspar5Wv F+pfAg048Q69czyIVY2zzICctZclMM14WBob6aVWKBxl3L5DsbEI1Y3ni9ffCvr2GYpK TGtaQ2g15F8rMn68gF2pLq1pcjpM+LTjMJDtgLtA+eM6nhXToHTUYVCGIbr12+Qs3obU QW6w== Received: by 10.49.121.40 with SMTP id lh8mr28698967qeb.30.1354662177626; Tue, 04 Dec 2012 15:02:57 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 4 Dec 2012 15:02:37 -0800 (PST) In-Reply-To: <50BE406C.3020205@internet2.edu> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <50A2D6BC.602@joelhalpern.com> <50BE406C.3020205@internet2.edu> From: Dae Young KIM Date: Wed, 5 Dec 2012 08:02:37 +0900 X-Google-Sender-Auth: 2p3951A28ILfdwylRt--m4w6zZs Message-ID: To: Scott Brim Content-Type: multipart/alternative; boundary=047d7bdc1be4e35abe04d00edd27 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 23:02:58 -0000 --047d7bdc1be4e35abe04d00edd27 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 3:26 AM, Scott Brim wrote: > On 11/13/12 20:17, Dae Young KIM allegedly wrote: > > OK, Shim6 is not an LIS. But, the shim is between L3 and L4 while a > > session shim would be between L4 and APP. > > Usually that's handled in libraries used by apps. We don't use X.200 > layering much. > Yes, session should be part of implementation issues. Still, one would wish for a clearly declared session concept within the TCP/IP suite, so that it is not done ad hac from one application to another but is provided as a default interface visible to all APPs. -- DY --047d7bdc1be4e35abe04d00edd27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 5, 2012 at 3:26 AM, Scott Brim <swb@internet2.edu> wrote:
On 11/13/12 20:17, Dae Young KIM allegedly wrote:
> OK, Shim6 is not an LIS. But, the shim is between L3 and L4 while a > session shim would be between L4 and APP.

Usually that's handled in libraries used by apps. =C2=A0We don't us= e X.200
layering much.

Yes, session should be part of impl= ementation issues.

Still, one would wish for a clearly declared sess= ion concept within the TCP/IP suite, so that it is not done ad hac from one= application to another but is provided as a default interface visible to a= ll APPs.



--
DY
--047d7bdc1be4e35abe04d00edd27-- From huitema@huitema.net Wed Dec 5 00:27:38 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD1921F871A for ; Wed, 5 Dec 2012 00:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke73wck7Gijf for ; Wed, 5 Dec 2012 00:27:37 -0800 (PST) Received: from xsmtp05.mail2web.com (xsmtp25.mail2web.com [168.144.250.191]) by ietfa.amsl.com (Postfix) with ESMTP id AEFB621F842C for ; Wed, 5 Dec 2012 00:27:37 -0800 (PST) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1TgAKO-0000Vp-Ih for rrg@irtf.org; Wed, 05 Dec 2012 03:27:36 -0500 Received: (qmail 8609 invoked from network); 5 Dec 2012 08:27:34 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.18.205.153]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Dec 2012 08:27:33 -0000 From: "Christian Huitema" To: "'Tony Li'" , "'Scott Brim'" References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> In-Reply-To: Date: Wed, 5 Dec 2012 00:27:19 -0800 Message-ID: <0d9601cdd2c2$57d22290$077667b0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQKmaqimcuMIEaDS4+m+D6OTBfD6uwEJqFf5AlYTT+gB3vf1+gMMZiYcAUxrLhkCUOa8uAJhMVl6AefJTo0CHbp56AIiN/yelbUjrTA= Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 08:27:38 -0000 > Hi Scott, > > Doesn't that strike you as a layering violation? Shouldn't a stack shield > applications from having to create these mechanisms? Not really. Applications do have their own concept of identity, for very good reasons -- think of the difference between managing corporate data, your personal email, and an online game. They also have their own specific "time line" -- anywhere between instant to forever. It is quite hard to develop a "one size fits all" solution. Otherwise, "the market" probably would have created one. -- Christian Huitema From tony.li@tony.li Wed Dec 5 09:11:19 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29EE21F883B for ; Wed, 5 Dec 2012 09:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSCL0TmZN0X6 for ; Wed, 5 Dec 2012 09:11:19 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5E71021F8835 for ; Wed, 5 Dec 2012 09:11:19 -0800 (PST) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta15.emeryville.ca.mail.comcast.net with comcast id Xq661k00416AWCUAFtBKAG; Wed, 05 Dec 2012 17:11:19 +0000 Received: from dhcp-10-155-40-143.cisco.com ([128.107.239.234]) by omta06.emeryville.ca.mail.comcast.net with comcast id Xt941k008547xYo8St961P; Wed, 05 Dec 2012 17:09:17 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <0d9601cdd2c2$57d22290$077667b0$@huitema.net> Date: Wed, 5 Dec 2012 09:09:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> <0d9601cdd2c2$57d22290$077667b0$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354727479; bh=D8MKMjFRUTTalVqf2a7YkV90J9A25nshGKPwXpW3a6U=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=L4s8fIRwBZ5Boa+etKs/6Vw3qY848GyiKSBA+8JO6cqyZGMUX9Ex4b3bPavmPuV7E pexuxlcR6tWSbgFhorU3OnImlrc4y4o2y0ALqppoy3jMJNLlD0gUDQd3Qii6Mzw91j PmzoOIaoL71HTdOT1WwHlbRmd4rc6UXqQjU8b0nNi0qPnXBIk8qVphpu6BJGCyIqYp bHzm8A9/eg3VF9fgwHvi/2BQ6PXirGst73JjP3iRpxstdWVkNexmQ0tUtPhqSzGGhE y6VWvrpjAd9dahG8vdboK/F0towBQEb5yuFGv0zBVbb2j04hE35RZnQYjE9cxdQb8s q1iCD4FOJXEAA== Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:11:19 -0000 On Dec 5, 2012, at 12:27 AM, Christian Huitema = wrote: >> Hi Scott, >>=20 >> Doesn't that strike you as a layering violation? Shouldn't a stack = shield >> applications from having to create these mechanisms? >=20 > Not really. Applications do have their own concept of identity, for = very > good reasons -- think of the difference between managing corporate = data, > your personal email, and an online game. They also have their own = specific > "time line" -- anywhere between instant to forever. It is quite hard = to > develop a "one size fits all" solution. Otherwise, "the market" = probably > would have created one. Yes, entirely reasonable. When an application is going to be mobile = across stacks, then another mechanism is necessary. However, for the = mobility of the stack itself, that support should be intrinsic. Should apps have to know that the infrastructure has changed and that = the active interface now has a different L3 name? Tony From lear@cisco.com Wed Dec 5 09:32:36 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C0121F8C14 for ; Wed, 5 Dec 2012 09:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.445 X-Spam-Level: X-Spam-Status: No, score=-110.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES7e1z-0a8kG for ; Wed, 5 Dec 2012 09:32:36 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BC16421F8C04 for ; Wed, 5 Dec 2012 09:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=344; q=dns/txt; s=iport; t=1354728755; x=1355938355; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=p+diGuOl0zCOQTDeO5/dJtd+Pc7GVcVBiOUG7++rSas=; b=bVo27R86WQNgT/Y2m41MLpvKLupoqqA9fu7l8NZT8cWut0NeNiy+MABV GOKAv7jVApJxxfkwL1+MR/aOzjWtPFhahGtV1qoa2FizM+XLUdUVgqBPb CXAyrbWoGA4+/AMFB2W0IFfE0+MnEgIDW0v8J/YxquM7RYYHaMpaCzkZp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0PAEOEv1CQ/khL/2dsb2JhbABEg0eCbbZoBAOBARZzgh4BAQEEI1UBEAsYAgIFFgsCAgkDAgECAUUGDQEHAQGIDK9EkxGBIo5DgRMDlgOQR4Jz X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="10171345" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 05 Dec 2012 17:32:32 +0000 Received: from dhcp-10-61-105-116.cisco.com (dhcp-10-61-105-116.cisco.com [10.61.105.116]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB5HWWeC007624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2012 17:32:32 GMT Message-ID: <50BF8530.9010102@cisco.com> Date: Wed, 05 Dec 2012 18:32:32 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tony Li References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> <0d9601cdd2c2$57d22290$077667b0$@huitema.net> <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li> In-Reply-To: <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:32:36 -0000 Tony, On 12/5/12 6:09 PM, Tony Li wrote: > Should apps have to know that the infrastructure has changed and that the active interface now has a different L3 name? Applications may have cached state that needs to be invalidated (a good example is DNS caching), but I don't know that this in particular invalidates your point. Eliot From Fred.L.Templin@boeing.com Wed Dec 5 16:03:21 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3579521F87D1 for ; Wed, 5 Dec 2012 16:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYmd2nGNR0WD for ; Wed, 5 Dec 2012 16:03:20 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 5E40A21F8797 for ; Wed, 5 Dec 2012 16:03:20 -0800 (PST) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qB603JUI010643 for ; Wed, 5 Dec 2012 16:03:19 -0800 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qB603JHs010617 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 5 Dec 2012 16:03:19 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Wed, 5 Dec 2012 16:03:18 -0800 From: "Templin, Fred L" To: "rrg@irtf.org" Date: Wed, 5 Dec 2012 16:03:18 -0800 Thread-Topic: Where IRON fits in Thread-Index: Ac3TDo7189972t4cTtqBxbzYBdg/iQANSXgg Message-ID: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> <0d9601cdd2c2$57d22290$077667b0$@huitema.net> <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li> <50BF8530.9010102@cisco.com> In-Reply-To: <50BF8530.9010102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [rrg] Where IRON fits in X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:03:21 -0000 Good to see some activity on this list - I think? A couple of posts have mentioned IRON, and that work did indeed originate from this group. However, I have come to the realization that IRON is really an interior routing solution and not an Internetworking solution. In particular, IRON does not use tunneling between the routers of separate sites across the DFZ the way LISP does; it only uses tunneling *within* a site, even if that "site" is distributed across the global Internet. Where IRON adds value is that it manages mobility and multi-homing within the site without exposing de-aggregated prefixes to BGP. The IRON relays can therefore advertise only a few short prefixes into the BGP instead of lots of long prefixes. I therefore think IRON is complimentary to either of LISP or ILNP. It's just that IRON does well for "sites" that are geographically distributed and/or have lots of mobility internally. Thanks - Fred fred.l.templin@boeing.com=20 From heinerhummel@aol.com Thu Dec 6 03:33:49 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440F921F8727 for ; Thu, 6 Dec 2012 03:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN5LorX2-fwR for ; Thu, 6 Dec 2012 03:33:48 -0800 (PST) Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by ietfa.amsl.com (Postfix) with ESMTP id 4139621F86D8 for ; Thu, 6 Dec 2012 03:33:48 -0800 (PST) Received: from mtaomg-db04.r1000.mx.aol.com (mtaomg-db04.r1000.mx.aol.com [172.29.51.202]) by imr-da02.mx.aol.com (Outbound Mail Relay) with ESMTP id CB1991C00018F; Thu, 6 Dec 2012 06:33:47 -0500 (EST) Received: from core-dqd004c.r1000.mail.aol.com (core-dqd004.r1000.mail.aol.com [172.29.162.13]) by mtaomg-db04.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 731B7E000082; Thu, 6 Dec 2012 06:33:47 -0500 (EST) References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> <0d9601cdd2c2$57d22290$077667b0$@huitema.net> <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li> <50BF8530.9010102@cisco.com> To: Fred.L.Templin@boeing.com, rrg@irtf.org In-Reply-To: X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CFA1BCB0B0A975_CDC_3B28_Webmail-d106.sysops.aol.com" X-Mailer: AOL Webmail 37252-STANDARD Received: from 178.27.21.1 by Webmail-d106.sysops.aol.com (205.188.171.200) with HTTP (WebMailUI); Thu, 06 Dec 2012 06:33:47 -0500 Message-Id: <8CFA1BCB0A4C290-CDC-1278@Webmail-d106.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Thu, 6 Dec 2012 06:33:47 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1354793627; bh=9JmcYJ893/TQMCrv5YIqLZYKkGNtimx82yM3IUduKrA=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=vvtTnBhPTJv/raNtFsQKSe36KF3QXlrqTbkabReObqkzik7rI3K1sW4oAInldeBYC 0Fvct+SQPn0c9F+L2W/Y7iKe+cg2cldrzzT8TObegJ+75My4/6537UZLqvSJy4PvQK WXySlSiWQkQOcKmtwPqtlQ4Io15gfRit6GiSXcxQ= X-AOL-SCOLL-SCORE: 0:2:421337920:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33ca50c0829b3ebf Subject: Re: [rrg] Where IRON fits in X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 11:33:49 -0000 This is a multi-part message in MIME format. ----------MB_8CFA1BCB0B0A975_CDC_3B28_Webmail-d106.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Tunneling legacy routers a la LISP presumes global ipv4 address uniqueness,= i.e. won't work as soon as that presumption doesn't hold anymore. This is a major difference with TARA. Because TARA routers do not dissemina= te user reachability, each TARA router which replaces a legacy router would= free a bunch of ipv4 addresses from the necessity to be globally unique. LISP reminds me of MADCAP. As soon as MADCAP was accomplished it was OUT. A= nd the above is one of the reasons why I expect LISP to share with it the s= ame destiny. Heiner -----Original Message----- From: Templin, Fred L To: rrg Sent: Thu, Dec 6, 2012 1:03 am Subject: [rrg] Where IRON fits in Good to see some activity on this list - I think? A couple of posts have mentioned IRON, and that work did indeed originate from this group. However, I have come to the realization that IRON is really an interior routing solution and not an Internetworking solution. In particular, IRON does not use tunneling between the routers of separate sites across the DFZ the way LISP does; it only uses tunneling *within* a site, even if that "site" is distributed across the global Internet. Where IRON adds value is that it manages mobility and multi-homing within the site without exposing de-aggregated prefixes to BGP. The IRON relays can therefore advertise only a few short prefixes into the BGP instead of lots of long prefixes. I therefore think IRON is complimentary to either of LISP or ILNP. It's just that IRON does well for "sites" that are geographically distributed and/or have lots of mobility internally. Thanks - Fred fred.l.templin@boeing.com=20 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg =20 ----------MB_8CFA1BCB0B0A975_CDC_3B28_Webmail-d106.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Tunneling legacy routers a la LISP presumes global ipv4 ad= dress uniqueness, i.e. won't work as soon as that presumption doesn't hold = anymore.

This is a major difference= with TARA. Because TARA routers do not disseminate user reachability, each= TARA router which replaces a legacy router would free a bunch of ipv4 addr= esses from the necessity to be globally unique.

LISP reminds me of MADCAP.= As soon as MADCAP was accomplished it was OUT. And the above is one of the= reasons why I expect LISP to share with it the same destiny.

Heiner


Good to see some activity on this list -=
 I think?

A couple of posts have mentioned IRON, and that work did indeed
originate from this group. However, I have come to the realization
that IRON is really an interior routing solution and not an
Internetworking solution.

In particular, IRON does not use tunneling between the routers
of separate sites across the DFZ the way LISP does; it only uses
tunneling *within* a site, even if that "site" is distributed
across the global Internet.

Where IRON adds value is that it manages mobility and multi-homing
within the site without exposing de-aggregated prefixes to BGP.
The IRON relays can therefore advertise only a few short prefixes
into the BGP instead of lots of long prefixes.

I therefore think IRON is complimentary to either of LISP or ILNP.
It's just that IRON does well for "sites" that are geographically
distributed and/or have lots of mobility internally.

Thanks - Fred
fred.l.templin@boeing.com=
=20
_______________________________________________
rrg mailing list
rrg@irtf.org
http=
://www.irtf.org/mailman/listinfo/rrg
----------MB_8CFA1BCB0B0A975_CDC_3B28_Webmail-d106.sysops.aol.com-- From huitema@huitema.net Fri Dec 7 21:37:08 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CF421F8488 for ; Fri, 7 Dec 2012 21:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNwhMhpHpUMU for ; Fri, 7 Dec 2012 21:37:07 -0800 (PST) Received: from xsmtp12.mail2web.com (xsmtp32.mail2web.com [168.144.250.235]) by ietfa.amsl.com (Postfix) with ESMTP id A3C0E21F8484 for ; Fri, 7 Dec 2012 21:37:07 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ThD5y-0002NA-B5 for rrg@irtf.org; Sat, 08 Dec 2012 00:37:06 -0500 Received: (qmail 8761 invoked from network); 8 Dec 2012 05:36:59 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.18.205.153]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Dec 2012 05:36:59 -0000 From: "Christian Huitema" To: "'Eliot Lear'" , "'Tony Li'" References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> <0d9601cdd2c2$57d22290$077667b0$@huitema.net> <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li> <50BF8530.9010102@cisco.com> In-Reply-To: <50BF8530.9010102@cisco.com> Date: Fri, 7 Dec 2012 21:36:43 -0800 Message-ID: <103c01cdd506$02140940$063c1bc0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQKmaqimcuMIEaDS4+m+D6OTBfD6uwEJqFf5AlYTT+gB3vf1+gMMZiYcAUxrLhkCUOa8uAJhMVl6AefJTo0CHbp56AIiN/yeANbgo0UBiSwQ5wIGazFUlZZ3ggA= Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 05:37:08 -0000 > On 12/5/12 6:09 PM, Tony Li wrote: > > Should apps have to know that the infrastructure has changed and = that the > active interface now has a different L3 name? Generally, no, albeit I am pretty sure that the apps that depend on = NAT/firewall traversal do keep extensive data about the state of the = network. But most other apps are content to treat rare and weird network events = as failures, and simply run through whatever reconnection process they = have for the general failure case. From swb@internet2.edu Mon Dec 10 05:01:38 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9121F8E6C for ; Mon, 10 Dec 2012 05:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63vhDWwrtvl7 for ; Mon, 10 Dec 2012 05:01:38 -0800 (PST) Received: from int-proxy02.merit.edu (int-proxy02.merit.edu [207.75.116.231]) by ietfa.amsl.com (Postfix) with ESMTP id 12EB421F8E6E for ; Mon, 10 Dec 2012 05:01:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy02.merit.edu (Postfix) with ESMTP id 1AC1326803A; Mon, 10 Dec 2012 08:01:35 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy02.merit.edu Received: from int-proxy02.merit.edu ([127.0.0.1]) by localhost (int-proxy02.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZuOv3TL9u71; Mon, 10 Dec 2012 08:01:34 -0500 (EST) Received: from swbi2mbp.local (cpe-67-241-75-185.twcny.res.rr.com [67.241.75.185]) by int-proxy02.merit.edu (Postfix) with ESMTPSA id 791F8268038; Mon, 10 Dec 2012 08:01:34 -0500 (EST) Message-ID: <50C5DD2F.2080004@internet2.edu> Date: Mon, 10 Dec 2012 08:01:35 -0500 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tony Li References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 13:01:38 -0000 On 12/04/12 14:16, Tony Li allegedly wrote: > > On Dec 4, 2012, at 10:20 AM, Scott Brim wrote: > >> I don't know who "they" is but applications that want to be robust >> across network changes have their own identity-related functions. They >> have done their own loc/id split, for the identities that matter to them >> (app/session level), and use it to sustain sessions. They don't care >> about or need what this list is talking about. > > Hi Scott, > > Doesn't that strike you as a layering violation? Shouldn't a stack shield applications from having to create these mechanisms? > > Regards, > Tony (sorry for the delay) First of all I'm talking about general Internet use, not special cases like data centers. In those cases it makes plenty of sense to treat all higher layer functions in a block and use lower layer identification mechanisms. Identification is not limited to a particular layer or activity -- identities are used at multiple layers and in higher layers there can be multiple independent identities (and identification functions). There is variation in what is being identified, how authentication and authorization are done, what happens during events, lifetime, etc. There was a time when everything used lower layer tuples for identification and that _was_ a layer violation. Now they have figured out that they have to have their own mechanisms in order to be free of location. Could they all use the same mechanisms provided by lower layers? The variation in requirements says no. Higher layer functions often need independence in how they behave - the end-to-end argument applies up the stack, not just in the network infrastructure. Not only is there variation in how identity is used already, we want to ensure that freedom for flexibility and robustness (just as we do elsewhere in the architecture). In particular, nowadays some "sessions" can leap between lower layer entities, independently of each other, while some remain and all maintain identities. Higher layer functions related to identity simply cannot depend on lower layers to provide it - they are now decoupled. Scott From swb@internet2.edu Mon Dec 10 05:10:44 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F82621F8E80 for ; Mon, 10 Dec 2012 05:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmkKrn7gZQf7 for ; Mon, 10 Dec 2012 05:10:44 -0800 (PST) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by ietfa.amsl.com (Postfix) with ESMTP id E807C21F8E7E for ; Mon, 10 Dec 2012 05:10:43 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id EE520100071; Mon, 10 Dec 2012 08:10:42 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZjgldGaqTgR; Mon, 10 Dec 2012 08:10:42 -0500 (EST) Received: from swbi2mbp.local (cpe-67-241-75-185.twcny.res.rr.com [67.241.75.185]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id 632D5100012; Mon, 10 Dec 2012 08:10:42 -0500 (EST) Message-ID: <50C5DF53.2020404@internet2.edu> Date: Mon, 10 Dec 2012 08:10:43 -0500 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tony Li References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> <50BE3EEB.20700@internet2.edu> <0d9601cdd2c2$57d22290$077667b0$@huitema.net> <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li> In-Reply-To: <2C77A48B-9A7D-4E02-B4F3-987E0AFC83F8@tony.li> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 13:10:44 -0000 On 12/05/12 12:09, Tony Li allegedly wrote: > Yes, entirely reasonable. When an application is going to be mobile > across stacks, then another mechanism is necessary. However, for the > mobility of the stack itself, that support should be intrinsic. Sure. The network layer entity can have its own identification functions for its own purposes, and higher layer entities can and _will_ have their own. > Should apps have to know that the infrastructure has changed and that > the active interface now has a different L3 name? They shouldn't have to but after years of having nothing to depend on in L3, they are not going to trust the lower layers to take care of it for them.