Re: [ncrg] Relevance for IPv4 address sharing mechanisms

Johna@nemertes.com Tue, 06 November 2012 23:24 UTC

Return-Path: <Johna@nemertes.com>
X-Original-To: ncrg@ietfa.amsl.com
Delivered-To: ncrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7D421F8BB2; Tue, 6 Nov 2012 15:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level:
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 a4YEVArpbWBe; Tue, 6 Nov 2012 15:24:28 -0800 (PST)
Received: from domino-89a.nemertes.com (unknown [208.85.188.89]) by ietfa.amsl.com (Postfix) with ESMTP id C8FB421F8BBE; Tue, 6 Nov 2012 15:24:28 -0800 (PST)
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F58F810@xmb-rcd-x14.cisco.com>
References: <5097E725.808@skoberne.net> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F58F810@xmb-rcd-x14.cisco.com>
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>
MIME-Version: 1.0
X-KeepSent: 6E25DC05:7E054FAA-85257AAE:00807C21; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
From: Johna@nemertes.com
Message-ID: <OF6E25DC05.7E054FAA-ON85257AAE.00807C21-85257AAE.008094B7@Nemertes.com>
Date: Tue, 6 Nov 2012 18:24:26 -0500
X-MIMETrack: Serialize by Router on domino-89a.nemertes.com/Nemertes(Release 8.5.3FP2|July 02, 2012) at 11/06/2012 05:24:28 PM, Serialize complete at 11/06/2012 05:24:28 PM
Content-Type: multipart/alternative; boundary="=_alternative 0080838B85257AAE_="
X-Mailman-Approved-At: Tue, 06 Nov 2012 15:32:35 -0800
Cc: "ncrg@irtf.org" <ncrg@irtf.org>, ncrg-bounces@irtf.org, =?UTF-8?B?TmVqYyDFoGtvYmVybmU=?= <nejc@skoberne.net>
Subject: Re: [ncrg] Relevance for IPv4 address sharing mechanisms
X-BeenThere: ncrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Complexity Research Group <ncrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/ncrg>, <mailto:ncrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/ncrg>
List-Post: <mailto:ncrg@irtf.org>
List-Help: <mailto:ncrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/ncrg>, <mailto:ncrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2012 23:31:03 -0000

Maximum number of steps to process under worst-case scenario? 
---------------------------------------------------------------------------
Johna Till Johnson
President & Sr. Founding Partner
Nemertes Research
917-991-1468
johna@nemertes.com
www.nemertes.com
http://www.twitter.com/nemertes
http://www.twitter.com/johnatilljohnso

---------------------------------------------------------------------------
"Everything is interesting if you go into it deeply enough."--Richard 
Feynman



From:   "Michael Behringer (mbehring)" <mbehring@cisco.com>
To:     Nejc ?koberne <nejc@skoberne.net>et>, "ncrg@irtf.org" 
<ncrg@irtf.org>rg>, 
Date:   11/06/2012 04:55 PM
Subject:        Re: [ncrg] Relevance for IPv4 address sharing mechanisms
Sent by:        ncrg-bounces@irtf.org



> -----Original Message-----
> From: ncrg-bounces@irtf.org [mailto:ncrg-bounces@irtf.org] On Behalf Of
> Nejc ?koberne
> Sent: 05 November 2012 11:20
> To: ncrg@irtf.org
> Subject: [ncrg] Relevance for IPv4 address sharing mechanisms
> 
> Hi,
> 
> I work on research on IPv4 address sharing mechanisms, which are in 
other
> WGs, so my question is: will this framework also be useful for 
evaluating
> complexity of these mechanisms? I.e. Stateful NAT64 (RFC 6146), DS-Lite
> (RFC 6333), current MAP and 4rd Internet Drafts and so on. Maybe it's a
> stupid question, but at the meeting today, routing protocols were mostly
> discussed.

Nejc, 

The NCRG should *specifically* contribute to IETF activities, and try to 
analyse the complexity in protocols. It seems to me that protocol 
complexity is significantly simpler to figure out than the complexity of a 
real network, with all its dependencies on hardware, human operators, etc. 
I'm thinking here of the complexity of the specs only, ignoring the 
implementation at this point. 

So please share your thoughts here on how we could analyse the complexity 
of those protocols!

Michael
 
> Thanks,
> Nejc
> _______________________________________________
> ncrg mailing list
> ncrg@irtf.org
> https://www.irtf.org/mailman/listinfo/ncrg
_______________________________________________
ncrg mailing list
ncrg@irtf.org
https://www.irtf.org/mailman/listinfo/ncrg