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 > >> > >> > >
- [netext] #4: Logical interface support: Point to … netext issue tracker
- Re: [netext] #4: Logical interface support: Point… Sri Gundavelli
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… Sri Gundavelli
- Re: [netext] #4: Logical interface support: Point… pierrick.seite
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… Sri Gundavelli
- Re: [netext] #4: Logical interface support: Point… Sri Gundavelli
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… Sri Gundavelli
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… pierrick.seite
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… pierrick.seite
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… Sri Gundavelli
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… Sri Gundavelli
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… Julien Laganier
- Re: [netext] #4: Logical interface support: Point… pierrick.seite