Subject: Re: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt

From: <[email-masked]>
Date: Tue, 1 May 2012 14:54:20 +0000

Sri,

Your comment below:
"Clearly this is a requirement spec with some minimal guidance on how to
deal with specific issues."
is not exactly reflected in terms of the content in the I-D. It does not
read that way.

I think Julien has a good point about how to structure and document the
concept of a logical interface while leaving the details to
implementations. 

-Raj

On 4/30/12 7:25 PM, "ext Sri Gundavelli" <[email-masked]> wrote:

>Hi Julien.
>
>Thanks for the comments. Inline ...
>
>
>On Apr 30, 2012, at 4:29 PM, Julien Laganier wrote:
>
>> On Mon, Apr 30, 2012 at 12:32 PM,  <[email-masked]> wrote:
>>> 
>>> Please make an effort and do a review of this I-D.
>> 
>> I have reviewed this document and IMHO the document is focused too
>> much on one implementation strategy, i.e., that of a stub logical
>> interface not connected to any link, layered on top of physical
>> interfaces, at the expense of describing a generic abstract model of a
>> logical interface that can be implemented in many manners. In doing
>> so, the document unnecessarily restrict the applicability of the
>> logical interface concept and describes workarounds that seem overly
>> complex and unnecessary. For example, the concept of virtual
>> identifier seems to prevent doing inter technology handovers.
>> 
>
>Not sure, if that was our goal, but if any part of the text is focussed
>on a specific approach, we have to fix that.  Logical interface is a
>software construct with certain expected behavior with respect to its
>interfacing with the physical link, ND traffic handling, and with respect
>to how the messages/events are forwarded up the stack. Clearly this is a
>requirement spec with some minimal guidance on how to deal with specific
>issues. The focus was mainly on:
>
>- The concept of a Logical Interface and the purpose
>- properties of the Logical interface, its related to the physical
>interfaces
>- How does logical interface deal with link specific ND messages, how
>RA's are seen, how RS is sent. L2 identifiers ...
>- Presents only the details/issues that the implementations have to be
>aware off.
>
>As I see it, if I'm implementing a logical interface, I need to know
>these details.  Now, there can be multiple ways to implement and meet
>these requirements. No part of the spec is using 2119 language, or
>suggesting how to implement it. Its some general guidance.
>
>
>
>
>>   o  In access architectures, where the link-layer identifier is
>>      associated with a specific access technology, it will not be
>>      possible for the logical interface to adopt a virtual identifier
>>      and it use it across different access networks.  In such networks,
>>      the logical interface must use the identifier of the respective
>>      sub-interface through which a packet is being transmitted.
>>      However, if more than one access technology domains that are part
>>      of the logical interface have such requirement, then the logical
>>      interface will not be able to support such configuration.
>> 
>> It seems to me that much of the issues revolving around link layer
>> identifiers, MTU, Neighbor Discovery, and Multicast, could be avoided
>> if the document eliminated the current dependency on the
>> implementation strategy being described in favor of a comprehensive
>> logical interface support, where the logical interface is attached to
>> a logical link which is terminated by a logical router. This logical
>> router would in turn be attached to the physical interfaces themselves
>> and perform adequate routing.
>> 
>
>The above text is about a specific issue related to choice of interface
>identifier selection. If WiMAX access is making certain assumption about
>the interface identifier, a given implementation needs to be sensitive to
>that aspect. So, we are only reflecting the issues with the interface
>identifier selection and the considerations. So, I'm not sure, if the
>above is about a specific implementation. The spec can be silent about
>this, but implementations will have no clue. At the end of the day, this
>is an informational spec, you and me/WG having worked on such things we
>have some understanding about the issues. But, some developer may not be
>aware of these considerations.
>
>
>>  This logical
>> router would in turn be attached to the physical interfaces themselves
>> and perform adequate routing.
>> Doing so, the IP layer on the host runs unmodified and uses the
>> logical interface as any other interface. ND/ARP/DHCP etc. are
>> executed together with the logical router at the end of the logical
>> link, so is multicast. Dissimilar MTU of physical interfaces are
>> hidden behind the logical router as wellŠ
>> 
>
>One can surely make this a logical router ( I don't know how this works
>..), still taking into account the considerations listed in the document.
>Not sure, what part of the spec is preventing any specific
>implementation, still conforming to the logical interface requirements.
>
>
>
>> Unlike the approach currently described in the document, I see only
>> advantages and no drawbacks to what I am proposing here.
>> 
>> Also note that this model is currently implemented and shipping on
>> many mobile devices, where two flavors of the model coexist; one where
>> the logical link is PPP, and another where it is Ethernet-like.
>> 
>
>
>I agree with that.  But, you also know, in the absence of some guidance
>how different implementations have violated some basics and the current
>situation with the 3G drivers. But, I again, we are not interested in
>reflecting any specific implementation, the goal is to provide
>requirements.
>
>
>
>Sri
>
>
>
>> --julien
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>
>_______________________________________________
>netext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 1 May 2012 08:04:19 -0700

Raj:

> concept of a logical interface while leaving the details to

No disagreement. As I said, our goal is get some implementations supporting the LIF approach on mobile terminals. Help the implementors understand all the issues with ND and related issues, provide some hints on how to achieve this. if there are parts of the text suggesting only a specific way of implementation, we should fix that and state that its only out of the many ways to achieve that. So, no disagreement there. These comments from you and Julien help; we know at least the open issues.

Sri