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

From: "netext issue tracker" <[email-masked]>
Date: Thu, 03 Mar 2011 17:17:56 -0000

#4: Logical interface support: Point to point links

 Clarify the use and behavior of the logical interface on PtP links.

-- 
---------------------------------------+------------------------------------
 Reporter:  basavaraj.patil@…          |       Owner:  telemaco.melia@…                 
     Type:  defect                     |      Status:  new                              
 Priority:  major                      |   Milestone:                                   
Component:  logical-interface-support  |     Version:                                   
 Severity:  -                          |    Keywords:                                   
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/4>
netext <http://tools.ietf.org/netext/>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 14 Mar 2011 15:24:29 -0800

> #4: Logical interface support: Point to point links

 Clarify the use and
> behavior of the logical interface on PtP links.

Folks: Again, reflecting the team's contributions on this topic, the authors
of this document have discussed this and resolve it with the following text.
The key points we tried to reflect are around that the logical interface
appears to the application as a shared link. There were thoughts around
making it appear like a p2p link, given that there are multiple neighbors on
each sub interface, this choice appears reasonable. With respect to how a
packet is transmitted, is still based on the chosen link model at each sub
interface level. Let us know, if you see any issues with it. This is proven
based on the multiple implementations from some of the co-authors of this
doc.

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

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

> #4: Logical interface support: Point to point links

 Clarify the use and
> behavior of the logical interface on PtP links.

--

> Reporter:  basavaraj.patil@Š          |       Owner:  telemaco.melia@Š
> 
 Priority:  major                      |   Milestone:
Component:  logical-interface-support  |     Version:
 Severity:  -                          |    Keywords:

netext
> <http://tools.ietf.org/netext/>

_____________________________________________
> __
netext mailing
> list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext

---

From: Julien Laganier <[email-masked]>
Date: Mon, 14 Mar 2011 18:20:02 -0700

Sri -

5213 supports only PtP links thus I do not understand how the
following resolution resolves anything. Please clarify what is the
issue you' re addressing and how this is addressing it.

--julien

