Re: [netext] #4: Logical interface support: Point to point links

Julien Laganier <julien.ietf@gmail.com> Thu, 24 March 2011 18:06 UTC

Return-Path: <julien.ietf@gmail.com>
X-Original-To: netext@core3.amsl.com
Delivered-To: netext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B7C28C141 for <netext@core3.amsl.com>; Thu, 24 Mar 2011 11:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.31
X-Spam-Level:
X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 TIMLRvTlQ81f for <netext@core3.amsl.com>; Thu, 24 Mar 2011 11:06:01 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B3F0328C13D for <netext@ietf.org>; Thu, 24 Mar 2011 11:06:00 -0700 (PDT)
Received: by ewy19 with SMTP id 19so186117ewy.31 for <netext@ietf.org>; Thu, 24 Mar 2011 11:07:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Kn5Tkmu6aVD5jzMKb6MBSHJb0YtatU0HR6OV4apraJs=; b=brMOnxwGRiKmHP5YWo6qT5d75IfgdkYIugj+aByELLWoIJV6uA2SIrDGbVqVBVdC1A mV8xAo5mb0CwKKcYWK1y2VsC8ww/Iuhl04RkYmqIQ25N2B4hwZ4pH722t1cVJ/deXUXE rbxkXCY0/4ATw3aRrvlC/g+zf2HY3LbErSxEA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mRyL82PTDBB1xj8ctIDIrKZ6/+ziI3RhCncgdwlXShBZy7Xrl2ysoIQqsBjpMutCMz voUpEdo9C5StHOPgjWVShUegsTxeeTh2GVdTy+5MgtbRQGauW7cEpx+qfpLp154KPQAK K7+rjgUyvYSFAlqgWp+3yhpYcNnDuznjb/33Y=
MIME-Version: 1.0
Received: by 10.216.24.73 with SMTP id w51mr7466280wew.72.1300990054871; Thu, 24 Mar 2011 11:07:34 -0700 (PDT)
Received: by 10.216.89.205 with HTTP; Thu, 24 Mar 2011 11:07:34 -0700 (PDT)
In-Reply-To: <AANLkTi=5a_WTs85JeonH5ucn3kdupQKOXmv2A4J9GY82@mail.gmail.com>
References: <AANLkTi=HfMj=HoU_jQX=6WyTtn+rmBd=VefhDfufVYcu@mail.gmail.com> <C9A661F6.13AFF%sgundave@cisco.com> <AANLkTi=5a_WTs85JeonH5ucn3kdupQKOXmv2A4J9GY82@mail.gmail.com>
Date: Thu, 24 Mar 2011 11:07:34 -0700
Message-ID: <AANLkTi=ODv3RDAtGqo2C7n-C_DiWcty28NUkqxLRFsgT@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: netext@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [netext] #4: Logical interface support: Point to point links
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2011 18:06:02 -0000

Folks,

I've been chatting offline with Sri and I'd like to share with the
rest of the WG my latest proposal regarding the content of section
6.3.

I would reword the first sentence of the paragraph:

   The sub-interfaces of a logical interface can be bound to a point-to-
   point or a shared link (Example: LTE and WLAN).

into:

As per the original PMIPv6 specificiation [RFC5213] the physical
interface underneath the logical interface has to be bound to
point-to-point link [RFC4861]. Access technologies that provides a
shared media (e.g., IEEE 802.11) can be supported as long as they
provide a point-to-point link [rfc4861]. The details of how a shared
media provides a point to point link are link layer specific and/or
operational matters that are out of scope of this document. For
example IEEE 802.11 media can provide a point-to-point link via the
appropriate use of IEEE 802.1Q VLAN header where a distinct VLAN is
configured between the MAG and each of the mobile node.

I would remove the second sentence:

   The logical interface appears as a shared-link to the applications,
and adapts to
   the link model of the sub-interface for packet communication.  For
   example, when transmitting a packet on a sub-interface which is
   attached to a p2p link, the transmission conforms to the p2p link
   model and when transmitting on a sub-interface attached to a shared
   link, the transmission conforms to the shared link model.

Because it doesn' t add much, for the two following reasons: 1) I don' t
know what it means that a transmission conforms to the {ptp, shared}
link model, and 2) it is tautologic, e.g., if the link is {ptp,
shared} then transmit conforming to the {ptp, shared} link model...

