Re: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

"Laganier, Julien" <julienl@qualcomm.com> Mon, 13 September 2010 17:49 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: mipshop@core3.amsl.com
Delivered-To: mipshop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDAF3A69F9 for <mipshop@core3.amsl.com>; Mon, 13 Sep 2010 10:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.558
X-Spam-Level:
X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPPiHP-qP3sG for <mipshop@core3.amsl.com>; Mon, 13 Sep 2010 10:49:49 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 27F2C3A69F5 for <mipshop@ietf.org>; Mon, 13 Sep 2010 10:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1284400215; x=1315936215; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Marco=20Liebsch=20<marco.liebsch@neclab.eu>|CC:=20 Vijay=20Devarapalli=20<dvijay@gmail.com>,=20"mipshop@ietf .org"=0D=0A=09<mipshop@ietf.org>,=20"BLUME,=20Oliver"=20< Oliver.Blume@alcatel-lucent.de>|Date:=20Mon,=2013=20Sep =202010=2010:50:13=20-0700|Subject:=20RE:=20[Mipshop]=20S ection=204.3.1=20of=0D=0A=09draft-ietf-mipshop-transient- bce-pmipv6|Thread-Topic:=20[Mipshop]=20Section=204.3.1=20 of=0D=0A=09draft-ietf-mipshop-transient-bce-pmipv6 |Thread-Index:=20ActTaWziasejZ/bYT5u94fT73gDqEgAAY+Yw |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F6826E40 0@NALASEXMB04.na.qualcomm.com>|References:=20<4C8927B2.10 30000@gmail.com>=20<4C89EE49.4050004@neclab.eu>=0D=0A=09< 4C8A0FA7.7060308@piuha.net>=20<4C8AAC0C.5020204@gmail.com >=0D=0A=20<4C8E2B36.7050308@neclab.eu>=0D=0A=20<BF345F630 74F8040B58C00A186FCA57F1F6826E3E6@NALASEXMB04.na.qualcomm .com>=0D=0A=20<4C8E5BC8.6060601@neclab.eu>=0D=0A=20<BF345 F63074F8040B58C00A186FCA57F1F6826E3ED@NALASEXMB04.na.qual comm.com>=0D=0A=20<4C8E5F77.4000903@neclab.eu> |In-Reply-To:=20<4C8E5F77.4000903@neclab.eu> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ryI+MgWR0HC9KAECxDo/eMfmErgSXgKq0PUuuDJqql4=; b=eAxnCiZhOje6Omo2qQ0qEJvB31u8nzarebzT2I3v1pBq55fCKEj6oNUa wSz1b1YWVinKt/XeI/i2SQjamKm1fUix6D1v1DKEWb+x9GggHSNu5ABI/ fpNYawfSgxfGouod76UvjcNp6oCYigo8o2N03U/b31OLvmEVrRtbxZd2k s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6105"; a="54187782"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 13 Sep 2010 10:50:15 -0700
X-IronPort-AV: E=Sophos;i="4.56,359,1280732400"; d="scan'208";a="7931320"
Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 13 Sep 2010 10:50:15 -0700
Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 13 Sep 2010 10:50:15 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Mon, 13 Sep 2010 10:50:14 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Marco Liebsch <marco.liebsch@neclab.eu>
Date: Mon, 13 Sep 2010 10:50:13 -0700
Thread-Topic: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6
Thread-Index: ActTaWziasejZ/bYT5u94fT73gDqEgAAY+Yw
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F6826E400@NALASEXMB04.na.qualcomm.com>
References: <4C8927B2.1030000@gmail.com> <4C89EE49.4050004@neclab.eu> <4C8A0FA7.7060308@piuha.net> <4C8AAC0C.5020204@gmail.com> <4C8E2B36.7050308@neclab.eu> <BF345F63074F8040B58C00A186FCA57F1F6826E3E6@NALASEXMB04.na.qualcomm.com> <4C8E5BC8.6060601@neclab.eu> <BF345F63074F8040B58C00A186FCA57F1F6826E3ED@NALASEXMB04.na.qualcomm.com> <4C8E5F77.4000903@neclab.eu>
In-Reply-To: <4C8E5F77.4000903@neclab.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mipshop@ietf.org" <mipshop@ietf.org>, "BLUME, Oliver" <Oliver.Blume@alcatel-lucent.de>
Subject: Re: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <mipshop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mipshop>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2010 17:49:50 -0000

Marco Liebsch wrote:
> 
>   [...]
> >>>>     virtual interface on top of physical radio interfaces or
> >>> I suggest:
> >>>
> >>> "logical interface on top of physical radio interfaces [I-D. ietf-
> >>>  netext-logical-interface-support] or"
> >>
> >> I am not sure why we should have a reference to NetExt, as the
> >> approach how to realize this is not NetExt specific. Examples are
> >> given in the text.
> >
> > I do not propose a reference to netext, I propose a reference to a
> > document that describes exactly what you need, i.e., a logical
> > interface that hides multiple physical interfaces.
>
> Now I am a bit lost. 

I don't know why but let's give it a try?

> Why is the virtual interfase the only approach to solve this? 

Who said the virtual interface is the only approach to solve this? I've said in another note that to the extent that the IETF does not specify NETLMM extensions that require changes to the IP layer on a host, you have to hide the multiple physical interfaces under a logical interface. I thought we agree about this.

> And why should we specify in this document how to solve it?

We are not specifying how to solve it, we are giving an _informative_ reference that explains what is this logical interface that you cite as an example of how to solve the dual radio issue.

> Examples are given, including the virtual interface approach, even if 
> they are vague.. Details about what's needed are in as requested, details
> about how to solve it should not be in.

I do not follow this dichotomy. There are no details, there is an informative reference on what constitutes a logical interface.

> Also: What we need is the described behaviour of the MN, not internal
> details about hiding or not hiding physical interfaces.

Exactly what the netext document is supposed to be doing. Not describe an implementation, but the external behavior in terms of the network on one hand, and the IP layer on the host on the other hand.

--julien