Subject: Re: [netext] Flow Mobility discussion - way forward?

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 01 Mar 2011 10:38:54 +0100

Hi Hesham,

On Tue, 2011-03-01 at 12:32 +1100, Hesham Soliman wrote:
> Carlos, 
> 
> >> requirement and I do not know how to build a real world system based
> >> on PMIPv6 that doesn't have them. I have two questions regarding the
> >> real world world applicability of your system that works without L2
> >> signaling:
> >> 
> >> 1) what is the trigger to the PBU if it's not the L2 signaling?
> > 
> > 2 possible options:
> > 
> > a) RS from the MN (this is documented in RFC5213, though it does not
> > work very well, as not all systems send an RS after moving).
> > 
> > b) the AP where the MN attaches to detects the attachment and triggers
> > the MAG. Note that this is not _new_ L2 signalling here, it's just
> > attachment detection based on IEEE 802.11 frames (any standard station
> > has to generate them).
> 
> => How do you identify the MN across MAGs? How does a new MAG know the MN's
> addresses? Are you transferring MAC addresses around?

We identify the MN using its MAC address.

> 
> > 
> >> 
> >> 2) How does the network decides it can offer flow mobility to a host
> >> in the absence of a layer 2 signaling from the host that indicates
> >> this host's support for flow mobility / inter-access handoffs?
> > 
> > For example, you can have that information in the profile of the user.
> 
> => Do you have a user profile transfer mechanism in your lab? If you do
> please share some high level info.

In our lab the testbed is small, so we just have a config file with the
profile.

Carlos

> Hesham

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 01 Mar 2011 23:04:46 +1100

> We identify the MN using its MAC address.

=> I consider that a reliance on L2 obviously, but how does the new MAG
recognise that this MN already has a binding? How does it get its old
address? I'm asking these questions because I don't think any serious WLAN
deployment would ever use PMIPv6. If for nothing else, PMIPv6 won't work on
shared links. 

> In our lab the testbed is small, so we just have a config file with the

=> So as both myself and Julien already said, you must be assuming a 1:1
mapping between the MN and the user. Either that or your profile is a device
profile not a user profile. The former is wrong in the real world and the
latter is not used in the real world.

Thanks,
Hesham

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 01 Mar 2011 13:12:58 +0100

Hi Hesham,

> recognise that this MN already has a binding? How does it get its old

This is a question related to the flow mobility solution itself. The
prototype I mention is plain PMIPv6. Anyway, in the solution we have in
our draft, it is the LMA that knows if the MN has already a binding, not
the MAG, and for that we could thing of feasible approaches.

> deployment would ever use PMIPv6. If for nothing else, PMIPv6 won't work on

Well, I see quite potential for PMIPv6 over WLAN, why do you think there
would not be any serious WLAN deployment with PMIPv6?

> latter is not used in the real world.

I was referring to a device profile and I don't see why this cannot be
used in the real world. My operator here in Spain knows which device I
use (even I have a flat rate that can just be used with my type of
device).

Carlos

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 01 Mar 2011 23:18:10 +1100

> would not be any serious WLAN deployment with PMIPv6?

=> Because of the nature of the links, a router doesn't always know who's
attached. As you said earlier you make the MN send an RS, which is not
required in IPv6. Also the address allocation is a mess and sharing the link
with MIPv6 nodes is very problematic. I'm not the right person to say why
PMIPv6 was created in the first place but I only see it used, if ever, on
p2p links whose use is strictly defined in SDOs. It was never intended, even
by its proponents, to do flow mobility or global mobility and it can't do
either one. 
The irony is that people wanted something that doesn't involve MN signalling
and now we'll expect signalling anyway, just not on L3. It's mind boggling.

> use (even I have a flat rate that can just be used with my type of

=> Really? And do you  call your operator if you remove your SIM card and
put it in another device?. Does you operator also know when you run new SW
on your phone/laptop? This is not a serious approach, I'm sorry but it's
completely unreliable for any serious deployment

Hesham

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Mar 2011 10:20:20 -0800

Carlos:

I've not been following this thread, pardon me for the ignorance on the
context of the thread. Clarifying question (specific to this one comment).

> As you said earlier you make the MN send an RS, which is not required in IPv6.

A mobile node, or a simple IPv6 node, on a new link does not an RS ? How
does it detect the IPv6 routers, if suppress-periodic RA is enabled ?

Sri

On 3/1/11 4:18 AM, "Hesham Soliman" <[email-masked]> wrote:

> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 01 Mar 2011 20:06:11 +0100

Hi Sri,

> does it detect the IPv6 routers, if suppress-periodic RA is enabled ?

The point is that, in my experience, if you attach a node to a WLAN
(i.e. connect to an AP), when you first bring up the interface an RS is
sent. But if later on the device changes AP, my experience with Linux is
that no more RS are generated (unless you bring down/up the interface).

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 01 Mar 2011 20:30:47 +0100

Hi Hesham,

> required in IPv6. Also the address allocation is a mess and sharing the link

PMIPv6 does not force any specific mechanism on how the MAG detects the
attachment of a MN. My experience with WLAN is quite OK so far, never
had a problem and it's quite easy to implement the AP trigger and the
ptp-to-ptp emulation on WLAN.

> by its proponents, to do flow mobility or global mobility and it can't do

I don't know the intention of the proponents of the protocol, but as
mentioned in other e-mail, I don't see any problem using it on WLAN
links. I see it working every day, and even doing flow mobility across
different technologies.

> and now we'll expect signalling anyway, just not on L3. It's mind boggling.

I don't expect signaling from the MN, that's the point. I see the value
of PMIPv6 on this absence of MN involvement and that's why we are
proposing signaling on the core (MAG-LMA) to enable flow mobility
instead of putting all the requirements on the MN (for that we already
have MIPv6).

Carlos

> completely unreliable for any serious deployment

You talking about serious approaches and operators?? from a pure-user
only perspective, I'm sorry to say that most current practices of
operators cannot be considered as "serious" :)

Carlos

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Mar 2011 11:35:44 -0800

Hi Carlos:

> that no more RS are generated (unless you bring down/up the interface).

All the stacks I've tested, any time there is a link flap, reassociation
with a new 802.11 AP, the client will send an RS. This is true for IPv4 as
well, the activation of DNAv4 procedures, ARP'ng for the DR MAC address.
IMO, the node does send an RS message.

Regards
Sri

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 01 Mar 2011 20:38:46 +0100

Hi Sri,

> IMO, the node does send an RS message.

Then you haven't tested Linux ;). With Linux (at least the flavours I've
tested) there is no such RS upon AP reassociation.

Carlos

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Mar 2011 11:46:32 -0800

Hi Carlos:

> tested) there is no such RS upon AP reassociation.

Ok. I assume, on "that" Linux stack, your mobile IP client will not work. It
will never send an RS and will never obtain a CCoA address. It will be happy
with a stale binding using a CCoA address from the prev link.

Sri

---