On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli <[email-masked]> wrote:
> _______________________________________________
> netext mailing list
> [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 14 Mar 2011 19:03:54 -0800

Julien:

Lets see, what is the violation here ?

- We are stating the logical interface appears to the applications as an
interface attached to a shared link. For the simple reason, that we have
multiple neighbors on different network segments attached through different
sub-interface of that logical interface. We don't have a single
neighbor/MAG. 

- "Underneath the logical interface ...", there are sub-interfaces which may
be very well attached to different p2p links. As long as the network has the
semantics to send a RA with PIO, exclusively to this node, no other node on
that access link can receive that Prefix set, we are confirming to 5213 link
model. From any of the MAG's perspective, attached to any of the access
links, it can still be kept as a p2p link

- Exposing the logical interface as a shared link to the applications on the
*mobile node*, is not violating 5213 principles. The path chosen for a
packet through a sub-interface can be still a p2p link and the rules of
link-layer resolution of the peer, or adding l2 headers skipping l2
resolution, is still the approach in use.

Sri

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 10:21:13 +0100

Hi Sri,

If I understand correctly, there is no violation of RFC5213 if all physical links are p2p. However the proposed text allows the virtual interface to bound physical shared links. If so, I think we may have the issue described in section 4.2 of http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-03. Maybe, the text should be clarified to restrict to physical p2p links.  

BR,
Pierrick 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de Sri Gundavelli
> Envoyé : mardi 15 mars 2011 04:04
> À : Julien Laganier
> Cc : [email-masked]
> Objet : Re: [netext] #4: Logical interface support: Point to point links
> 
> Julien:
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Mar 2011 16:51:31 -0700

Sri:

I am going to repeat it once again: you are equating advertizing or
per-MN subnet prefix to a point-to-point link, but these are two
different things, thus I am saying that we have a problem as 5213 is
limited to support of point-to-point links.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Mar 2011 17:17:05 -0800

Hi Pierrick,

The sentence can be reworded. Agree, the link model between the MAG and the
MN is still a point-to-point link. From 5213 perspective, as long as the
point-to-point communication semantics are there between the MN and MAG, we
meet the requirement and there is no protocol violation.  How that P2P link
model is achieved, based a tunnel interface, putting the access point in a
unicast mode, are all the possible options.

Sri

On 3/15/11 1:21 AM, "[email-masked]"
<[email-masked]> wrote:

> 
> Hi Sri,
> 
> If I understand correctly, there is no violation of RFC5213 if all physical
> links are p2p. However the proposed text allows the virtual interface to bound
> physical shared links. If so, I think we may have the issue described in
> section 4.2 of http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-03.
> Maybe, the text should be clarified to restrict to physical p2p links.
> 
> BR,
> Pierrick 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Mar 2011 17:18:00 -0800

Julien:

We all agree, the link model is still P2P. All I'm saying, we should not
classify P2P vs Non-P2P, based on the access technology type. I can build
P2P link on an IPsec tunnel, 802.11 access, or a GRE tunnel. We just require
P2P communication semantics, if we specify more that this, it will be an
over specification. Lets work out the text for this.

Sri

>>>>   the required link model and the associated state for each sub-
---------------------------------------+----------------------------------->>>>
-
>>>> Component:  logical-interface-support  |     Version:
---------------------------------------+----------------------------------->>>>
-

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Mar 2011 17:36:57 -0700

Actually, the point to point link depends on access type. Tunnels are
point to point by nature so there is nothing to do. 802.11 is a shared
media thus unless you can enforce that only two IP nodes are attached
to the link it doesn' t qualify as a point-to-point link and thus 5213
doesn' t work. This is the stuff that i supposed to go in the
applicability statement for the logical interface that this WG is
chartered to produce thus I do not understand what you mean by
overspecification. It would atcually be underspecification in terms of
the deliverable we have.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Mar 2011 17:47:04 -0800

Looks like I prompted you to say this :), when you were not exactly thinking
about that. Surely an over specification in my email text.

I'm not sure I agree. There is no 1:1 relation between a link model and an
Access Technology. Even in 802.11, every frame goes back the AP, its the
AP's choice on what gets blocked. So, that P2P link model is there even in
802.11 shared media.

If my memory serves right, I know some one who posted few emails 3 years
back in netlmm, as how to achieve this P2P links in 802.11 and use it as
PMIPv6 access links. Is that you ? :)

Sri

On 3/15/11 4:36 PM, "Julien Laganier" <[email-masked]> wrote:

>> ---------------------------------------+----------------------------------->>
>> >>
>> -
>>>>>> 
>> ---------------------------------------+----------------------------------->>
>> >>
>> -
>>>>>> 
>>>>>>>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Mar 2011 18:44:39 -0700

> about that. Surely an over specification in my email text.

I've been thinking about this for a long time, trust me.

> AP's choice on what gets blocked. So, that P2P link model is there even in

In 802.11 the MAC exposes a shared link to the IP layer. Now I am not
saying the technology can't construed into giving you a point to point
link, but that is something that a vanilla 802.11 will not give you
thus this has to be explained in the applicability statement. That is
exactly the raison d' etre of such a statement...

> PMIPv6 access links. Is that you ? :)

I think your memory is mixing up things.

Some years ago I've been trying to get NETLMM to work on shared link,
as it wouldn't work on them "as is"  without additional mechanism in
place. At this time however the WG decided to not work on these
mechanism and restrict the applicability of NETLMM to point-to-point
links.

That's what happened. Now we have to live with the limited scope that
was decided upon, and I didn' t make that decision.

--julien

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 08:22:10 +0100

agreed

