[netext] IETF79 WG Meeting minutes

[<[e-mail]>]

Network-Based Mobility Extensions IETF 79 WG meeting (Beijing, China)

Tuesday, November 9th, 2010
1520-1700 Afternoon Session II and
1710-1810 Afternoon Session III (Emerald)

Chairs:  Basavaraj Patil ([e-mail])
         Rajeev Koodli ([e-mail])

Minutes of meeting by: Carl Williams ([e-mail])
                       Elena Demaria  ([e-mail])



1) Agenda for IETF 79 meeting was presented by Basavaraj
 -------------------------------------------------------

1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins

2. WG status update       Chairs  5 Mins


3. Logical Interface Support for multi-mode IP Hosts
   Telemaco Melia    15 Mins
   I-D: draft-ietf-netext-logical-interface-support-01

4. Proxy Mobile IPv6 Extensions to Support Flow Mobility
   Carlos Bernardos    25 Mins
   I-D: draft-bernardos-netext-pmipv6-flowmob-01

5. Flow mobility support in PMIPv6
   Tran Minh Trung  20 Mins
   I-D: draft-trung-netext-flow-mobility-support-00

6. PMIPv6 inter-working with WiFi access authentication
   Marco L./Sri Gundavelli   10 Mins
   I-D: draft-liebsch-netext-pmip6-authiwk-00

7. Multi-access Indicator for Flow Mobility
   Rajeev Koodli   5 Mins
   I-D: draft-koodli-netext-multiaccess-indicator-00.txt

8. a. Scenarios of the usage of multiple home network prefixes on a
   logical interface
   I-D: draft-hong-netext-scenario-logical-interface-02.txt
   b. Hybrid home network prefix for multihoming in PMIPv6
   I-D: draft-hong-netext-hybrid-hnp-03.txt
   Yong-Geun Hong 15 Mins

9. Next steps Chairs  5 Mins


2)  Working group status update
-------------------------------

Basavaraj provided an update on working group activities including
working group documents and additional proposals for the working
group.

Runtime LMA Assignment Support for PMIP6
(draft-ietf-netext-redirect-04).  Draft presented at several IETF
meetings. Author said nothing more to present at this IETF. This draft
had several reviews and has been succinctly updated.  It has completed
working group LC.  Author said to submit to IESG for review.  There is
security consideration issue that was raised on email alias.   Whether
we need two options (which draft has) or if we converge on just one we
need to decide before submitting to the IESG.

Bulk Re-registration for Proxy Mobile IPv6
(draft-ietf-netext-bulk-re-registration-02).  Yokota-san and X. Cui
have provided comments and draft was revised. Sri said it is ready for
Working Group LC.   Basavaraj said however that we need to have review
of these documents and if we dont get reviews we will not progress
documents.

PMIPv6 localized routing problem statement
(draft-ietf-netext-pmip6-lr-ps-03).  Basavaraj stated already done
working group LC.  It has been a while since we reviewed document so
we will do a short 1 week LC on this document and then forward to
IESG.

Localized Routing for PMIP6 (draft-ietf-netext-pmip-lr-01).  Basavaraj
wants reviews done before issuing a WG LC. Suresh has presented
previous meetings. Basavaraj says that people arent paying attention
to this document. He said he wants at least two reviews before going
to working group last call.  Carlos has volunteered and as well as
Gaetan.  Basavaraj wants reviews completed in next couple of weeks.

Radius support for PMIP6 (draft-ietf-netext-radius-pmip6-00). Authors
feel that the reason that there isnt so much interest in this draft
is that there is lack of expertise in this room on radius. One option
is to have experts from RADEXT or DIME to take a look at draft and
provide feedback.  Basavaraj also stated that the other way he looks
at it isnÕt interest in these extensions at all for PMIPv6.  We have
to make a decision of what we want to do with this draft.  Sri stated
that he thinks this is essential and needs to be done.  Basavaraj
stated that we must solicit experts and that no one has reviewed this
ID.   AAA experts must be solicited by the authors for performing
review.  Julien suggested that this may not be required.   Julien
stated that there may be different options.  Basavaraj stated that his
reading is that even the authors arent making an effort to move this
ID forward.  Basavaraj stated that we need to say that this is needed
for deploying the protocol; otherwise, it wont move forward.   DIME
and RADEXT working groups could provide expert advice.  It is up to
the authors to contact them. If authors want chairs to do Working
group LC across RADEXT and DIME we can do that.




3)  Logical Interface Support for Multi-mode IP hosts
------------------------------------------------------

Telemaco Melia presented
draft-ietf-netext-logical-interface-support-01.  Telemaco stated that
together with Sri and other authors that he is only going to provide a
brief update since last IETF and the discussion that has been going on
over past weeks.  Telemaco gave a picture of changes they did and went
over them.  Telemaco went over ND support for logical interfaces; been
discussing support in terminal device and got implementation done.
Got some feedback.   Also went through comments at last IETF such as
MTU issues.  This is what we did since last IETF as well as we also
worked on aligning ID with solution draft on flow mobility.
Telemaco stated that they provided text with respect to the properties
of the logical interface.   Telemaco went over bullets with that text.
Telemaco stated that he had off-line discussions prior to the working
group meeting with 3GPP folks that property 6 bullet listed in his
slide was relaxed.   Property 6 states that:  ÒThe Logical interface
should transmit uplink packets on the same physical interface on which
the downlink packet was received for the particular prefix/flow.Ó
Telemaco  then covers the discussion of the points he just made.  The
Virtual Link Layer ID Ð we had a lot of discussion on this point.
Telemaco says that we agreed that the Logical interface has a virtual
link-layer identifier and it is used for ND operations;  is stored in
binding cache of LMA and used as source link-layer for sending packets
from this logical interface.    Telemaco stated that physical
interface SHOULD be able to send packets with the VLL-ID as the source
link-layer address and SHOULD be able to receive packets with the
VLL-ID as the destination link-layer address.
Julien:   stated that some link-layers do not have link layer IDs.
Telemaco Response:   yes, so what we agreed is that there will be a
configure exchange when bring up interface.  The most common use case
will be WiFi.  Most WiFi interfaces can change MAC address.
Julien:  If you have to cope with the case that you cannot do that, why
not use this same mechanism all the time.    If you have to deal with
the case that you cant change the link-layer id because there is no
link-layer id,  and you have a solution for this then why not use it
all the time.
Telemaco Response:  what we discussed was an alternative to a mapping
between the logical interface and the physical interface.  Dont yet
have complete picture.  This is what we are currently working on.
There are cases that we wont be able to support it right now and
working on.
Rajeeve:   If you are designing for case dont work then why not use
for default case and use it uniformly.
Julien:  It is logical and doesnÕt exist - only exist in host as a
construct.  Only the host sees the logical interface.  There is no
link-layer for the logical interface so dont need link-layer id.  If
you introduce this link-layer ID on wire then you run into problems
everywhere.  ND will break.   Only host sees logical interface and why
tell the rest of the world of it.
Telemaco Response:   It will simplify the solution.
Julien:  Only host sees logical interface and why tell the rest of the
world about it by having an ID for it.  You dont need to do this.
Telemaco:  Because the network has to be aware of it.
Julien:   No, it is logical.
Sri:  You need to abstract the physical interfaces.
Julien:  If you want to do slack the use then use EUI64 ID and you can
ping from any interface you have.  That is different from layer 2.
Response:  If you have this, the logical interface and use ND what you
have to do is keep state for all logical interfaces.  How many soft
states you want to keep in the logical interfaces?
Julien:  Physical interface should be able to send packets with the
VLL-ID - What about receiving?  If I cant receive packets at the
link-layer ID.
Julien:  You are making a lot of assumptions of what layer 2 you are
using.  Maybe this is WiFi.  If it only works on WiFi, just write it.
 Basavaraj:  Transmission is ok but receiving is problem.
Julien:  DonÕt need this fake thing it is just causing problems.
Kent:  I am assuming in the VLL-ID case only applies when you dont
have it.  For WiMAX you  wouldnt use any specific  vll-id  and use R6
for example.  I think it will still work but donÕt need to use
vll-id.  There is case where you have2  link layer id on physical oneÉ
but only in case you support link layer ID on the physical.   For
non-link layer how does it apply here.  I dont see the LL-id being
applied for that case.
Response: Ok.
Julien:  So what you are saying is that sometimes you use it and
sometimes you do not?
Kent:  You dont have MAC address then you dont use it obviously.
Kent:  Use it when link layer is supported on the physical.
Julien:  what if one of the physical interfaces has a MAC address and
the other does not.  how do you deal with that case.  Say you have 3G
and you have WiFi, how do you do this?
Julien:   if you take step back,  all pmip stuff was done for point to
point links - then link layer ID is pointless.  On many point to point
links you donÕt have link layer IDs.  It is a point to point link you
dont need link layer IDs, you just send frame there and it arrives.
If you expose then you run into problems.   We have been discussing
this for 20 minutes already. Just get rid of it.
Julien: PMIP doesnÕt work on shared access links  (doesnt work on
wifi by itself).  Ðmake it point to point link.  One VLAN per Mobile
node and then in layer 2 destination put broadcast.
Sri:  Support: RA unicast.
Julien: RA unicast is a different story.  PMIP works on point to point
links it is written in the spec.  wanted to have it work on shared
links but nobody wanted to do it.   Now it is done this way and you
canÕt change this.
Julien:   PMIPv6 only works on point to point links.
Julien: are we changing this.  We are not charter to change this.   I
am repeating myself now.
Sri: I agree.  As long as point to point semantics with same prefix
and stick to mobile node and even if shared link if you can achieve
that at the end of day what you have is a point to point link.
Basavaraj:  Obviously this issue needs additional discussion. I would
recommend that the concept of how we use the virtual link layer id and
what are assumptions and if we assume it works on certain access
networks- we need to have further discussion.  We can note it in
minutes and move on.
Telemaco continues on with his presentation and states that the link
scoped unicast traffic is generated by logical interface. is sent
through all physical interfaces associated to the logical interface.
Telemaco says that because  of the properties of the PMIPv6 domain
this mode of operation of the logical interface does not add any issue
from the point of view of ND
Basavaraj:  there may be some concerns as Neighbor discovery concerns.
Telemaco:  For the unicast case for link scope.  Not sending multicast
packet you are sending same packet on both links.
Rajeeve:  what you are saying is that you are sending same unicast
packet on multiple physical interfaces. Not sending mulicast.
Telemaco:  yes.
Telemaco:  You have 2 options (comes in next slide) either you keep
states for the ND procedures on any physical interface or you can in
this case replicate the packet.  We are discussing this and this is
one of the option and we know it is working because we tested it.
Suresh: if one of the interface is not up ICMP error can be
generated. How does it work?
Telemaco:  From an IP stack perspective we dont change anything so if
the logical interface sees that there is a packet generated for
refresh neighbor cache for instance and one of the sub-interfaces is
active and the other one is not active, then the inactive
sub-interface is not going to be used.  From a neighbor cache
perspective of the logical interface there will be one entry which is
the MAC because they share the same link local address.
Telemaco:  So from that perspective if I know which link is going to
be used there is nothing wrong going on the neighbor cache. It looks
like a normal neighbor cache and not touched and from this perspective
it works.  You just need to use the same packet on both links and it
works.
Suresh:  what if same address  exist on two of these  interface that
the packet goes out through how do you resolve duplication across
multiple links for the same link local address?  How do you maintain
the neighbor cache?
Telemaco:  Which address is duplicated?
Suresh:  Let say that link local traffic - for example an address
resolution NS Ð is a link local multicast traffic .  So letÕs say that
I send a packet out to trying to resolve fad::3 for example and it is
going out through multiple physical links, it is possible that there
is somebody on both links whoÕs got the same address but  different
link-layer addresses, how do you handle merging these two things into
the neighbor cache?
Telemaco:  There are only the MACs behind. And the MACs are
configured per mobile node.
Suresh: still point to point is ok.
Julien: is this point to point or is this shared.
They said it is shared.
Julien:   what if I send a MLD message to get some multicast traffic.
I send an MLD join to receive multicast traffic am I going to receive
it on all my physical interfaces
Telemaco:  Possible yes.
Julien:  You say link local multicast traffic, do you talk about
neighbor discovery or link local multicast traffic?
Response:  I am using  Neighbor  Discovery here as we are talking
about Neighbor Discovery.
Julien:  Am I only to do this for Neighbor discovery packets?  Or am I
suppose to do this for all the link local traffic?
Telemaco:  we are focusing here on neighbor discovery. If you want to
know about other taffic, than we need to examine it.
Julien:  What I do when I send  a MLD join  - it is a multicast packet
and link local  - do I send it through all my physical interfaces?
Then I am receiving all my traffic through all my physical interfaces.
Jari:   I am also wondering about that.   I guess that the goal would
be here that we do the construction of a particular interface and the
end result  is such that that host doesnÕt see a difference.  It
behaves as a normal interface.  If it starts to receive packets
multiple times, then that could be a problem.
Basavaraj:   The authors dont really understand how to deal with
multicast join.  Dealt with neighbor discover.  Authors donÕt
understand and they need to take a look.
Telemaco:  wasnÕt initially in scope.
Carlos:  The way in which we discussed it briefly is that this we are
assuming this is in a constraint environment and control environment
and talking to the same LMA (controlled environment). The MLD would
go out through the LMA and traffic back and would be one single
traffic back we shouldnt be receiving twice the response.  It is
only one single source request.    I donÕt see a real deployment case
where we would actually be receiving twice traffic on the two
interfaces where we are sharing the link local or sharing the address
for this case.
Jari:  one special case where this works is point to point links and
nothing on other side;  it doesnt matter what you send.  You wont
receive anything and there is nothing to receive your packet.   If you
speak on this in more general sense you have multiple of interfaces
and you have applications like MLD or  multicast DNS  I am not sure
what the right behavior is.  For MLD it will be one behavior -  one stream
and for multicast dns I would like to resolve my name if it happen to
be on some other interface.  It seems like a tricky problem.  Maybe
scoping this down to where this could work it might be a reasonable
approach.
We havent got an agreement on this yet.  We have multiple opinions
and I am reflecting the current discussion.
Suresh: why cant you keep state.
Response:  we can.
Julien:  We should discuss this on alias.
Rajeeve: we need to have people to look at drafts weeks before meeting
and also for the authors if there are sticky issues than authors
should alert working group on the mailing list.   Must do both.
Telemaco:  We can trigger discussion on mailing list but it would be
nice to receive feedback as well.
Basavaraj:  we need to put on mailing list and not just discuss
between the authors.
Telemaco:  says there are other slides such as MTU considerations and
said this is easy to resolve.
Then we are discussing support of LIF conceptual data structure.
This is work that is going on subject to discussion.
Comment:  one way to address issue of logical interfaces is to provide
examples.   In 3g you have pdp context for primary connection.  It
would help discussion if you use those examples for discussion.
Basavaraj:  we will take this discussion to the mailing list and
interest of time we need to move forward.  We hope people are active
on mailing list and provide feedback to authors.
Basavaraj:  we have two documents that discuss the flow mobility work.


4)  Proxy Mobile IPv6 Extensions to Support flow Mobility
---------------------------------------------------------

Carlos Bernardos presented draft-bernardos-netext-pmipv6-flowmob-01.
Carlos stated that the first time this ID was presented was at IETF
78.   Carlos went over changes since -00.  Main changes were that he
added more text on prefix deployment models.  Carlos also added text
on partial handoff scenarios.  Next steps:  design choices still open
in draft.  Feedback from the working group is welcomed.  Carlos has
asked for working group adoption.

Julien:  sent feedback on mailing list;   shared prefix versus single
prefix is irrelevant.  What you need here is a prefix set.  And member
interfaces and move interfaces.

Carlos Response:  we are only high-lighting the scenario.  Other case
from point of how you deal with it from LMA and all sessions and you
may know to signal information on MAG.

Julien: start document with a model and then describe the model. How
you address each case.  With one of flows Ð MAG doesnÕt need to know
about the flow.

Carlos Response:  By default you only send info about prefix.

Julien: why:

Carlos Response:  there are some use cases that you need that.

Rajeeve:  If you start from there you can see where this shared or
unique.  At time of mobile attachment, if it is same prefix, than
nothing to do.  Other thing is what you convey in the message.  /64 is
already there.  With /64 you have a kind of wildcard and if you go
over /64 you have more granularity.  When LMA decides to move the flow
it checks if prefix is valid on MAG or not.

Parviz:  from the application perspective is mobility seamless

Carlos response:  Yes, both interfaces are attached at same time.

Vijay: is there are requirement that there is seamless mobility.

Carlos:  No, but have it anyways.

Rajeeve:  what do you mean by seamless.

Basavaraj:  Move flow from one MAG to another MAG.  Whether it is
seamless we are not looking at.

Comment:  do you agree the target should we move them seamlessly?

Basavaraj:  We are not worried about that at the moment.

Rajeeve:  Optimization comes next.  We want basic operational
document.  So that flow movement happens.  Let us first get basic
mechanism working first.

Rajeeve:  Basic assumption we have a logical interface here.  We
arenÕt dealing with interface handover.  We are not looking at
interface handover.

Sri:  So I agree.  With respect to flow granularity however I
disagree. We have to stay within the scope of the prefix.  This works
for the use cases and how 3GPP can use it.   If we try to do more than
we have issues.

Sri:  Approach RFC 5213 Ð it is called inter-technology handover.

Melia:  There are technologies that accept flow.  Why should we cut
off our legs.

Sri:  Not cutting of legs.  It is about scope.  The constraints:
Interfaces.

Rajeev:  I have a comment on overall scope.  CanÕt change anything on
MN link.  But can punch into the layer 2.  You can explicity state
that how to handle from MAG to mobile that it can be specified in the
access layer.

Sri:  That is not in current scope.

Rajeeve:  Not making assumption about protocol that you need to
specify.  There are access specific signaling that is possible.

Sri:  What is this interface?  At the end of the day someone has to
implement.

Basavaraj:  I dont know about granularity aspect - dont know if you
need signaling.

Julien:  Dont have changes on MN - that is the end of the story.

Rajeeve:  Let us figure lower bound on the mailing list.  Regarding
what we can do with layer 2 between the MN and MAG - let us discuss on
the mailing list.  The baseline is /64 so we have a wildcard
granularity.

Zuniga:  Operator will have traffic selector and will want to send
them to the UE.

Carlos:  You must have a customer for this solution. Most likely this
will be an operator.  We have shown that basically this is seamless.
Worst case you get jitter and latency.





5)  Flow Mobility Support in PMIPv6
-----------------------------------

T.Tran (ETRI) presented another ID on flow mobility.  T. Tran stated
that there are common points and different points with the previously
presented draft.

Sri:  State diff between two drafts.

T.Tran:  First diff is donÕt require information from MN to MAG Ð no
extensions.  differentatie clearly when flow description and home
network description - pmipv6.

Sri:  can we agree that these are similar.

Carlos:  we dont require 5-tuple list Ð that is optional.
Comment:  proactive method proposed here.  We think of two cases.

Rajeev: you should read draft.  We are getting caught up in terms.
Comes back to point when protocol needs to be involved.  If it is
already , then you can call this pro-active.

Speaker:  if this is pro-active.

Rajeev:  one mag one prefix another mag you iniated mobility session.
Shared from beginning.   Initiated tghat signaling.  There is no
difference there.  No requirement for 5-tuple.  Base line is /64.

Comment:  when you update prefix on 2nd mag, I donÕt see any prefix
advertisement.  Other thing I donÕt know how these drafts will work
without specification of.  How will host need to use that..

Basavaraj:  fundamental assumption is the need for logical interface.
It is in draft.

Comment: is it tracking the interface id?
Is binding cache tracking logical or physical?

Response: logical interface id.

Comment:  both have same logical.   How will LMA use it?

Response: based on flow information.  Flow mobility.

Sri: solution is based on knowledge that the MN and LMA know exactly
how to route flow.

Basavaraj:  suggestion to move forward asking both ID authors and work
together and harmonize differences and common things.  Hopefully we
can create harmonize the document for a potential working group
document.

Basavaraj stated how quickly can come with single draft for
consideration for a working group document.


6)  PMIPv6 inter-working with WiFi Access Authentication
--------------------------------------------------------

Marco Liebsch presented draft-liebsch-netext-pmip6-authiwk-00.  Marco
noted that this is new draft. Netext is not chartered to work on it.
This is just analysis and documentation only.  Not extensions.  Marco
stated that RFC5213 assumes completed authentication procedure before
registration.  Marco noted that approach/solution is not documented in
the IETF.  Enable WLAN trusted access Ð 3GPP recommendations for
security and for PMIP operation using non-3GPP radio access.   Also,
there is the WIMAX forum specification for WiFi inter-working.  Marco
stated that the document objective is for a general BCP for AuthN
inter-working with PMIPv6.  Also, that it serves to provide advanced
documentation including other SDOÕs deployment and recommendations to
use a particular authentication method as well as includes
inter-working between WiFi AuthN and operatorÕs AAA.  Finally Marco
stated that the document will identify protocol gaps and need for IETF
specification.

Marco asked is such a document useful for the IETF and has a reasonable
scope.

Comment:  Is there any info on BBF?  I think there is some work being
done?  Not aware of any details.

Comment: recently there has been discussion in BBF in connection to
the 3gpp common architecture for fixed line access.  If the mobile
initially attached to 3gpp network or moves to hotspot, then UE is not
visible to the RG or BRASÉ this is where 3gpp and BBF to work together
so that the UE can be known to BBF access.   So wifi in that case
complicates picture.

Parviz: I agree for today that if you look at architecture that is
being discussed, wireless lan controller is not in architecture map.
Personal view wireless lan controller can be co-located.


Basavaraj:  take BBF discussion to mailing list.

Yokota-san:  interesting work.   Wifi/ap and controller mag box ---
(* combined or controller *)

Marco:  This is wireless lan specific.

Comment: is only thing you mean that if you make auth available to mag
and extract that thing that the mobile becomes ??

Comment:  Because I heard you talk about un-trusted.

Response:  Trusted relationship with the network.

Comment: today this is what happens in 3gpp - wifi is untrusted.

Parviz:  Business model can own and operate a hot spot.  It is
business question. Not IETF topic.  Want to control all the hotspots,
then this is an topic to pursue.

Sri:  if you look in wireless enterprise model, it is trusted.  If it
managed hotspot.

Basavaraj:  dont know if this debate about trusted and untrusted is
relevant to what you are trying to proposal.


Marco:  we can address this on mailing list.

Kent:  this is already commercially deployed.  The whole trusted wifi 3g.

Basavaraj:  what are we proposing to be done?

Marco:  maybe documenting for the IETF community.  We propose just to
describe for IETF.

Comment:  if you actually look at ....  goes to auth server interesting
part to combine all of them into one auth.   Speed up the process instead
of
cascading them.


Raj:  how many have read the draft?  - only 2 people.

Basavaraj:  how many people think that describing this in doc makes
sense?  6 or 7 hands.

Basavaraj: how many people see no value from this I-D?.  No one raised
hands.

Basavaraj:  Some people said yes but we wont make any decision now.
So people should read doc and we can guage interest on the mailing
list.



7)  Multi-access Indicator
--------------------------

Rajeeve Koodli presented draft-koodli-netext-multiaccess-indicator.
Rajeeve stated that it is important that when a mobile node attaches
to the mobile network using multiple access networks that the mobile
network gateway to know whether the mobile node is capable of
simultaneous multi-access.  This is important so that the mobile
network gateway can distribute the traffic flows using the appropriate
interface.   Rajeeve states that this document defines a new EAP
attribute which can be used for such an indication to the mobile
network gateway.

Rajeeve stated that the document defines a new flag for the
MIP6-Feature-Vector AVP in RFC 5447, which may need IANA assignment.
This document defines a new EAP attribute to extend the capability of
the EAP-AKA protocol.  This attribute is passed from the MN to the AAA
server.  The document doesnÕt specify any new messages or options to
the EAP-AKA protocol.

Comment:   isnt this info be available to the MAC?

Rajeev:  the attribute exchange is between mobile and AAA server.

Rajeeve: we can write a draft.  I think LMA needs to know if it is
authorized.

Jari:  I think you were extending EAP. Of course you may want to worry
about independence. Even if you have information coming from more than
one source. That is only concern I have.

Basavaraj:  LMA needs to know you have logical interface.  And in
order to provide flow mobility you need logical interface.

Rajeeve: this is only one way to do it.  Not only that the mobile has
the logical interface capability but also it is authorized.


Parviz: The RAT type can be whatever the multi-access information on
attachment is unclear. The authenticator is not the pdn-gw


Basavaraj: what does the working group think about specifying this here?
How many have read the doc? One hand.

Basavaraj:  LMA needs to know MN has logical interface - that is gap
now.  This is one way of handling the issue.

Basavaraj:  I will pose question on mailing list and give people time
to read doc and take the question on mailing list so people can make
informed decision.



8)  Scenarios of the usage of multiple home network prefixes on a
logical interface
---------------------------------------------------------------


Y-G. Hong from ETRI presented
draft-hong-netext-scenario-logical-interface-02.  Mr. Hong stated that
a logical interface is used to hide the existence and the change of
physical interface from the IP layer of a host and it also can be used
for a multiple interfaces mobile node in PMIPv6 domain.  Mr. Hong
explained that there are various usages of multiple home network
prefixes on the logical interface if a LMA assigns multiple home
network prefixes to a multiple interfaces mobile node with a logical
interface.  His document describes the usages.
Mr. Hong asked is describing various scenario of the usage of the
logical interface in PMIPv6 necessary and is there interest in working
group?

Yuri:  I think this work is related to flow mobility drafts.   So this
work is tightly coupled with that work.  So from my point of view Ð it
will be part of draft that describes flow mobility.
Telemaco:  This shouldnt be part of separate document.  If there is
something missing then put into the main document.
Basavaraj:  letÕs take a look at scenarios and how best to document
it.  We can put it in appendix of logical interface draft.  From my
perspective we can capture as part of flow mobility document.

9)  Hybrid home network prefix for multihoming in PMIPv6
--------------------------------------------------------

Y-G Hong presented 2nd draft draft-hong-netext-hybrid-hnp-03.
Mr. Hong stated that if the flow is classified by home network prefix,
to support flow mobility between different interfaces.  To enable
PMIPv6 to support both inter-technology handoff and simultaneous
access at the same time.  Goals of draft to propose a hybrid home
network prefix assignment scheme Ð 1. Separate prefix for the purpose
of inter-technology handoff and the purpose of simultaneous access;
(2) During flow mobility, some flow (prefix) is moved to another
interface and some flow (prefix) is left over.
Basavaraj:  has anybody read draft?  No one.
Basavaraj:   is going to ask for feedback on the alias for this draft.
Comment:  would this be a competing solution for what Rajeev is proposing?
Rajeeve:  I dont know.  My reading is that Home network prefix is
used for these two things - simultaneous access and for
inter-technology handoff.
Basavaraj:  read the draft and see if it is solving problems.

Wrap-up discussion of Beijing working group meeting.
Basavaraj:  Regarding next step:
- Not having enough discussion on mailing list.
- Logical interface document and flow mobility document Ð hopefully
can move forward.
- Localized routing and bulk and run-time IDs - we need to get people to
review and comment and feedback - otherwise we are not making
progress.