From: <[email-masked]>
Date: Tue, 1 Mar 2011 19:52:29 +0000

FWIW, I would remind you that we have agreed (during chartering) to not do any L3 signaling between MN-MAG.
Hence use of RS/RA is not an option here and hence do not need to spend time on that.

-Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Sri Gundavelli
Sent: Tuesday, March 01, 2011 1:36 PM
To: [email-masked]
Cc: [email-masked]; Zuniga, Juan Carlos
Subject: Re: [netext] Flow Mobility discussion - way forward?

Hi Carlos:

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Mar 2011 12:00:37 -0800

This is unrelated to the L3 interface between MAG-MN question, or about
LMA-MAG signaling. The basic node behavior, if this comment were to be true,
many apps and the basic host IP stack is broken.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2011 21:26:08 +0100

Hello Sri, netext,

Sri - I take advantage of your email to reply, but I also Cc the group.

Please excuse my ignorance of netext developments, and generally on the
PMIPv6 text.

But, even accepting that MH does send an RS upon attachment to a new
attachment to a new WiFi AP.

I would like to tell about difficult issues when trying to implement
PMIPv6 on WiFi (not me, but related).

o even though an MN does send an RS: does it contain an MN-ID?  For
   PMIPv6 to work it should contain an MN-ID otherwise MAG can't know to
   whom to allocate a prefix.  What is the RFC/draft telling how to
   encode an MN-ID into an RS and eventually RA?  I am not aware.

   Do you really _mean_ MN-ID (like a NAI) or do you silently assume
   that MN-ID could be the MAC address of MH?

o how do you make work ptp links on WiFi?  Name of open source software
   please thank you.

o what does one use in implementation to make this "prefix-per-MH"
   concept work; how does one do "point-to-point" links on WiFi in
   practice?  Is it L2TP?  Is it another?  Which document?  Don't say it
   is out of scope - it is fully in scope if one wants to do PMIPv6
   with WiFi - without this PMIPv6/WiFi can't work.

o how does one do several prefixes on a single WiFi link?  What
   draft/RFC tells how to do it?  Typically a WiFi link has a single
   prefix, or maybe a few; how does one make sure that each different
   prefix (HNP) sent on a single WiFi link is never advertised to
   everyone else, but only to a single MH? (make sure dst address is
   unicast, not multicast).

o is there an radvd implementation doing this per-MN prefix
   advertisement?

o radvd on linux is driven by a config file, and there is difficulty in
   updating that file dynamically and re-start radvd daemon.  Anybody
   did that already?  Where?  radvd software is GPL - so any
   modifications to do this behaviour should be available - whom should
   I ask?

o are implementers of PMIPv6/WiFi use something else than radvd to send
   RAs from MAG?  What software please?

o when supposedly the MAG does advertise a number of independent
   "per-MH" HNPs, does is still advertise a non-HNP prefix valid for
   every other MH which does not assume PMIPv6 is working (a "natural"
   prefix if I can say so)?  What does this prefix look like?

o does a MAG receiving 2 MHs coming from 2 different other MAG's assign
   2 link local addresses on its WiFi interface (the next-hop for
   default route)?

These are doubts only about MAG-MH interface.  But there are a number of
doubts about how the LMA assigns the prefix to MHas well.  I assume this
is not performed with DHCP - then how is it performed?  The PMIPv6
specification is silent about this (lifetimes?  confirmations?).  It is
very little tempting to start writing a new implementation of prefix
allocation, especially when knowing DHCPv6 implementations include
prefix allocation, all readily available.

My current state of thinking is that PMIPv6 is written for 3GPP and has
not been experimented on WiFi beyond proof of concept.  I mean - all my
respect to statements of implementations of PMIPv6 on WiFi, but,
however, when compared to MIPv6 implementations, these are much less
working on WiFi.  For example, MIPv6 implementation work with
out-of-the-box radvd, and out-of-the-box dhcp3.  But PMIPv6
implementations on WiFi can only work according to non-specified and
behaviour which is claimed out of scope in PMIPv6 specs.

Finally, I may be not updated with draft/RFC developments of PMIPv6,
excuses.

Alex

Le 01/03/2011 19:20, Sri Gundavelli a écrit :
> Carlos:
>
> I've not been following this thread, pardon me for the ignorance on
> the context of the thread. Clarifying question (specific to this one
>  comment).
>
>
> A mobile node, or a simple IPv6 node, on a new link does not an RS ?
>  How does it detect the IPv6 routers, if suppress-periodic RA is
> enabled ?
>
>
> Sri
>
>
>
>
>
> On 3/1/11 4:18 AM, "Hesham Soliman"<[email-masked]> wrote:
>
>>
>>>
>>> Well, I see quite potential for PMIPv6 over WLAN, why do you
>>> think there would not be any serious WLAN deployment with
>>> PMIPv6?
>>
>> =>  Because of the nature of the links, a router doesn't always
>> know who's attached. As you said earlier you make the MN send an
>> RS, which is not required in IPv6. Also the address allocation is a
>> mess and sharing the link with MIPv6 nodes is very problematic. I'm
>> not the right person to say why PMIPv6 was created in the first
>> place but I only see it used, if ever, on p2p links whose use is
>> strictly defined in SDOs. It was never intended, even by its
>> proponents, to do flow mobility or global mobility and it can't do
>> either one. The irony is that people wanted something that doesn't
>> involve MN signalling and now we'll expect signalling anyway, just
>> not on L3. It's mind boggling.
>>
>>>
>>>> shared links.
>>>>
>>>>>> =>  Do you have a user profile transfer mechanism in your
>>>>>> lab? If you do please share some high level info.
>>>>>
>>>>> In our lab the testbed is small, so we just have a config
>>>>> file with the profile.
>>>>
>>>> =>  So as both myself and Julien already said, you must be
>>>> assuming a 1:1 mapping between the MN and the user. Either that
>>>> or your profile is a device profile not a user profile. The
>>>> former is wrong in the real world and the latter is not used in
>>>> the real world.
>>>
>>> I was referring to a device profile and I don't see why this
>>> cannot be used in the real world. My operator here in Spain knows
>>> which device I use (even I have a flat rate that can just be used
>>> with my type of device).
>>
>> =>  Really? And do you  call your operator if you remove your SIM
>> card and put it in another device?. Does you operator also know
>> when you run new SW on your phone/laptop? This is not a serious
>> approach, I'm sorry but it's completely unreliable for any serious
>>  deployment
>>
>> Hesham
>>
>>>
>>> Carlos
>>>
>>>>
>>>> Thanks, Hesham
>>>>
>>>>
>>>>>
>>>>> Carlos
>>>>>
>>>>>>
>>>>>> Hesham
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>> _______________________________________________ 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, 01 Mar 2011 12:48:35 -0800

Hi Alex,

Thanks for your note and for your agreement on the host having to send RS
after reattach.

Few points without going into details as we have related products in this
space. 

