[mif] Motivations for draft-ietf-mif-dhcpv6-route-option

Maglione Roberta <roberta.maglione@telecomitalia.it> Wed, 16 November 2011 01:02 UTC

Return-Path: <roberta.maglione@telecomitalia.it>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB7E11E80E4 for <mif@ietfa.amsl.com>; Tue, 15 Nov 2011 17:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.536
X-Spam-Level:
X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6]
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 5RhicCqsRcHD for <mif@ietfa.amsl.com>; Tue, 15 Nov 2011 17:02:19 -0800 (PST)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF1D11E80B2 for <mif@ietf.org>; Tue, 15 Nov 2011 17:02:19 -0800 (PST)
Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Nov 2011 02:02:14 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 16 Nov 2011 02:02:14 +0100
From: Maglione Roberta <roberta.maglione@telecomitalia.it>
To: mif <mif@ietf.org>
Date: Wed, 16 Nov 2011 01:59:42 +0100
Thread-Topic: Motivations for draft-ietf-mif-dhcpv6-route-option
Thread-Index: AQHMo/tgviDlqlbdN0SXs3FChFIsqw==
Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local>
Accept-Language: en-US, it-IT
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, it-IT
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2011 01:02:20 -0000

Hello,
    during the meeting the chairs and many people asked about use cases and motivations for this work:
as I quickly mentioned at the mic there is a draft in v6ops (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat) that clearly explains the use cases and the requirements, coming from a Service Provider, for  this work.
In Broadband network environment where the CPE is multi-homed to two upstream edge routers and each router provides connectivity for different types of services for example internet access and Video on Demand (restricted inside a walled garden,) and the Service Provide would like to avoid routing on the CPE, there is a need to provision static route entries on RGs/CPEs.

 As a Service Provider we believe DHCPv6 is the right tool to that because we need a centralized control/management point for storing the customer’s related info  (ipv6 prefix, ipv6 routes, …) and DHCPv6 is a good place for that. Using RA’s would require to manually provision the edge router and this operation is not always possible, for example when router is operated by 3rd party.

Regarding the issues raised about the potential need for VRRP on the CPE to protect against failure, in my opinion in the scenario described above VRRP is not needed because if the connection to the edge router providing internet service is down I don’t want the user traffic using the other link because the other edge router only provides limited connectivity  to a restricted walled garden. As far as DHCPv6 failure, as many of you know there is ongoing work on dhc WG in order to provide DHCPv6 redundancy.

I really would like to see this work progressing because it is needed as many Service Providers said not only draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat, but also in Broadband Forum documents, if you take a look at WT-124i3 you can find requirements calling exactly for this draft to solve the problem described above, this means a community of Service Providers’ recognized the need for this work.

Thanks
Regards,
Roberta

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.