> De : Sri Gundavelli [mailto:[email-masked]]
> Envoyé : mercredi 16 mars 2011 02:17
> À : SEITE Pierrick RD-RESA-REN; [email-masked]
> Cc : [email-masked]
> >> - "Underneath the logical interface ...", there are sub-interfaces
> which
> >> may
> >> be very well attached to different p2p links. As long as the network
> has
> >> the
> >> semantics to send a RA with PIO, exclusively to this node, no other
> node
> >> on
> >> - Exposing the logical interface as a shared link to the applications
> on
> >> the
> >>>> of this document have discussed this and resolve it with the
> following
> >> text.
> >>>> each sub interface, this choice appears reasonable. With respect to
> how
> >> a
> >>>> packet is transmitted, is still based on the chosen link model at
> each
> >> sub
> >>>> ---------------------------------------+-----------------------------
> --
> >> -----
> >>>>
> >>>>>
> >>>> ---------------------------------------+-----------------------------
> --
> >> -----
> >>>>
> >>>>>

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 Mar 2011 11:31:09 -0700

Pierrick,

I am confused... Do you disagree that a vanilla IEEE 802.11 isn't a
point-to-point link?

--julien

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 19:53:11 +0100

> De : Julien Laganier [mailto:[email-masked]]
> Envoyé : mercredi 16 mars 2011 19:31
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]

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.  

> >> > links are p2p. However the proposed text allows the virtual interface
> to
> >> bound
> >> >> - We are stating the logical interface appears to the applications
> as
> >> an
> >> >> that access link can receive that Prefix set, we are confirming to
> 5213
> >> >> link
> >> >>> On Mon, Mar 14, 2011 at 4:24 PM, Sri Gundavelli
> <[email-masked]>
> >> >> wrote:
> >> >>>> Folks: Again, reflecting the team's contributions on this topic,
> the
> >> >> authors
> >> >>>> interface level. Let us know, if you see any issues with it. This
> is
> >> >> proven
> >> >>>> based on the multiple implementations from some of the co-authors
> of
> >> >> this
> >> >>>> doc.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> ---
> >> >>>>  The sub-interfaces of a logical interface can be bound to a
> point-
> >> to-
> >> >>>>   interface appears as a shared-link to the applications, and
> adapts
> >> to

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 Mar 2011 12:03:56 -0700

Pierrick,

On Wed, Mar 16, 2011 at 11:53 AM,  <[email-masked]> wrote:
>
>
>> Julien Laganier <[email-masked]> wrote:
>>
>> Pierrick,
>>

Thanks for clarifying.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 Mar 2011 12:31:02 -0800

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. 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.
We also agreed, we can achieve that with today's 802.11 standards and
today's boxes out there.
 
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. 

We can just state the requirement of P2P link model on any access
technology, and leave it there.

Sri

On 3/16/11 11:03 AM, "Julien Laganier" <[email-masked]> wrote:

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 Mar 2011 12:43:30 -0700

Sri,

On Wed, Mar 16, 2011 at 1:31 PM, Sri Gundavelli <[email-masked]> wrote:
> model.

That is better, and different from what is in the draft that says
shared link is supported.

   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

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

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.

> VLAN's, send unicast RA's per RFC-6085, set up some L3 tunnels, is beyond

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.

> 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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 Mar 2011 12:47:50 -0800

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 Mar 2011 13:17:23 -0700

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

---

From: Julien Laganier <[email-masked]>
Date: Thu, 24 Mar 2011 11:07:34 -0700

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:

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

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:

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.

---

From: <[email-masked]>
Date: Fri, 25 Mar 2011 13:33:50 +0100

Hi Julien,

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

Pierrick

> Envoyé : jeudi 24 mars 2011 19:08
> À : [email-masked]
> Cc : SEITE Pierrick RD-RESA-REN; Sri Gundavelli
> >>>>> On Wed, Mar 16, 2011 at 11:53 AM,  <pierrick.seite@orange-
> ftgroup.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>