- There is access authentication on 802.11 link, where there is a mapping
between a link-layer address and a mobile identity.

- MN-ID need not be a MAC address

- There is the ability to segregate shared links as p2p links, there are
semantics

- There are semantics to sends unicast RA's. There is this RFC-6085.
 
- RADVD is a specific implementation, I'm not sure I can comment in that
tool context. But, we can stay with the standard IP host behavior for this
discussion, as that is what we need, except for inter-tech handovers where
we need logical interface construct

- How the LMA allocates prefixes for a mobility session is out of scope. It
can very well use local pools, depend on AAA, or use DHCP PD. Some folks
have attempted to specific this LMA-DHCP interface. It should be good to
have such details specified

- The comment on link-local address is valid and as we have seen early
proposals to avoid that remote conflicts

- MAG can certainly advertise local prefixes which have no mobility. But, we
will be hit with the issue of lack of SAS ability. So, lets assume the MAG
advertises the prefixes on a per-MN basis, just that prefixes it gets from
the LMA for that session.

- The implementors of PMIPv6 I know, use Cisco IOS, Linux and number of
platforms that we have obviously.

- We have tried PMIPv6 beyond 3GPP and we have understanding how this works.
There are other folks like Juan Carlos, Carlos, Telemaco, who have even
implementations of some of advanced features working. I will surely try to
provide you some working images on some platforms that you can play with. I
will try to get you that.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2011 21:50:34 +0100

Hi Raj,

Please allow to give an oppinion on this.

I agree we should leave the Host unmodified.  But in more detail: what
do you mean we should not spend time on signalling MH-MAG?  (you say MN,
and I suppose MH, because MR-MAG doesn't work with PMIPv6, and MN can be
an MR; also this MH is not assumed Mobile IPv6, so it could as well be
an H actually - making it a 'H-MAG' interface).

To me that signalling is of paramount importance for PMIPv6/WiFi to
work.  YEs, the MH should send the typical RS it sends, unmodified, and
MAG should adapt to it.  In this sense, only the MH is out of scope, but
MAG is modified and its modifications are in scope.

I do think we need to spend time telling (at least on the mailing list,
or for an implementer clarification) how does the MH tell the MAG its
MN-ID when that happens on WiFi (not on cellular).

I take advantage of this remark to tell that this is true for a number
of other aspects in the PMIPv6 RFC.  A number of such aspects
('stateful', 'policy') are currently said to be out of scope in the
PMIPv6 spec.

This is strange!

A spec would leave aspects as 'out-of-scope' when non-interoperable
implementations of it are ok.  I.e., it would be ok to have local
proprietary implementations of 'policy server'.  But when the inherent
working of PMIPv6 is at stake then that can't be left out of scope.

I may be not updated about PMIPv6 documents, excuses, but this MN-ID
between MH and MAG question is very much in-scope IMHO.

Yours,

Alex

Le 01/03/2011 20:52, [email-masked] a écrit :
>
> FWIW, I would remind you that we have agreed (during chartering) to
> not do any L3 signaling between MN-MAG. Hence use of RS/RA is not an
>  option here and hence do not need to spend time on that.
>
> -Raj
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of ext Sri Gundavelli
> Sent: Tuesday, March 01, 2011 1:36 PM To: [email-masked] Cc:
> [email-masked]; Zuniga, Juan Carlos Subject: Re: [netext] Flow
> Mobility discussion - way forward?
>
> Hi Carlos:
>
>
>
>
> On 3/1/11 11:06 AM, "Carlos Jesús Bernardos Cano"<[email-masked]>
> wrote:
>
>> Hi Sri,
>>
>>> I've not been following this thread, pardon me for the ignorance
>>>  on the context of the thread. Clarifying question (specific to
>>> this one comment).
>>>
>>>
>>> A mobile node, or a simple IPv6 node, on a new link does not an
>>> RS ? How does it detect the IPv6 routers, if suppress-periodic RA
>>> is enabled ?
>>>
>>
>> The point is that, in my experience, if you attach a node to a
>> WLAN (i.e. connect to an AP), when you first bring up the interface
>> an RS is sent. But if later on the device changes AP, my experience
>>  with Linux is that no more RS are generated (unless you bring
>> down/up the interface).
>>
>
> All the stacks I've tested, any time there is a link flap,
> reassociation with a new 802.11 AP, the client will send an RS. This
>  is true for IPv4 as well, the activation of DNAv4 procedures, ARP'ng
>  for the DR MAC address. IMO, the node does send an RS message.
>
>
>
> Regards Sri
>
>
>
>
>
>> Thanks,
>>
>> Carlos
>>
>>>
>>> Sri
>>>
>>>
>>>
>>>
>>>
>>>> know who's attached. As you said earlier you make the MN send
>>>> an RS, which is not required in IPv6. Also the address
>>>> allocation is a mess and sharing the link with MIPv6 nodes is
>>>> very problematic. I'm not the right person to say why PMIPv6
>>>> was created in the first place but I only see it used, if ever,
>>>> on p2p links whose use is strictly defined in SDOs. It was
>>>> never intended, even by its proponents, to do flow mobility or
>>>> global mobility and it can't do either one. The irony is that
>>>> people wanted something that doesn't involve MN signalling and
>>>> now we'll expect signalling anyway, just not on L3. It's mind
>>>> boggling.
>>>>
>>>>>
>>>>>> shared links.
>>>>>>
>>>>>>>> =>  Do you have a user profile transfer mechanism in
>>>>>>>> your lab? If you do please share some high level info.
>>>>>>>
>>>>>>  assuming a 1:1 mapping between the MN and the user. Either
>>>>>>  that or your profile is a device profile not a user
>>>>>> profile. The former is wrong in the real world and the
>>>>>  cannot be used in the real world. My operator here in Spain
>>>>>  knows which device I use (even I have a flat rate that can
>>>>> just be used with my type of device).
>>>>
>>>> =>  Really? And do you  call your operator if you remove your
>>>> SIM card and put it in another device?. Does you operator also
>>>>  know when you run new SW on your phone/laptop? This is not a
>>>> serious approach, I'm sorry but it's completely unreliable for
>>>>  any serious deployment
>>>>
>>>> Hesham
>>>>
>>>>>
>>>>> Carlos
>>>>>
>>>>>>
>>>>>> Thanks, Hesham
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Carlos
>>>>>>>
>>>>>>>>
>>>>>>>> Hesham
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>  list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2011 22:03:13 +0100

Le 01/03/2011 20:38, Carlos Jesús Bernardos Cano a écrit :
>>>> I've not been following this thread, pardon me for the
>>>> ignorance on the context of the thread. Clarifying question
>>>> (specific to this one comment).
>>>>
>>>>
>>>> RS ? How does it detect the IPv6 routers, if suppress-periodic
>>>> RA is enabled ?
>>>>
>>>
>>> WLAN (i.e. connect to an AP), when you first bring up the
>>> interface an RS is sent. But if later on the device changes AP,
>>> my experience with Linux is that no more RS are generated (unless
>>> you bring down/up the interface).
>>>
>>
>> reassociation with a new 802.11 AP, the client will send an RS.
>> This is true for IPv4 as well, the activation of DNAv4 procedures,
>>  ARP'ng for the DR MAC address. IMO, the node does send an RS
>> message.
>
> Then you haven't tested Linux ;). With Linux (at least the flavours
> I've tested) there is no such RS upon AP reassociation.

