Re: [ncrg] Relevance for IPv4 address sharing mechanisms

Rana Sircar <sircar.rana@gmail.com> Thu, 08 November 2012 16:56 UTC

Return-Path: <sircar.rana@gmail.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 1387721F84E9 for <ncrg@ietfa.amsl.com>; Thu, 8 Nov 2012 08:56:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.765
X-Spam-Level:
X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, 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 EoMhYIu6rMtJ for <ncrg@ietfa.amsl.com>; Thu, 8 Nov 2012 08:56:19 -0800 (PST)
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0A721F84DC for <ncrg@irtf.org>; Thu, 8 Nov 2012 08:56:19 -0800 (PST)
Received: by mail-pb0-f54.google.com with SMTP id wz17so555241pbc.13 for <ncrg@irtf.org>; Thu, 08 Nov 2012 08:56:18 -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:content-type; bh=0Il2BmN4fqDyxPFyZlTYVtS+4O9BaABw65ztbze9364=; b=Qh44EmkPQasO/g4OTvHxfzDlC/yDT8uA/0w6nhdLF+mvD2eKsyNf8Qt3MKOhGZ4fFO w8Vv/RTCeTirMbIaKZAnf1xBkRJrrfrLAa2BIoZQ/9rm40pJeE5x/O/lwiUXc7PZi63a Dp0Q/bmqvwbunCDcAVg4ITIqVB6x/G03POi1En4FDvj4llvbL77JfwyXQuWuK5p83h+z YzzIJ1M/3EhiLkCUInZwxIfESq9HJxSb4yn/SbF5T66ZZvDh1g6xtb8fO3qbTZGB1ps0 lolqKgUHZX6/l4rCeDDwAl59ywC5UBDhsnbI6iQHbr6lnroKJ2H5ExiKsisD2IkEK+Yu ZsHA==
Received: by 10.66.85.69 with SMTP id f5mr23887366paz.50.1352393778809; Thu, 08 Nov 2012 08:56:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.218.68 with HTTP; Thu, 8 Nov 2012 08:55:58 -0800 (PST)
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F58F810@xmb-rcd-x14.cisco.com>
References: <5097E725.808@skoberne.net> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F58F810@xmb-rcd-x14.cisco.com>
From: Rana Sircar <sircar.rana@gmail.com>
Date: Thu, 8 Nov 2012 22:25:58 +0530
Message-ID: <CAPjPJcmqFGj+MTLB_h8EU925DYi=5_8+u3s4wmz5YcFuyV+_Xg@mail.gmail.com>
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>
Content-Type: multipart/alternative; boundary=f46d042ef563c84a9b04cdfeb61f
Cc: "ncrg@irtf.org" <ncrg@irtf.org>, =?ISO-8859-2?Q?Nejc_=A9koberne?= <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: Thu, 08 Nov 2012 16:56:20 -0000

Hi Michael,

I was trying to understand this aspect - on one hand we have protocol
complexity and on other Network complexity. Unfortunately sum of Protocol
complexity does not translate to a total Network complexity. On other hand,
in many cases, Protocol complexity comes fairly close to Algorithmic
complexity (in theory).

As I understand, IETF covers both Transport & signaling protocols
(including service layer & management ones). This itself gives 2 dimensions
to the network under considerations (assuming that the goal is still
"Network" and not limited to "Protocol").

As we know, the mission of the IETF is to make the Internet work better by
producing high quality, relevant technical documents that influence the way
people design, use, and manage the Internet (from Engineering standpoint).
This would remove Operations from the view. But it does bring Network
engineering requirements, Architecture, Design & implementation in its
purview.

With Mobile Broadband, enterprise, Military/Government networks & personal
networks in picture (apart from fixed line access, Metro & core), we  do
have a complex job in hand.  The final answer may not be a "value" or
"Measure" but may be a "Class of Complexity" instead.

Best Regards,
Rana
GSM+919899003705|


On 7 November 2012 03:24, Michael Behringer (mbehring)
<mbehring@cisco.com>wrote;wrote:

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