IETF Logo Mail Archive

Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

jouni korhonen <jouni.nospam@gmail.com> Fri, 21 September 2012 10:27 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103F21F8688 for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 03:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level:
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
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 4ri1yorsKhHU for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 03:27:59 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A302421F8687 for <v6ops@ietf.org>; Fri, 21 Sep 2012 03:27:57 -0700 (PDT)
Received: by bkty12 with SMTP id y12so1600376bkt.31 for <v6ops@ietf.org>; Fri, 21 Sep 2012 03:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tnF10FcyKXA99VfflQqZ1sOIn7xTyDDvLAxSU/03VAs=; b=ggvkHV3SjJ6kxRcyTbeeWgd2FjshPjx83UxSqgkldKsUrnV+z5mY4h0xzm5BT87xCh eDEN19sADA/QviJsY7KneuFKc21OLbZsC1MMenJyvGSMrE1wICeNgo8fk7+HZq2HufUl zUXUnFSmemMWyiPpXyihg7zUDFr4FX++EMwmp7zNTskre8zWC24u2dKiiRPHir+yk1tI KERFhczzoAZ3h+i0Y4Br0VzG4Koc5H38+K9HisKyuTKABfiaR2+ThPkfHeRTyS5xjiDj sByl6tgvSEKW8dSR84IXxDBdSZm53Ursij0m1jv/FuIT6VkbR6ZwuWBTx/Jf3nPZ/eU4 ozuA==
Received: by 10.205.120.16 with SMTP id fw16mr1878760bkc.102.1348223276707; Fri, 21 Sep 2012 03:27:56 -0700 (PDT)
Received: from ?IPv6:2001:6e8:2100:100:223:32ff:fec9:7938? ([2001:6e8:2100:100:223:32ff:fec9:7938]) by mx.google.com with ESMTPS id t23sm5941730bks.4.2012.09.21.03.27.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 03:27:53 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B123404@PUEXCB1B.nanterre.francetelecom.fr>
Date: Fri, 21 Sep 2012 13:27:49 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <765A5155-1D90-4F1F-B5CD-E2E3CD18633B@gmail.com>
References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr1xnF_mQwy-6OAyXRxkcpoNB099tVC+J89ni6wVA+bmSw@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> <CAKD1Yr0AduMnirD60gB3PYnqWkOu122S1A=hxjyt2FjxqurdnQ@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36E5B123404@PUEXCB1B.nanterre.francetelecom.fr>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2012 10:27:59 -0000

Med,

On Sep 21, 2012, at 11:04 AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:

> 
> I don't understand. An interface is connected to only network, and the cellular link is point-to-point. By definition, there can only be one entity on the other side. Where's the conflict?
> [Med] Consider the case the MIFed device is connected to both a 3G network and WiFI hotspot simultaneously: if the hotspot and the 3G are managed by the same provider, then policies to offload (some of traffic) can be enforced using specific routes. But if these networks are not managed by same entities and each of them are sending specific routes, wouldn't be there potential conflict    in the policies? What would be the behaviour of the device? 

RFC4191 also brings in router preferences. You do not need to bother too much
with specific routes. Simple example to make cellular preference low and others
stay on default. More specific routes can be installed on those destinations 
you definitely want to flow through your cellular infra. We got some good results
with that, specifically when you configure your mobile to allow RC4191 extensions
only from your cellular interface (trivial e.g. on any Linux based device). So the
mobile operator still has the control. That has been dealt several times in Mif.

- Jouni




>  
>  2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think it's appropriate to say that an experimental RFC is a requirement. Additionally, ND proxy is not fully baked, and it has issues with certain topologies. We need a better solution than that.
> [Med] RFC4389 is the best reference we can quote at this stage. Do you have a pointer to an I-D where these issues are discussed? We can add a pointer to that I-D.
> There is no working solution at this time. This can be made to work when tethering over the cellular link, but the ND proxy RFC is not the way to do it. I think we need a new document to specify this.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email