I agree.

On some linux implementations of WiFi driver the RS doesn't happen,
especially when the ESSID is the same as on the previous AP, and the two
coverages overlap (typical for hotspot deployments).

The RS does happen when putting interface down/up, and that does happen
when new association (i.e. previous iwconfig listed less lines than
current).

This behaviour is so since a number of years.  To circumvent it I think
there is a flag somewhere in /proc/sys, or a sequence ifconfig down/up
which forces sending an RS.  This method is good when experimenting -
implementer can trigger sending an RS.  There may even exist some
distribution-specific linux software in the userspace ("Connection
Manager"(?) on Ubuntu is the latest I tried) which does provoke sending
an RS when the user manually selects an ESSID to connect to, IIRC.

But this is different from deployment, because at deployment time no new
software trigger should be added: use a Host out of the box.  Use only
its kernel stack - that is the only vanilla stuff we can assume on an
unmodified Host (non-modified Host). (I mean the assumption here, in
this group).

Alex

>>>>>> Well, I see quite potential for PMIPv6 over WLAN, why do
>>>>>> you think there would not be any serious WLAN deployment
>>>>>> with PMIPv6?
>>>>>
>>>>> =>  Because of the nature of the links, a router doesn't
>>>>> always know who's attached. As you said earlier you make the
>>>>>  MN send an RS, which is not required in IPv6. Also the
>>>>> address allocation is a mess and sharing the link with MIPv6
>>>>>  nodes is very problematic. I'm not the right person to say
>>>>> why PMIPv6 was created in the first place but I only see it
>>>>> used, if ever, on p2p links whose use is strictly defined in
>>>>>  SDOs. It was never intended, even by its proponents, to do
>>>>> flow mobility or global mobility and it can't do either one.
>>>>> The irony is that people wanted something that doesn't
>>>>> involve MN signalling and now we'll expect signalling anyway,
>>>>> just not on L3. It's mind boggling.
>>>>>
>>>>>>
>>>>>>> shared links.
>>>>>>>
>>>>>>>> In our lab the testbed is small, so we just have a
>>>>>>>> config file with the profile.
>>>>>>>
>>>>>>> =>  So as both myself and Julien already said, you must
>>>>>>> be assuming a 1:1 mapping between the MN and the user.
>>>>>>> Either that or your profile is a device profile not a
>>>>>>> user profile. The former is wrong in the real world and
>>>>>>> the latter is not used in the real world.
>>>>>>
>>>>>> I was referring to a device profile and I don't see why
>>>>>> this cannot be used in the real world. My operator here in
>>>>>>  Spain knows which device I use (even I have a flat rate
>>>>>> that can just be used with my type of device).
>>>>>
>>>>> SIM card and put it in another device?. Does you operator
>>>>> also know when you run new SW on your phone/laptop? This is
>>>>> not a serious approach, I'm sorry but it's completely
>>>>> unreliable for any serious deployment
>>>>>
>>>>> Hesham
>>>>>
>>>>>>
>>>>>> Carlos
>>>>>>
>>>>>>>
>>>>>>> Thanks, Hesham
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Carlos
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hesham
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ netext
>>>>> mailing list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2011 22:26:29 +0100

Le 01/03/2011 21:48, Sri Gundavelli a écrit :
> Hi Alex,
>
> Thanks for your note and for your agreement on the host having to
> send RS after reattach.
>
> Few points without going into details as we have related products in
> this space.
>
> - There is access authentication on 802.11 link, where there is a
> mapping between a link-layer address and a mobile identity.

Specific authentication method and software name please, so I can try
here in my lab the same so I don't grow white hairs wondering how others
do it.

It will be very good for me to learn whether PMIPv6 on WiFi absolutely
needs this mapping MAC address - mobile identity, you mention above.  I
currently suppose that PMIPv6 can't work without this mapping.  (a
mapping which is not documented BTW).

> - MN-ID need not be a MAC address

Must one insert MN-ID in RA or RS?  Or are we free to not do it?

> - There is the ability to segregate shared links as p2p links, there
> are semantics

Software name please?  RFC/draft name please?

> - There are semantics to sends unicast RA's. There is this RFC-6085.

Is it implemented on linux?  How should I configure it?

Or is it a Cisco-only thing (judging by authorship)? (I do appreciate
and sometimes even buy Cisco).

> - RADVD is a specific implementation, I'm not sure I can comment in
> that tool context.

Yes, radvd is specific implementation.  I can comment on it, if needed.

> But, we can stay with the standard IP host behavior for this
> discussion, as that is what we need, except for inter-tech handovers
> where we need logical interface construct.

Yes, but we don't understand the same thing by IP host standard
behavior.  One of the divergences is on the use of RAs.

Or we can't say PMIPv6 works with all IPv6 "standard" Hosts if we don't
understand the same thing by standard.

> - How the LMA allocates prefixes for a mobility session is out of
> scope.

No no, it is fully in scope.

> It can very well use local pools, depend on AAA, or use DHCP PD.

Even the simple concept of local pools is not that easy to implement.

I can tell that DHCP PD is not as simple as you seem to assume it.
BAsically it is next to impossible for LMA to act on behalf of the Host,
without modifications to DHCP specs and implementation.

AAA is a huge concept.  If I only knew which part of AAA software to
install and try with PMIPv6 to avoid coding local pool.  Which one?

> Some folks have attempted to specific this LMA-DHCP interface. It
> should be good to have such details specified.

Well yes, I think without such kind of LMA-DHCP interface, PMIP can't
work for a H on WiFi.

> - The comment on link-local address is valid and as we have seen
> early proposals to avoid that remote conflicts
>
> - MAG can certainly advertise local prefixes which have no mobility.
> But, we will be hit with the issue of lack of SAS ability. So, lets
> assume the MAG advertises the prefixes on a per-MN basis, just that
> prefixes it gets from the LMA for that session.

Assume yes, but implement how?

> - The implementors of PMIPv6 I know, use Cisco IOS, Linux and number
> of platforms that we have obviously.

Well please direct them to the list to answer this: is their PMIPv6 used
without link-specific authentication (without EAP, without PEAP, without
WPA)?

> - We have tried PMIPv6 beyond 3GPP and we have understanding how
> this works. There are other folks like Juan Carlos, Carlos, Telemaco,
> who have even implementations of some of advanced features working.
> I will surely try to provide you some working images on some
> platforms that you can play with. I will try to get you that.

Thanks for the offer, appreciated.  That can be useful.

