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

[Julien Laganier <[e-mail]>]

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