Re: [Softwires] MAP draft 11 question on fragment ID space reduction

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Tue, 14 October 2014 14:51 UTC

Return-Path: <rajiva@cisco.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACA61A87B1 for <softwires@ietfa.amsl.com>; Tue, 14 Oct 2014 07:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level:
X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myjQukdrObkN for <softwires@ietfa.amsl.com>; Tue, 14 Oct 2014 07:51:04 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C621A877F for <softwires@ietf.org>; Tue, 14 Oct 2014 07:51:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2373; q=dns/txt; s=iport; t=1413298264; x=1414507864; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0sq1DlUsBet2vtK8iflRdDI0oB2KTuxe2gGuFZHWamE=; b=M8AxEO1JZqr4ixgFfiLqIa7P9YWfFQ8pipeXADPlDJjK/CYMcqE2hUte w/+DU3SKFKCdwUnptN8dV733BM0lbRQo0m4GiRlIvaQyVBOyZdD45Kw5n Kbroob7gTFeBTEGv/jX4++TEQ90QdGlze5DMISth+kzZuvFXjKbPVgqvn w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAK03PVStJV2Q/2dsb2JhbABbgw5TWATMKgqGeVQCgRQWAX2EAgEBAQQBAQFrCwwEAgEIEQMBAgEuJwsdCAIEAQ0FiD4Nxk4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXkBorBwaERQWLIIZZhEKHEIFqlCeDd2yBSIECAQEB
X-IronPort-AV: E=Sophos;i="5.04,717,1406592000"; d="scan'208";a="363338160"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 14 Oct 2014 14:51:03 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9EEp3xt012142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 14:51:03 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.218]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 09:51:02 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Ole Troan <otroan@employees.org>
Thread-Topic: [Softwires] MAP draft 11 question on fragment ID space reduction
Thread-Index: AQHP55XYMDkTrQLO4kS2LpDbhAWxWJwv60aA///TAQA=
Date: Tue, 14 Oct 2014 14:51:02 +0000
Message-ID: <D0629F4B.20A7A8%rajiva@cisco.com>
References: <CAPi140MdbJQBLSRS+g4Jx0G1zm1dx6PLBBQ7oPeALU2z-Vp81g@mail.gmail.com> <A9F4CC49-3409-482E-8DD1-D60770719370@employees.org> <365F683D-89D6-4A42-B9F1-780453D9C1A5@nominum.com>
In-Reply-To: <365F683D-89D6-4A42-B9F1-780453D9C1A5@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.82.226.158]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <AA154AC14FE8C246A503A4E05EA53094@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/nE4J8nu_HpA6JFs3jSa_2hD7bGU
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] MAP draft 11 question on fragment ID space reduction
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Oct 2014 14:51:07 -0000

It might be worth understanding why this problem is even worth
addressing/mentioning.

Is the possibility of 2 or more host devices (behind 2 or more MAP CE
routers) sharing the same IPv4 address would be "generating the fragmented
packets" towards the same destination around the same time, not close to
zero due to PMTUD etc.?

AFAIK, RFC6888 doesn¹t mention such a problem or requirement for CGN?


IMO, there shouldn¹t be any normative recommendation, if this problem is
mentioned.

-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco





-----Original Message-----
From: Ted Lemon <Ted.Lemon@nominum.com>
Date: Tuesday, October 14, 2014 at 9:32 AM
To: Ole Troan <otroan@employees.org>
Cc: Softwires-wg list <softwires@ietf.org>
Subject: Re: [Softwires] MAP draft 11 question on fragment ID space
reduction

>On Oct 14, 2014, at 5:01 AM, Ole Troan <otroan@employees.org> wrote:
>> splitting the fragment id space so that there is only a single bit per
>>CPE sounds like a corner case that should be disallowed. I don't know if
>>we have the knowledge to be able to specify exactly how much of the
>>fragment id space is safe to split up though.is it 4, 6, or 8 bits?
>
>There's a lot to think about here.  The fragment ID translation algorithm
>probably needs to maintain a cache so that it doesn't accidentally
>overload fragment IDs.   The set of all outstanding fragments has the
>potential to be larger than the set of all ports in use, so there is
>definitely reason to be concerned about shrinking the fragment ID space.
> However, shrinking the fragment ID space _does_ serve the useful purpose
>of isolating fragment ID collisions to the nodes that are supposed to be
>receiving the fragments.
>
>It may be that the right thing to do is to note that this is a problem,
>make a recommendation, but essentially leave it as future research, since
>we really haven't analyzed the problem in enough depth to make an
>informed recommendation.
>
>> if changing back to SHOULD from the MUST would lead people to accept
>>that we leave the exact recommendations for further study I would be
>>happy to do that.
>
>So yes, this might be a good way to go.
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires