[netext] Review of draft-ietf-netext-logical-interface-support-04

[Peter McCann <[e-mail]>]

In Taipei I picked up an action item to review the logical interface support
draft.  Here are some comments on it.


In general, I think you need to consider some of the problems being dealt
with in the MIF working group in the context of this document.  Mapping 
IP flows onto physical interfaces is just one of the things that you have
to worry about.  What if each physical interface is connected to a different
provisioning domain?  How do you deal with things like multiple sets of
DNS servers, or conflicting DHCP options?

I am not sure what is gained by using a logical interface as depicted
in Figure 5 of Section 6.1.  There are two different prefixes here
(why are we going back to a single LMA at all in this case?) so you 
might as well have presented this as two different interfaces to the
upper layers.

I think the use cases in Section 6.2 and 6.3 were more what the authors
had in mind when thinking about this logical interface concept.  However,
I have a concern: in these cases, you need to know that the two physical
interfaces are being routed by the network back to the same LMA.  In general,
the two technologies may be routed to completely different service providers.
How does the logical interface manager in the host distinguish these two
cases?  By its very definition, PMIP does not expose the workings of the
network to the host.  Are you saying that a given host will only use its
WLAN interface in conjunction with a wide-area cellular operator?  That
doesn't seem very realistic given today's usage models, where I can take
my phone into my home and use my home WLAN network.



Section 4, I am not sure about your description of the 3GPP link layer.
As shown in your protocol stack in Figure 2, there is no PPP, although
it is true that the concatenation of PDCP and GTP makes for a point-to-point
link.  Also, you should make it clear that the random L2 MAC address is
only used in the Source Link Layer Address *option* of ND, and not as a
true link layer source address (there is no place in the PDCP headers to
put such a thing).  I believe this address is simply ignored by the PGW
since it has a tunnel endpoint associated with the UE.


Editorial nits:

Section 3.2.1:
   This type of solution does not typically allow for simultaneous
   attachment to different access networks, and therefore can only be
   considered for inter-access technology handovers, but not for flow
   mobility.
I think you meant to say:
   This type of solution does not typically allow for simultaneous
   attachment to different access networks, and therefore can only be
   considered for intra-access technology handovers, and not for flow
   mobility.

In Section 5.6: s/PIF Table/FLOW Table/



--
Peter J. McCann
Huawei Technologies (USA)
[e-mail]
[phone]
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA