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

[Julien Laganier <[e-mail]>]

2011/3/15 Sri Gundavelli <[e-mail]>:
> 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've been thinking about this for a long time, trust me.

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

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

> 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 ? :)

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

> On 3/15/11 4:36 PM, "Julien Laganier" <[e-mail]> wrote:
>
>> 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
>>
>> 2011/3/15 Sri Gundavelli <[e-mail]>:
>>> 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
>>>
>>>
>>>
>>> On 3/15/11 3:51 PM, "Julien Laganier" <[e-mail]> wrote:
>>>
>>>> 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
>>>>
>>>> 2011/3/14 Sri Gundavelli <[e-mail]>:
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 3/14/11 5:20 PM, "Julien Laganier" <[e-mail]> wrote:
>>>>>
>>>>>> 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 <[e-mail]>
>>>>>> wrote:
>>>>>>>> #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.
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/3/11 9:17 AM, "netext issue tracker"
>>>>>>> <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> #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/>
>>>>>>>
>>>>>>> _____________________________________________
>>>>>>>> __
>>>>>>> netext mailing
>>>>>>>> list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netext mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>