But I am currently looking at linux implementations.  When that is
done, I will 'promote' one to the core made of Cisco routers, later.
But currently I consider PMIPv6 on linux for WiFi.

Alex

>
>
> Sri
>
>
>
>
> On 3/1/11 12:26 PM, "Alexandru
> Petrescu"<[email-masked]> wrote:
>
>> Hello Sri, netext,
>>
>> Please excuse my ignorance of netext developments, and generally
>> on the PMIPv6 text.
>>
>> But, even accepting that MH does send an RS upon attachment to a
>> new attachment to a new WiFi AP.
>>
>> I would like to tell about difficult issues when trying to
>> implement PMIPv6 on WiFi (not me, but related).
>>
>>  PMIPv6 to work it should contain an MN-ID otherwise MAG can't know
>>  to whom to allocate a prefix.  What is the RFC/draft telling how
>> to encode an MN-ID into an RS and eventually RA?  I am not aware.
>>
>> o how do you make work ptp links on WiFi?  Name of open source
>> software please thank you.
>>
>> practice?  Is it L2TP?  Is it another?  Which document?  Don't say
>> it is out of scope - it is fully in scope if one wants to do PMIPv6
>> o radvd on linux is driven by a config file, and there is
>> difficulty in updating that file dynamically and re-start radvd
>> daemon.  Anybody did that already?  Where?  radvd software is GPL
>> - so any modifications to do this behaviour should be available -
>> whom should I ask?
>>
>> o are implementers of PMIPv6/WiFi use something else than radvd to
>> send RAs from MAG?  What software please?
>>
>> o does a MAG receiving 2 MHs coming from 2 different other MAG's
>> assign 2 link local addresses on its WiFi interface (the next-hop
>> for default route)?
>>
>> These are doubts only about MAG-MH interface.  But there are a
>> number of doubts about how the LMA assigns the prefix to MHas
>> well. I assume this is not performed with DHCP - then how is it
>> performed?  The PMIPv6 specification is silent about this
>> (lifetimes?  confirmations?).  It is very little tempting to start
>> writing a new implementation of prefix allocation, especially when
>> knowing DHCPv6 implementations include prefix allocation, all
>> readily available.
>>
>> My current state of thinking is that PMIPv6 is written for 3GPP
>> and has not been experimented on WiFi beyond proof of concept.  I
>> mean - all my respect to statements of implementations of PMIPv6
>> on WiFi, but, however, when compared to MIPv6 implementations,
>> these are much less working on WiFi.  For example, MIPv6
>> implementation work with out-of-the-box radvd, and out-of-the-box
>> dhcp3.  But PMIPv6 implementations on WiFi can only work according
>> to non-specified and behaviour which is claimed out of scope in
>> PMIPv6 specs.
>>
>> Finally, I may be not updated with draft/RFC developments of
>> PMIPv6, excuses.
>>
>> Alex
>>
>>>> MN send an RS, which is not required in IPv6. Also the address
>>>> was created in the first place but I only see it used, if
>>>> ever, on p2p links whose use is strictly defined in SDOs. It
>>>> was never intended, even by its proponents, to do flow mobility
>>>> or global mobility and it can't do either one. The irony is
>>>> that people wanted something that doesn't involve MN signalling

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 02 Mar 2011 10:46:08 +1100

> ptp-to-ptp emulation on WLAN.

=> Quiet easy? I think you must have a special WLAN in your lab :)
I don't think so, if you think it's easy I think you've missed a lot of
issues. See my points above and please respond specifically.

> links. I see it working every day, and even doing flow mobility across

=>I notice that you're giving generic responses. You're not addressing
specific issues above.

> instead of putting all the requirements on the MN (for that we already

=> If you think you can do flow mobility without MN involvement then good
luck with that. I'm starting to think that people on this list are in denial
and it doesn't matter how many arguments are not being responded to,
everyone comes back and says "it's doable". I think we're going to have to
leave this to the AD's because we're not making any progress.

> operators cannot be considered as "serious" :)

=> Again, you're backing out of your points mentioned earlier :) Please
respond to how you will make it work.

Hesham

---

From: <[email-masked]>
Date: Wed, 2 Mar 2011 02:08:31 +0000

Hi Alex,

Comments inline:

-----Original Message-----
From: ext Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, March 01, 2011 2:51 PM
To: Patil Basavaraj (Nokia-MS/Dallas)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netext] Flow Mobility discussion - way forward?

Hi Raj,

Raj> Good. We are in agreement that the protocol ought to work with no expectations of host modifications.

Raj> In the context of the flow mobility discussion, that RS (as it exists today) will not be of much help even if it is only the MAG that is being modified. 

Raj> Potentially via L2 means. But if your question is if this is or can be done at L3, then no. 

Raj> It's a bit late to start asking questions about the basic PMIP6 RFC (5213). You may want to refer to the Netlmm archives.

This is strange!

Raj> Would advise you to go revisit Netlmm discussion archives. 

Raj> I don't believe that to be the case in the context of flow mobility for PMIP6. At least not in terms of how flow mobility for PMIP6 is envisioned.

-Raj

Yours,

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Mar 2011 12:34:27 +0100

Hi Sri,

> with a stale binding using a CCoA address from the prev link.

I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in that
Linux stack, don't worry, the MIPv6 client takes care of configuring a
CoA (sending an RS if no RA is received).

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Mar 2011 12:35:57 +0100

Hi Sri,

> many apps and the basic host IP stack is broken.

Well, I'd not sya the basic host IP stack is broken. The behaviour I've
noticed with Linux is not the one I like the most, but I'd not call it
broken.

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Mar 2011 12:43:42 +0100

> issues. See my points above and please respond specifically.

- MN attachment detection: software on the AP that monitors the
association table (most drivers provide that feature).

- Point-to-point emulation: MAG send the RA to the unicast link-local
address of the MN or it sends it multicast in IPv6 but addressed to the
L2 address of the MN only.

- We use L2 address as MN-ID (just for the sake of simplicity)

What else do we need? with that I have legacy IPv6 clients (no
modification at all) roaming happily between MAGs :)

> leave this to the AD's because we're not making any progress.

Well, I've seen prototypes of flow mobility working, with the only
artifact of the logical interface (or the weak host model) in the
terminal. So I say "it's doable" because I've done it or I've seen it
done.

> respond to how you will make it work.

We have a draft summarizing how solutions that I've seen working
operate.

Carlos

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 03 Mar 2011 01:28:29 +1100

> association table (most drivers provide that feature).

=> How does the AP tell the MAG that a new host has attached? Is this
documented in a standard somewhere? If there is a specific L2 mechanism for
this then I guess you are relying on L2-specific hints, but I'm curious to
know what they are.

> - We use L2 address as MN-ID (just for the sake of simplicity)

=> Are you expecting the host (we're not talking about MNs obviously) to
send that MN-ID in a ND packet? I assume you're not.

> terminal. So I say "it's doable" because I've done it or I've seen it

=> Of course it's doable in a prototype. We're talking about deploying it in
a real fault tolerant system though, it's a different story.

> We have a draft summarizing how solutions that I've seen working

=> ok, I hope you answer the fundament questions about knowing the link
state and the interface availability, congestion ...etc in that draft.
Because they're the things that you don't know without checking with the
host and you need them to do flow mobility.

Hesham

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Mar 2011 16:55:52 +0100

Hi Hesham,

> this then I guess you are relying on L2-specific hints, but I'm curious to

The AP detects that a host has attached looking at its association
table. If the AP is collocated with the MAG, the AP can just use local
communication to inform the MAG. If they are different boxes, you can
use whatever kind of signaling channel between the AP and the MAG (in
our prototype we just use UDP messages). This is compliant with RFC5213,
with does not enforce any particular mechanism to detect MN attachment.

> send that MN-ID in a ND packet? I assume you're not.

No. In our scenario, the L2 address of the node appears in the
association table of the AP and we use it as MN-ID. Alternatively, we
could have a table mapping L2 addresses with MN-IDs or other possible
approaches.

> a real fault tolerant system though, it's a different story.

Well, I just wanted to make the point that we talk about things that are
working fine without many implementation effort and that we think can
work properly in a real system without major efforts.

> host and you need them to do flow mobility.

Of course there are many things that could be enhanced and adjusted
based on the system where the solution is implemented. Most of them can
be left up to the particular system (just as RFC5213 does for many key
functions), as long as we come up with a solution that is interoperable
and that do not pose strong requirements (such as particular L2
signaling) on the MN.

Carlos

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Mar 2011 08:16:29 -0800

Hi Carlos:

(Still keeping the discussion context to this one comment).

- I assume MIPv6 stack is on top of IP stack, not the other way around

- If IP stack does not detect movement detection across L3 links (in the
absence of any other hints about same L3 link, in the forms essid or other
hints), how does the MIPv6 stack which is relying on the stack/kernel
events, decide to force an RA ? What is the hint ? How come ND/DHCP does not
realize the same need to send an RS ? Is MIPv6 stack so smart ?

- Assuming there is no MIPv6 stack on the host, an host moves across access
links, it will never do an RS and will keep using the address from the
previous link. So, the basic IPv6 connectivity is broken. This is a bug, not
a protocol gap.

PS: I heard about this RS problems 5 years back, when most WLAN drivers were
not handling IPv6 correctly. I'm pretty sure all the WLAN drivers have fixed
those problems now. You may want to replace your buggy NIC card driver :)

Regards
Sri

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Mar 2011 17:49:26 +0100

Hi Sri,

> - I assume MIPv6 stack is on top of IP stack, not the other way around

Well, i reality MIPv6 is part of IPv6, not really sits on top.

> realize the same need to send an RS ? Is MIPv6 stack so smart ?

The implementations that I'm familiar with do the following:

- They wait for an unsolicited RA
- If no unsolicited RA is received in a time interval equal to 2 times
the frequency of RAs (there is information about that on the RAs), the
MN sends an RS.

> previous link. So, the basic IPv6 connectivity is broken. This is a bug, not

With WLAN and Linux, that's the behavior. I guess developers understood
that two APs with the same ESSID belongs to the same ESS, and therefore
the same IP subnet. That actually is correct and cannot be cataloged as
"bug".

> those problems now. You may want to replace your buggy NIC card driver :)

It's not a buggy NIC card driver. You may say a buggy OS, but I honestly
will not call Linux "buggy" (or at least buggier than many others that
are out there).

Carlos

---

From: <[email-masked]>
Date: Wed, 2 Mar 2011 16:53:26 +0000

Folks,

Is this discussion about how MIP6 works even relevant in the context of the flow mobility discussion?
There are other questions and concerns that have been raised which I would advise the authors to focus on.

If you need to understand how movement detection in MIP6 works, please refer to Sec 11.5 of RFC3775. 

-Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Carlos Jesús Bernardos Cano
Sent: Wednesday, March 02, 2011 10:49 AM
To: Sri Gundavelli
Cc: [email-masked]; Zuniga, Juan Carlos
Subject: Re: [netext] Flow Mobility discussion - way forward?

Hi Sri,

On Wed, 2011-03-02 at 08:16 -0800, Sri Gundavelli wrote:
> > I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in 
> > that Linux stack, don't worry, the MIPv6 client takes care of 
> > configuring a CoA (sending an RS if no RA is received).
> > 
> 
> Hi Carlos:
> 

> 
> - If IP stack does not detect movement detection across L3 links (in 
> the absence of any other hints about same L3 link, in the forms essid 
> or other hints), how does the MIPv6 stack which is relying on the 
> stack/kernel events, decide to force an RA ? What is the hint ? How 
> come ND/DHCP does not realize the same need to send an RS ? Is MIPv6 stack so smart ?

- They wait for an unsolicited RA
- If no unsolicited RA is received in a time interval equal to 2 times the frequency of RAs (there is information about that on the RAs), the MN sends an RS.

> 
> - Assuming there is no MIPv6 stack on the host, an host moves across 
> access links, it will never do an RS and will keep using the address 
> from the previous link. So, the basic IPv6 connectivity is broken. 
> This is a bug, not a protocol gap.

With WLAN and Linux, that's the behavior. I guess developers understood that two APs with the same ESSID belongs to the same ESS, and therefore the same IP subnet. That actually is correct and cannot be cataloged as "bug".

> 
> PS: I heard about this RS problems 5 years back, when most WLAN 
> drivers were not handling IPv6 correctly. I'm pretty sure all the WLAN 
> drivers have fixed those problems now. You may want to replace your 
> buggy NIC card driver :)

It's not a buggy NIC card driver. You may say a buggy OS, but I honestly will not call Linux "buggy" (or at least buggier than many others that are out there).

Carlos

> > I'm talking about a legacu IPv6 host. If I install Mobile IPv6 in 
> > that Linux stack, don't worry, the MIPv6 client takes care of 
> > configuring a CoA (sending an RS if no RA is received).
> > 
> > Carlos
> > 
> >
>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Mar 2011 09:13:36 -0800

Yes, it is relevant in the context of the current discussion. If we are not
on the same page, as how a simple IP host behaves across L3 roams, we are
not going to converge on what new events L2 or L3 we need. So, this is
relevant.

Thanks
Sri

On 3/2/11 8:53 AM, "[email-masked]" <[email-masked]>
wrote:

> - If no unsolicited RA is received in a time interval equal to 2 times the
> frequency of RAs (there is information about that on the RAs), the MN sends an
> RS.
> 
>> 
> With WLAN and Linux, that's the behavior. I guess developers understood that
> two APs with the same ESSID belongs to the same ESS, and therefore the same IP
> subnet. That actually is correct and cannot be cataloged as "bug".
> 
>> 
> It's not a buggy NIC card driver. You may say a buggy OS, but I honestly will
> not call Linux "buggy" (or at least buggier than many others that are out
> there).
> 
> Carlos
> 
>> 
>> 
>> 
>> Regards
>> Sri
>> 
>> 
>>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 03 Mar 2011 16:08:28 +1100

> with does not enforce any particular mechanism to detect MN attachment.

=> Ok since that protocol doesn't exist today, you basically require
colocation of the AP with the MAG.

> work properly in a real system without major efforts.

=> I think "working fine" is a subjective description. You can make enough
assumptions in a lab to make anything work. The point is, as myself and
Julien mentioned several times, you can't assume a 1:1 mapping of
user:device. It's a fact in today's world.

> based on the system where the solution is implemented.

=> It's a fundamental assumption though! The only entity that knows if it's
interface is up or down in a WLAN is the host. What can you do about that?
Unless you define a new WLAN standard you're out of luck. The only entity
that knows its apps is the end host. How can you change that? I'm not
talking about well known ports, it's a generic assumption.
Also, the only entity that knows what it's "about to do" is the end host.
Nothing to change here either.

  Most of them can
> and that do not pose strong requirements (such as particular L2

=> Then do that first before you suggest building something on a foundation
that doesn't exist. Shouldn't you have a foundation before you build?

Hesham

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 03 Mar 2011 11:07:44 +0100

Hi Hesham,

> colocation of the AP with the MAG.

Nope, you can use your own implementation of that mechanism if required.

> user:device. It's a fact in today's world.

You can have 1:n mappings as well.

> Nothing to change here either.

That's a mobile-centric view, which is not quite aligned with a
network-based mobility protocol.

> that doesn't exist. Shouldn't you have a foundation before you build?

Again, I have seen built systems working based on the same principles
that we have been discussed here.

Carlos

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 03 Mar 2011 22:41:17 +1100

> You can have 1:n mappings as well.

=> No you can't. You're assuming the device capability is in the profile.
We've gone over this already...

> network-based mobility protocol.

=> It's aligned with the Internet as it is today....

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Mar 2011 10:40:56 -0800

Sri,

Whether or not a host stack send an RS when a link-up event happens is
irrelevant to the design of the PMIPv6 flow mobility for the two
following reasons:

1. Stacks with DNAv6 would send an RS, other stack would not. So it's
not generic and can't be relied upon.
2. Even if all stacks were sending RS. RS can be lost. So it's not
reliable and can' t be relied upon.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Mar 2011 10:49:46 -0800

Hi Carlos,

> association table (most drivers provide that feature).

Ok.

> L2 address of the MN only.

PMIPv6 assumes a point-to-point *link*. You are talking about
unicasting RAs which implements a subnet in which only one MN stands.
This doesn't give you a point-to-point link. Since we do not change
the L3 between MN and MAG, a point-to-point link has to be provided at
L2. How do you do that?

> - We use L2 address as MN-ID (just for the sake of simplicity)

If you use IEEE EUI-48 as MN-ID, how do you do flow mobility to a
system that isn't 802 (e.g. 3GPP)?

If you do not use IEEE EUI-48 as MN-ID, where do you get the MN-ID from?

> modification at all) roaming happily between MAGs :)

See above...

> terminal. So I say "it's doable" because I've done it or I've seen it

You can't assume weak host model. Remember the IP layer is unmodified.

You can assume logical interface, but it has loads of unresolved
issues that need to be taken care of, as per my comments during the
meetings. I haven' t seen those resolved yet, so I do not know how
doable or not it is.

> We have a draft summarizing how solutions that I've seen working

We still have unanswered questions left on the table. The drafts on
the table do not answer those.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Mar 2011 14:43:47 -0800

Julien:

RS message can get lost and in sequence, sure, like any other IP packet. So,
the host using stateless autoconf can never configure an IPv6 address, till
it receives a router advertisement message. So, enabling RA suppress is not
desirable. It is also unreliable for any IP host on a normal IPv6 link to
obtain prefix information, given the probability that RS/RA messages can get
lost. I agree, its the same level of unreliability exists in case of PMIPv6,
which is one of the triggers for the protocol operation, not just for flow
mobility.

Regards
Sri

On 3/3/11 10:40 AM, "Julien Laganier" <[email-masked]> wrote:

>>>> come ND/DHCP does not realize the same need to send an RS ? Is MIPv6 stack
>>>> so
>>>> smart ?
>>> 
>>> will

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Mar 2011 14:59:17 -0800

Sri,

In the ND case, when RS are lost, an IPv6 host will eventually obtain
prefix information via receiving a periodic RA, configure an address
with SLAAC, and be connected to the Internet.

In contrast, in the PMIPv6 case, relying on RS as a mobility trigger
can lead to a failure mode in which the host is never detected by the
PMIPv6 fabric and has no connectivity to the Internet.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Mar 2011 15:12:10 -0800

Julien,

Sure, assuming the router is not provisioned to suppress periodic RA's and
based on the RA frequency, an IPv6 host will eventually obtain an address.
In case of PMIPv6, the same periodic RA with no PIO's will enable the host
to retrigger the RS for PIO's and allow the router to discover the host and
present its PIO's.

Sri

On 3/3/11 2:59 PM, "Julien Laganier" <[email-masked]> wrote:

>>>>> Is this discussion about how MIP6 works even relevant in the context of
>>>>> the
>>>>> flow mobility discussion?
>>>>> If you need to understand how movement detection in MIP6 works, please
>>>>> refer
>>>>> to Sec 11.5 of RFC3775.
>>>>> 
>>>>> -Raj
>>>>> 
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>> Of
>>>>> ext Carlos Jesús Bernardos Cano
>>>>> frequency of RAs (there is information about that on the RAs), the MN
>>>>> sends
>>>>> an
>>>>> RS.
>>>>> 
>>>>>> 
>>>>> that
>>>>> two APs with the same ESSID belongs to the same ESS, and therefore the
>>>>> same
>>>>> IP

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 04 Mar 2011 00:32:47 +0100

Hi Julien,

> the L3 between MN and MAG, a point-to-point link has to be provided at

I've just described how I make our lab proto work, emulating a
point-to-point link over a point-to-multipoint one.

> system that isn't 802 (e.g. 3GPP)?

All my previous e-mails about the lab prototype and WLAN refers to basic
PMIPv6, I haven't mentioned anything about flow mobility in that
context. That's a separate issue.

> You can't assume weak host model. Remember the IP layer is unmodified.

True, in IETF I cannot assume that. I've just wanted to make the point
that the same network signaling used in a prototype worked for terminals
with the logical interface artifact and with the weak host model. But I
just mentioned that to provide proof that I've seen the concepts we are
discussing in a working system.

> meetings. I haven' t seen those resolved yet, so I do not know how

That's a different draft. Authors are working on addressing unresolved
issues and your very right comments. New version will come out soon and
then we will be able to discuss about that (separate thread).

Carlos

---

From: <[email-masked]>
Date: Thu, 3 Mar 2011 23:46:45 +0000

