Re: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter

Ole Trøan <otroan@employees.org> Wed, 15 February 2012 20:03 UTC

Return-Path: <ichiroumakino@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36B021E80A0 for <softwires@ietfa.amsl.com>; Wed, 15 Feb 2012 12:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXdKLHMzLSzJ for <softwires@ietfa.amsl.com>; Wed, 15 Feb 2012 12:03:39 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC92E21E8027 for <softwires@ietf.org>; Wed, 15 Feb 2012 12:03:38 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so968110wib.31 for <softwires@ietf.org>; Wed, 15 Feb 2012 12:03:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=70+6QG6RT/o7OI41pqAJH20GDQ+kgWgNWqNpQdO5l0E=; b=hF7AbEgzyVYMzDt2LX3Xb/XaBxfKrFmGUtbdPA37lHg5b9MTZrh/20h+lPNJOilTfV HOUGqjRxNCx5UOQH17zMu27vCshE3AvFGjRXJ2kEnoJAx80cugiqFIzqGW2zzB+ny89i ccviAuSPgax6mXLMQLvnfWuwcxDKMSslnJnG8=
Received: by 10.180.86.134 with SMTP id p6mr37371990wiz.0.1329336217808; Wed, 15 Feb 2012 12:03:37 -0800 (PST)
Received: from dhcp-10-61-97-249.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id y1sm15139527wiw.6.2012.02.15.12.03.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 12:03:36 -0800 (PST)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="iso-8859-1"
From: Ole Trøan <otroan@employees.org>
In-Reply-To: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>
Date: Wed, 15 Feb 2012 21:03:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E19E9813-9BC7-400E-8CCB-9AD7DD1539D2@employees.org>
References: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>
To: Rémi Després <despres.remi@laposte.net>
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 15 Feb 2012 20:03:40 -0000

Remi,

> Your comments about the following feature-comparison item have been:
> - "possible with MAP-{E,T} too, but may require coordination of subnet numbering."
> - "I don't see the point of having text in the specification for this use case. it is a deployment option."
> 
> +----+--------------------------------------+-----+-----+-----+-----+
> |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
> |    |                                      |  -T |  -E |  -H |  -E |
> +----+--------------------------------------+-----+-----+-----+-----+
> ...
> |    |                                      |     |     |     |     |
> |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
> |    | third-party CPEs                     |     |     |     |     |
> 
> But, AFAIK, it is not possible to configure a MAP domain for CEs attached to third-party CPEs (ref. use case 5.2.2 of the 4rd-U draft).
> 
> 2.
> To deal with some similar use cases, we had an optional Suffix parameter of Mapping rules in draft draft-despres-intarea-4rd-01 (of which co-authors were R. Després, S. Matsushima, T. Murakami, ... and yourself).
> 
> Having not seen in the WG that the need had disappeared, nor that another way to satisfy the need had been discussed, I did include the Suffix parameter in 4rd-U.
> 
> 3.
> A somewhat detailed explanation about this need, received in the past and IMHO clarifying, was something like this:
> 
> "For the instance, in Japan, NTT provides the access line to the end-users and ISPs provides the internet service over this access line. Sometimes, NTT CPE is located in front of the ISP's 4rd CE. Sometimes, only the ISP's 4rd CE is located at home as shown below.
> 
> --<ipv6>-- NTT CPE ---- ISP CE ----
> 
> --<ipv6>-- ISP CE --

I would not expect those two cases would be in the same MAP domain. even though they could.

> It depends on the end-users' contract. If the end-user is getting some services from NTT, the NTT CPE is located at home and the ISP CE is located behind the NTT CE. If the end-user is not getting such a service, only ISP CE is located at home.

not quite. see Satoru-san's presentation from the Paris last week for details.

> In both cases, the IPv6 network infrastructure assigns an IPv6 prefix to the customer site. If present, the NTT CPE receives an IPv6 prefix and then delegates a longer IPv6 prefix to the ISP CE. For example, a /48 IPv6 prefix is assigned to the NTT CPE, and the NTT CPE delegates a /52 after adding a 4bit suffix to the ISP CE. But in other cases, if the ISP CE is directly connected to the IPv6 network infrastructure, the ISP CE can get an IPv6 prefix without any suffix.
> 
> So, in one 4rd domain, some ISP CEs get shorter IPv6 prefixes directly from the IPv6 network (say /48) and some other ISP CEs get longer IPv6 prefixes from NTT CPEs (say /52). This means that the delegated IPv6 prefix consists of the Domain IPv6 prefix followed by EA bits, if the ISP CE is directly connected to the IPv6 network, and that the delegated prefix consists of the Domain IPv6 prefix, followed by EA bits, and followed by the added suffix if the ISP CE is connected to another CE."

the End-user IPv6 prefix must be of the same length for all CEs using the same mapping rule.

> 4.
> Without a suffix parameter in mapping rules that applies to CEs behind a third-party CPEs, CPE added suffixes would be included in EA bits. They would therefore be present as lower parts of PSIDs of CE that have shared IPv4 addresses. 
> I don't see how this could work. 

incorrect, MAP includes an EA-bits length parameter. the EA-bits are included in the topmost End-user IPv6 prefix (in your example above).

> 5.
> Of course, the suffix parameter can be added to MAP if decided (no problem with that), but the feature comparison table remains based on existing drafts.

not, needed. the MAP subnet-id is defined to be 0.

> Hoping this clarifies this issue, I welcome questions and comments from anyone in the WG, in particular from the MAP design team.

MAP supports "3rd party CPEs". (assuming all the other problems associated with provisioning are resolved.)
it also solves the case of directly connected and 3rd party CPEs within the same MAP domain. albeit I've never ever heard that as a real use case.

cheers,
Ole