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

Rémi Després <despres.remi@laposte.net> Wed, 15 February 2012 17:12 UTC

Return-Path: <despres.remi@laposte.net>
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 AA0D321F86F6 for <softwires@ietfa.amsl.com>; Wed, 15 Feb 2012 09:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.841
X-Spam-Level:
X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 QqZ370fdgG0n for <softwires@ietfa.amsl.com>; Wed, 15 Feb 2012 09:12:59 -0800 (PST)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id A281221F8468 for <softwires@ietf.org>; Wed, 15 Feb 2012 09:12:58 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 4EA897000094; Wed, 15 Feb 2012 18:12:57 +0100 (CET)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id D96B47000083; Wed, 15 Feb 2012 18:12:56 +0100 (CET)
X-SFR-UUID: 20120215171256890.D96B47000083@msfrf2319.sfr.fr
From: Rémi Després <despres.remi@laposte.net>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Feb 2012 18:12:55 +0100
Message-Id: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>
To: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
Cc: Softwires WG <softwires@ietf.org>
Subject: [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 17:12:59 -0000

Hi Ole,

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

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.

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


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. 

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.


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