>> 
>> > - Point-to-point emulation: MAG send the RA to the unicast 
>> > link-local address of the MN or it sends it multicast in IPv6 but 
>> > addressed to the
>I've just described how I make our lab proto work, emulating a point-to-point link over a point-to-multipoint one.

I agree with Carlo's comment about how one could emulate a PtP link over wifi. You do not have to change the Wifi Mac to emulate a PtP link.

-Raj

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Mar 2011 15:51:36 -0800

Hi Carlos,

> point-to-point link over a point-to-multipoint one.

I've just explained why what you do isn't emulating a point-to-point
link. A point-to-point link is a link that has only two endpoints.
What you explained creates a per-MN subnet. These are different
things...

> context. That's a separate issue.

So is it fair to say that your basic PMIPv6 system only works with
unmodified L2 signaling because you constrain the MNID to be an
EUI-48?

If so, if the MNID had to be something else (which it will necessarily
have to in a multi-radio-technology setup as in flow mobility and
inter-tech handoffs), you will need to extend L2 signaling, no?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Mar 2011 15:54:33 -0800

> I agree with Carlo's comment about how one could emulate a PtP link over wifi. You do not have to change the Wifi Mac to emulate a PtP link.

So you disagree with my comment that what Carlos is doing only
implements a per-MN subnet model, and does not emulate a
point-to-point link?

If so, maybe you or Carlos can explain how having a per-MN subnet
model can constrain a shared link to have only two endpoints...

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Mar 2011 15:55:54 -0800

Sri,

I don't know of a spec that requires a host receiving an RA without
PIO to send another RS...

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 04 Mar 2011 01:53:47 +0100

Hi Julien,

> What you explained creates a per-MN subnet. These are different

If the MAG always uses the L2 address of the MN as destination address
of the frames it sends, I think that is a way of emulating a
point-to-point link between the MAG and that MN. Of course is not like a
real point-to-point link (we cannot avoid MN X to receive multicast
packets sent by MN Y), but this is enough to support PMIPv6.

> unmodified L2 signaling because you constrain the MNID to be an

No, I could also have a pre-configured database with L2 IDs and the
mapping to MN-IDs, supporting different L2 technologies. But this is
just an example. We are missing the point, the discussion started with
an example of one potential lab prototype of plain PMIPv6.

Carlos

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 04 Mar 2011 15:34:48 +1100

> to retrigger the RS for PIO's

=> Why would the host do that? Did I miss something? An empty RA doesn't
trigger anything AFAIK.

Hesham

and allow the router to discover the host and
>>>>>> There are other questions and concerns that have been raised which I
>>>>>> would
>>>>>> advise the authors to focus on.
>>>>>>

---

From: <[email-masked]>
Date: Fri, 4 Mar 2011 17:57:54 +0000

>>>> the L3 between MN and MAG, a point-to-point link has to be provided 
>>>> at L2. How do you do that?
>>>
>> I agree with Carlo's comment about how one could emulate a PtP link
>> over wifi. You do not have to change the Wifi Mac to emulate a PtP
>> link. 
>

Keyword here is emulate... Not really implement a PtP link.
For a real PtP link you could run PPP between the MN and the AP. It is
definitely not something like PDCP which creates a PtP link. 
For lab purposes emulating a PtP link is sufficient, especially to
verify the protocol operation. 

>model can constrain a shared link to have only two endpoints... 

If you have the ability to modify the AP, you could emulate the PtP
link quite well. Dont know what kind of an AP Carlos has or the
details of his lab setup. But the fact is he has a working model.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 05 Mar 2011 08:47:55 -0800

Julien:

The current implementation conforming to RFC-2461/4861 do deal with this.
The optimizations that are built in ND to handle the case of no IPv6
router(s) presence on the link, clearly factor the lossy nature of the link
loosing RS/RA message in sequence and do provide a clear recovery path.

The purpose, mission and the sole objective for that ND stack in the IP host
is to discover routers, default-router, prefixes on the link and so it can
configure an IPv6 address on its interface. The host that is silenced after
max RS transmissions does reset its state machine any time it detects the
presence of the routers on the link and its back at square-1, discovery
*routers* on the link. A RA message with no PIO option is not forcing the
node to suspend its router discovery phase.

Just as how a simple IP node/CMIP node recovers from this situation in a
fixed link, so does the IPv6 node in the PMIP6 access link.

You can verify the code in Kame/BSD and Linux open source implementations.
You can even try it out with popular IPv6 host stacks.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 05 Mar 2011 08:48:18 -0800

> => Why would the host do that? Did I miss something? An empty RA doesn't

We are talking about the case of RS/RA getting loss in simple IP and PMIP
links. The node is not shutdown because there is initial ND message loss and
the node is not prevented from sending RS messages on the link, as long as
there is some indications about router presence on the link. There is
sufficient guidance on 2461/4861 on this. The RA with no PIO need not
explicitly trigger RS, but that allows the host to continue to keep the
discovery phase on, leading to the exact same recovery path for both a node
on a simple IPv6 links, vs PMIPv6 links.

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 07 Mar 2011 12:18:28 +1100

On 6/03/11 3:48 AM, "Sri Gundavelli" <[email-masked]> wrote:

> there is some indications about router presence on the link.

=> What you said above is that receiving an RA without a prefix option
triggers the host to send an RS. I'm not aware of that behaviour specified
anywhere. 

There is
> sufficient guidance on 2461/4861 on this.

=> That an RA without prefix option triggers and RS? Please cite the
section.

 The RA with no PIO need not
> discovery phase on,

=> It does nothing basically. If a host is doing router discovery receiving
the RA without prefix option has no effect.

Hesham

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 06 Mar 2011 18:21:22 -0800

> the RA without prefix option has no effect.

Any RA message, with or without PIO options, serves as a hint on the
presence of routers on the link, that allows the host to keep/restart the
router discovery phase on and will allow the host to reset its max-rs-retry
message counter and send the next RS message. If your comment is that they
are not directly tied (the RS message from the host due to receiving an RA
with no PIO), fine, but the host that suspended its router solicitations
after reaching the max RS count, is able to restart the discovery phase and
send the next RS message, just because of that periodic RA that it received,
which provides the router presence hint on the link. What is the difference
?

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 07 Mar 2011 13:29:29 +1100

> which provides the router presence hint on the link. What is the difference

=> What is the difference between what you say above and what you said
before? You were sugesting a reaction that is not specified anywhere. That's
the difference. The fact is, an "empty" RA for lack of a better term has no
effect on the host's behaviour according to 4861. So whether the host is
doing router discovery or not, it makes no difference. The host will
continue with its normal behaviour. Of course implementations can choose to
do things differently, but I wouldn't state it like an expected behaviour.
That's why I responded to your comment because it confuses people to suggest
that this is "how things work".

Hesham

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 06 Mar 2011 19:03:54 -0800

> that this is "how things work".

Ok. This clarification is fine, if it sounded like a "reactionary tie" of
the two messages.

Sri