I would remove entirely the second paragraph:

   Based on the link to which the sub-interface is attached to, the
   layer-2 resolutions may or may not be needed.  If the interface is
   bound to a P2P link with PPP running, there will not be any link-
   layer resolutions in the form of ARP/ND messages.  However, if the
   interface is bound to a shared link such as Ethernet, there will be
   ND resolutions.  The logical interface implementation has to maintain
   the required link model and the associated state for each sub-
   interface.

as it is tautologic as well, it sort of says:

1. address resolution may or may not be needed => how could it be
different. it's like saying it might day or it might be night, where
is the information?
2. if address resolution is not needed, it is not performed => ditto.
3. if address resolution is needed, it is performed.

Finally it talks about shared link that we do not support. Thus I
think we should remove it altogether.

On Wed, Mar 16, 2011 at 1:17 PM, Julien Laganier <julien.ietf@gmail.com> wrote:
> Hi Sri,
>
> I don't know what it means that a link meets the point-to-point link
> model semantic, and I certainly don't want the reader to be told it's
> sending an unicast RA.
>
> The link to which the physical interface has to be a point-to-point
> link as per 5213, period. We are not chartered to change this.
>
> --julien
>
> On Wed, Mar 16, 2011 at 1:47 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
>> Hi Julien,
>>
>> I already agreed, we need to put a qualifier on that one sentence, which
>> states, the physical link being a shared link. If you agree, that qualifier
>> can be, "the physical link attached to the logical interface can be a shared
>> link, as long as it can meet the point-to-point link model semantics". Agree
>> ?
>>
>>
>> Regards
>> Sri
>>
>>
>>
>>
>> On 3/16/11 11:43 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote:
>>
>>> Sri,
>>>
>>> On Wed, Mar 16, 2011 at 1:31 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
>>>> I'm not sure, we can say, we need additional mechanisms in 802.11 to achieve
>>>> p2p link model. We are not talking about protocol extensions, its rather
>>>> about configuration. From PMIP perspective, we all agree, we need P2P link
>>>> model.
>>>
>>> That is better, and different from what is in the draft that says
>>> shared link is supported.
>>>
>>> 6.3.  Supported Link models for a logical interface
>>>
>>>    The sub-interfaces of a logical interface can be bound to a point-to-
>>>    point or a shared link (Example: LTE and WLAN).
>>>
>>> Do you disagree with the content of the draft?
>>>
>>>>  If some one wants to connect trusted WLAN access networks with PMIP
>>>> domain, they can very well do that, as long as they support P2P link model.
>>>
>>> Yes, as long as they support point to point link model, and unlike
>>> what is the current draft.
>>>
>>>> We also agreed, we can achieve that with today's 802.11 standards and
>>>> today's boxes out there.
>>>
>>> You can achieve that with today's 802.11 standards. Not sure about
>>> boxes out there. My AP only does shared link. This discussion seems to
>>> be moot since current APs do not have MAGs.
>>>
>>>> How they do that, if that's by configuring unique SSID's per MN, unique
>>>> VLAN's, send unicast RA's per RFC-6085, set up some L3 tunnels, is beyond
>>>> the scope of PMIP.
>>>
>>> Again, please do not equate sending unicast RAs with having a point to
>>> point link as these are two different things.
>>>
>>> I do not care how having a point to point link on a physical interface
>>> is done, my point is that was that the current draft says that shared
>>> link are supported while they are not, and I didn't put that text in
>>> that draft, for that matter.
>>>
>>>> We can just state the requirement of P2P link model on any access
>>>> technology, and leave it there.
>>>
>>> Right thus you agree the draft has to be corrected wherever it talks
>>> about shared links, to say that only point-to-point links are
>>> supported, and that shared links are not supported.
>>>
>>> Thanks.
>>>
>>> --julien
>>>
>>>> On 3/16/11 11:03 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote:
>>>>
>>>>> Pierrick,
>>>>>
>>>>> On Wed, Mar 16, 2011 at 11:53 AM,  <pierrick.seite@orange-ftgroup.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> Julien Laganier <julien.ietf@gmail.com> wrote:
>>>>>>>
>>>>>>> Pierrick,
>>>>>>>
>>>>>>> I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a
>>>>>>> point-to-point link?
>>>>>>>
>>>>>>
>>>>>> No... I was just agreeing  to require p2p link model on the physical links.
>>>>>> So, 802.11 cannot be used without additional mechanism to achieve a
>>>>>> point-to-point link. Actually, nothing new with regards to RFC5213.
>>>>>
>>>>> Thanks for clarifying.
>>>>>
>>>>> --julien
>>
>>
>