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

<pierrick.seite@orange-ftgroup.com> Fri, 25 March 2011 12:32 UTC

Return-Path: <pierrick.seite@orange-ftgroup.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 BC00128B56A for <netext@core3.amsl.com>; Fri, 25 Mar 2011 05:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level:
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 q8dl6ctKTSdW for <netext@core3.amsl.com>; Fri, 25 Mar 2011 05:32:18 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4AB2F3A6847 for <netext@ietf.org>; Fri, 25 Mar 2011 05:32:17 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3268C79800A; Fri, 25 Mar 2011 13:39:48 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 29F4A798009; Fri, 25 Mar 2011 13:39:48 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Mar 2011 13:33:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Mar 2011 13:33:50 +0100
Message-ID: <843DA8228A1BA74CA31FB4E111A5C462019551AD@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <AANLkTi=ODv3RDAtGqo2C7n-C_DiWcty28NUkqxLRFsgT@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netext] #4: Logical interface support: Point to point links
Thread-Index: AcvqTlp5UQOktyHvTxWL02PizBSAeQAmIgNQ
References: <AANLkTi=HfMj=HoU_jQX=6WyTtn+rmBd=VefhDfufVYcu@mail.gmail.com><C9A661F6.13AFF%sgundave@cisco.com><AANLkTi=5a_WTs85JeonH5ucn3kdupQKOXmv2A4J9GY82@mail.gmail.com> <AANLkTi=ODv3RDAtGqo2C7n-C_DiWcty28NUkqxLRFsgT@mail.gmail.com>
From: pierrick.seite@orange-ftgroup.com
To: julien.ietf@gmail.com, netext@ietf.org
X-OriginalArrivalTime: 25 Mar 2011 12:33:51.0807 (UTC) FILETIME=[E5C004F0:01CBEAE8]
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: Fri, 25 Mar 2011 12:32:20 -0000

Hi Julien,

IMHO, your text can replace the current section; there is no need to say more.

Pierrick

> -----Message d'origine-----
> De : Julien Laganier [mailto:julien.ietf@gmail.com]
> Envoyé : jeudi 24 mars 2011 19:08
> À : netext@ietf.org
> Cc : SEITE Pierrick RD-RESA-REN; Sri Gundavelli
> Objet : Re: [netext] #4: Logical interface support: Point to point links
> 
> 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
> >>
> >>
> >