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

Marco Liebsch <marco.liebsch@neclab.eu> Tue, 14 September 2010 07:38 UTC

Return-Path: <Marco.Liebsch@neclab.eu>
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 DBD923A68FA for <mipshop@core3.amsl.com>; Tue, 14 Sep 2010 00:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.153
X-Spam-Level:
X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 AYPm9FUQkRvT for <mipshop@core3.amsl.com>; Tue, 14 Sep 2010 00:38:11 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 773B43A68F6 for <mipshop@ietf.org>; Tue, 14 Sep 2010 00:38:11 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DAEDB28000188; Tue, 14 Sep 2010 09:38:35 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqRZQYCoNvAu; Tue, 14 Sep 2010 09:38:35 +0200 (CEST)
Received: from ENCELADUS.office.hd (Enceladus.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B7E812800017D; Tue, 14 Sep 2010 09:38:15 +0200 (CEST)
Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 14 Sep 2010 09:37:00 +0200
Message-ID: <4C8F261B.2050008@neclab.eu>
Date: Tue, 14 Sep 2010 09:36:59 +0200
From: Marco Liebsch <marco.liebsch@neclab.eu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "Laganier, Julien" <julienl@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> <BF345F63074F8040B58C00A186FCA57F1F6826E400@NALASEXMB04.na.qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F6826E400@NALASEXMB04.na.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.6.32]
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: Tue, 14 Sep 2010 07:38:14 -0000

  Julien,

Am 13.09.2010 19:50, schrieb Laganier, Julien:
> 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?
When you write that 'this is what we need', it can be understood that way.


>   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.
the document you refer to comprises text about solving certain things 
with a virtual interface. So, it's a solution, isn't it?
But I have no problem with adding this.


>> 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.
I don't know why, but let's give it a try ;-) ..

>   There are no details, there is an informative reference on what constitutes a logical interface.
ok

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

marco

> --julien