Subject: Re: [netlmm] comment for draft-damic-netlmm-pmip6-ind-discover-03

From: "Damic, Damjan" <[email-masked]>
Date: Tue, 11 Mar 2008 13:42:26 +0100

Hello Jun,

Thank you for the comments.

With regards to the interactions cases, it appears we focused at
scenario B.
However, proposed mechanism introduce mobility indication mechanisms
both at the MN- and AR side, thereby aiming also at two other scenarios.
In essence, MIP6-capable MN would be able to detect capabilities of the
access network. With proper authorization (preprovisioned MNO
configuration, subscriber or network policies etc.) the MN could be
granted to choose IF it wishes to utilize the network-based mobility
management, and if so, HOW the allocated PMIP6 address would be used (as
MN-HoA - scenario C, or simply MIP6 CoA - scenario A).

Both your questions are valid, and we already tried to have them covered
in the draft (seems the draft could use few more clarifications in those
places).
Please find more detailed answers inline...

>From: Jun AWANO <[email-masked]>
>Subject: [netlmm] comment for draft-damic-netlmm-pmip6-ind-discover-03
>To: [email-masked]
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=ISO-2022-JP
>
>Hi damic,
>
>I think your draft is helpful for PMIP-CMIP interworking especally for
>scenario B described in draft-giaretta-netlmm-mip-interactions.
>But I have some comments for your draft.
>
>1. consideration of network policy
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Your draft says the following at "4.3. Router Solicitation Client-based
>Mobility Flag",
>   The MAG that receives it
>   SHOULD respond with a Router Advertisement containing a 
>topologically
>   correct prefix for the link (i.e., Not the emulated PMIPv6 prefix).
>
>I think final decision for mobility mode selection should be made by
>network.
>So upon receiving RS including C flag set to 1, a MAG should decide
>mobility mode after considering network policy. The policy may be
>different between each MNs depending on payment and other factors.
>The MAG can get the policy from policy store

[DD] Agree. Maybe it's not spelled out directly, but the network
obviously must have the authority to override mobility mode requests
coming from the MN. Essentially, the proposed "C" flag simply serves as
indication of terminal capabilities, providing such information to the
MAG before it initiates the PBU registration with the LMA. The
network/MAG should take it into account, in case MN is sufficiently
authorized.

>
>2. assumed order of RS
>~~~~~~~~~~~~~~~~~~~~~~
>Do you assume MN which always sends RS without waiting RA?
>On the other hand, does a MAG wait for RS from MN before 
>sending RA when
>the MAG uses RS for mobility mode selection.
>Because a MAG sends RA to MN after registration procedure(PBU/PBA)
>according to PMIPv6 base spec.

[DD] Good catch, this is one of fundamental issue we have to deal with.
As you state, MAG would need the mobility capability information before
initiating PBU and before delivering the addressing configuration
information. In other words this is the moment when decision on the
granted mobility mode happens, and when a certain prefix(es) gets
allocated.

We don't explicitly expect that MN will always send the RS (though
according to my information it would be regular behavior of an IPv6
host, and does happen with few exisiting implementations. Would you
assume otherwise?). I could imagine few possible scenarios:
1) The ARs can advertise "network-based" capability in the unsolicited
RAs, without providing any specific prefix info. Only the enhanced MIP6
MN would process such indication, and then could ask for a certain
mobility mode (depending on the terminal configuration) in the
subsequent RS/RA exchange
2) If no unsolicited RA is received, if RA did not provide any hint on
the mobility mode, or MN is by default set for client-mobility mode, it
could send the RS with the "client-mobility" indication by its own
initiative. End result again depends on the subscriber/network policy.
3) In the remaining cases the networks either does not support mobility
indication extensions, or decided to override any selection option, so
the MIP6 MN should take and configure whatever it gets. The downside is
the unoptimized case when MIPv6 would be run over PMIPv6 (involuntary
Scenario A).
Please feel free to comment if believing we left out any important
aspect...

Kind regards,
Damjan

>Best regards,
>Jun
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Jun AWANO <[email-masked]>
Date: Tue, 11 Mar 2008 23:51:04 -0400

Hi Damjan,

Please let me ask more. :)

I'm still not sure how your draft mechanism works.
I'll put down call flows according to my understanding.
Please correct them.

Now, my assumption is following.

- assumed mobile node types
n1. Mobile Node which has neither MIPv6 capability
     nor enhanced features described in your draft.
n2. Mobile Node which doesn't have MIPv6 capability
     but enhanced features described in your draft.
n3. Mobile Node which has MIPv6 capability but doesn't have
     enhanced features described in your draft.
n4. Mobile Node which has both MIPv6 capability and
     enhanced features described in your draft.

- assumed network policies
p1. mandate host-based mobility
p2. allow MN to choose its mobility mode

and policy can be different per MNs.

- upon receiving RA without specific prefixes and O & M flags
   (both flags are set to 0)
n1 and n3 type MNs ignore the RA.
n2 and n4 type MNs response to the RA by sending RS immediately.

<< call flows according to my understanding >>

o Case 1
~~~~~~~~~
   MN type is n1/n2/n3/n4.
   n4 type MN doesn't request host-based mobility.
   network policy is p1.

MN(n1/n2/n3/n4)      MAG          LMA
  |                    |            |
  |               <policy p1>       |
  | RA(no prfx,{pmip}) |            |
  |<-------------------|            |
<ignored> if mn type is n1 or n3   |
  | RS                 |            |
  |------------------->|   PBU      |
  |                    |----------->|
  |                    |   PBA      |
  |                    |<-----------|
  | RA(HNP,{pmip})     |            |
  |<-------------------|            |
<PMIPv6 mode>

(assumption in this case)
-n3 type MN may need additional procedure to find
  it is on its home link.
-{pmip} means "N" flag defined in your draft.
-HNP can be gotten during access authentication,
  or by PBA.

o case 2
~~~~~~~~~
   MN type is n4.
   n4 type MN requests host-based mobility.
   but network policy is p1.

MN(n4)               MAG          LMA
  |                    |            |
  |              <policy p1>        |
  | RA(no prfx,{pmip}) |            |
  |<-------------------|            |
  | RS(C flag='1')     |            |
  |------------------->|   PBU      |
  |                    |----------->|
  |                    |   PBA      |
  |                    |<-----------|
  | RA(HNP,{pmip})     |            |
  |<-------------------|            |
<PMIPv6 procedure>

(assumption in this case)
-{pmip} means "N" flag defined in your draft.
-HNP can be gotten during access authentication,
  or by PBA.

o case 3
~~~~~~~~~
   MN type is n1/n2/n3/n4.
   n4 type MN doesn't request host-based mobility.
   network policy is p2.

MN(n1/n2/n3/n4)      MAG          LMA
  |                    |            |
  |              <policy p2>        |
  | RA(no prfx,{pmip}) |            |
  |<-------------------|            |
<ignored> if mn type is n1 or n3   |
  | RS                 |            |
  |------------------->|   PBU      |
  |                    |----------->|
  |                    |   PBA      |
  |                    |<-----------|
  | RA(HNP,{pmip})     |            |
  |<-------------------|            |
<PMIPv6 mode>

(assumption in this case)
-n3 type MN may need additional procedure to find
  it is on its home link.
-{pmip} means "N" flag defined in your draft.
-HNP can be gotten during access authentication,
  or by PBA.

o case 4
~~~~~~~~~
   MN type is n4.
   n4 type MN requests host-based mobility.
   network policy is p2.

MN(n4)               MAG          LMA
  |                    |            |
  |              <policy p2>        |
  | RA(no prfx,{pmip}) |            |
  |<-------------------|            |
  | RS(C flag='1')     |            |
  |------------------->|            |
  | RA(HNP, {pmip, alt prfx info})  |
  |<-------------------|            |
<MIPv6 procedure>

(assumption in this case)
-{pmip} means "N" flag defined in your draft.
-{alt prfx info} means "Alternate prefix informaton"
  defined in your draft.
  And in this case it conveys local prefix for CoA of MIPv6.
-HNP can be gotten during access authentication.

o case 4'
~~~~~~~~~
   MN type is n4.
   n4 type MN requests host-based mobility.
   network policy is p2.

MN(n4)               MAG          LMA
  |                    |            |
  |              <policy p2>        |
  | RA(no prfx,{pmip}) |            |
  |<-------------------|            |
  | RS(C flag='1')     |            |
  |------------------->|            |
  | RA(local prfx)     |            |
  |<-------------------|            |
<MIPv6 procedure>

(assumption in this case)
-{pmip} means "N" flag defined in your draft.
-the second RA advertises its local prefix from
  which CoA is derived.
  (without alternate prefix information)

---------------

I want to make sure especially about case4(').

Another comment.
You mentioned this mechanism is available for scenario C
described in 'draft-giaretta-netlmm-mip-interactions-02'.
But MN must at least get the same anchor(LMA/HA) address
to which MAG send PBU upon switching from PMIPv6 mode to MIPv6
mode. And MAG must get the same anchor address to which MN
send BU upon switching MIPv6 mode to PMIPv6 mode, as mentioned
in the draft.
How do you think about this.
Is it out of scope of your draft?
As one solution,
MN and MAG(AR) can exchange the address information by RA/RS during 
mobility mode selection.
It may be suspicious from a point of view of appropriate design.
And it isn't solution for adoptable widely, though.

Best regards,
Jun

---

From: "Damic, Damjan" <[email-masked]>
Date: Thu, 13 Mar 2008 15:06:19 +0100

Hi Jun,

Thanks for your detailed analysis, it kept me occupied for quite some
time :)
In principle your drafted call-flows comply to what we had in mind, but
there are also some subtle differences.
Please let me explain below...

>-----Original Message-----
>From: Jun AWANO [mailto:[email-masked]] 
>Sent: Wednesday, March 12, 2008 4:51 AM
>To: Damic, Damjan
>Cc: [email-masked]
>Subject: Re: [netlmm] comment for 
>draft-damic-netlmm-pmip6-ind-discover-03
>
>Hi Damjan,
>

[DD] Case n2 is not valid from my perspective. Indication extension
should only come together with the MIP6 stack, there is no need/purpose
making "legacy" IPv6 node aware of any network- or client-based
mobility.

>p1. mandate host-based mobility

[DD] After reading the email through, I assume under p1 you actually
meant "mandate network-based mobility", right? This is at least how I
will answer...

>n1 and n3 type MNs ignore the RA.

[DD] Actually no. We shaped the indication extensions in such format NOT
TO cause RA/RS to be discarded or ignored by the other side. The
processing entity should only skip/ignore the new flag or option carried
within if not recognizing it. The standard fields of the RA should still
establish the default router entry at the MN side (for all given MN
types). The whole point is to make the extension transparent for the
"legacy" terminals (n1 & n3 types), would you agree?
Additional remark for completness. We have also tried covering case of
stateful addressing (when RA's "M" flag is set) with similar DHCPv6
extensions.

>n2 and n4 type MNs response to the RA by sending RS immediately.

[DD] To my understanding, n3 MN will send the RS too but without any
extenstion.

>   n4 type MN doesn't request host-based mobility.

[DD] As explained above, we assume n3 nodes will not ignore such
enhanced unsolicited RA. Therefore I don't exactly understand what do
you mean by "need additional procedure", could you please explain?
However, because of the <policy p1> n3 MN may end up configuring PMIP6
address as MIP6 CoA, resulting with an unoptimized/enforced Scenario A.

>   but network policy is p1.

[DD] This case had me thinking, believe you made a good point here.
We figured {pmip} or "N" flag will serve as general capability
indication of the AR/MAG, and intended NOT TO TIE this to the type of
prefix carried in the Prefix Information option. Depending on the
network policy (p1 or p2) the AR would include its default prefix (HNP
or local) in the legacy prefix option, and may include the other prefix
in the Alternate Prefix option (option defines a type field which
specifies exactly which prefix is contained in the payload).
The problem may arise when a single prefix option is delivered in RA, as
you show here. If network policy imposes only PMIP6 use, the MN may not
be sure about the outcome of its "Client" request. We have to make sure
MN recognizes it has obtained localized PMIP6 mobility (whether it will
use it as MIP6 CoA and abstain from further registration, or fully
achieve Scenario C depends on the HN parameters bootstrap/configuration
procedure)
You deduced existence or absence of the "N" flag will be the hint for
delievered prefix type. True, it should do the trick, but we'll think
bit further is there's another more explicit solution.

>   n4 type MN doesn't request host-based mobility.

[DD] Again, don't understand what could go wrong here with n3 MNs?
Additionally, according to our current proposal MAG can include regular
& alternate prefix option in the solicited RA, even if not receiving the
RS's "Client" indication, giving the MN another possiblity to choose.
Approach illustrated above is probably cleaner avoiding possible
ambiguities on MN's selected mode.

>   n4 type MN requests host-based mobility.

[DD] We propose to keep it flexible. "Alternate prefix informaton"
should convey complement of the prefix type provided in the regular
prefix information, either HNP or local prefix depending on default
network's mobility policy. So, the solicited RA could also look like:
RA({pmip}, local prfx, alt prfx info(HNP)})

>   n4 type MN requests host-based mobility.

[DD] Yes, this would be the ideal call flow outcome, MN receiving one or
more local prefixes that it asked for. Oppositely from your cases 2&3 I
guess we could clarify I-D text that in such case "N" flag is not set,
and there should be no accompanying alternate prefix option because MN
already made it's choice of mobility mode.

[DD] So far, we only assumed that MIPv6 MNs would use DHCPv6-based
bootstrapping (as described in draft-ietf-mip6-hiopt-11) to retreive all
home network related information including HA address, HNP, etc. (see
hiopt section 3.1.1). This is how Scenario C may be controled. There was
no approach to solving the problem completely by means of SLAAC, and I'm
not sure we should be attempting that?

What I resolve from your valuable comments is that we still have some
space for I-D improvements. For example, decide whether to logicaly bind
the "N" flag with the prefix information payload (we could avoid sending
double prefix options in some instances). On the other hand, the
alternate prefix is needed when unicast RA is sent directly after
network authentication, without prior RS/capability exchange between MN
and MAG.
Hope my explanations have proven helpful, and will prompt you to send
further questions or improvement suggestions :))

Kind regards,
Damjan

---

From: Jun AWANO <[email-masked]>
Date: Thu, 13 Mar 2008 17:52:28 -0400

Hi Damjan,

Please find inline.

> making "legacy" IPv6 node aware of any network- or client-based

[JA] o.k.

> meant "mandate network-based mobility", right? This is at least how I

[JA] Sorry. You're right. I made a mistake.

> stateful addressing (when RA's "M" flag is set) with similar DHCPv6

[JA] O.K. The RA cause MN's default router entry to changing.
      And I also think that it very important existing MN work well.
      That's one reason why I picked up considerable type of MNs and
      tried to check out their procedures with call flows.

> [DD] To my understanding, n3 MN will send the RS too but without any

[JA] Why do you think so?
      I don't have any objections but I just want to confirm.

> address as MIP6 CoA, resulting with an unoptimized/enforced Scenario A.

[JA] Mobility selection can be involved not only in the bootstrapping
      case but also in the handover case.
      Here, I considered bootstrapping case.
      MN doesn't have knowledge about where is its home. So MN can't
      understand HNP including in RA is exactly its HNP.
      On the other hand, n4 type MN can know that using hint, which
      is "N" flag.
      But now, I've understood. As you explained in your reply
      you assumes that you use DHCPv6-based bootstrapping.
      If so n3 type MN also can detect returning home link and
      act as PMIPv6 node.

> bit further is there's another more explicit solution.

[JA] I thought "N" flag indicates network decision depending on
      MN's requirement and network policies, and it is also hint
      for MN to decide whether if default(legacy) prefix conveys
      HNP or local prefix.
      Delivered prefix type should be indicated explicitly
      if needed, as you said
      Moreover, the indication of PMIPv6 capability and the result
      of mobility mode decision should be separated.

> ambiguities on MN's selected mode.

[JA] As for additional procedure for n3 type MN that explained above.
      Upon receiving RS, network(MAG) decides whether if it should
      send PBU or not, depending on "Client" request, which is "C" flag.
      If there is no "Client" request, the MAG sends PBU.
      Once the MAG sent PBU, I think there is no space where the MN
      chooses host-based mobility. So the MAG doesn't(MUST NOT) include
      alternate prefix information into the RA. It's my understanding.

      You think about "scenario A case" here, don't you??
      I think middle PMIPv6 cloud should be completely transparent
      to the MN. So there might be no necessity of mobility mode
      selection.
      Do you have any valid use cases to control MN's mobility mode
      in the scenario A.
      Or, am I overlooking something?

> already made it's choice of mobility mode.

[JA] I agree with you.
      If MN requested host-based mobility and network permitted it,
      in other words RA didn't include "N" flag,
      Alternate prefix option isn't needed in the RA.

> not sure we should be attempting that?

[JA] O.K.
      If a MN has a MIPv6 capability potentially,
      the MN always get information for performing as MIPv6 host with
      DHCPv6, regardless its actual mobility mode.
      So the MN and MAG can share the information at this time, right?

> further questions or improvement suggestions :))

[JA] Your explanation is helpful for my understanding. :)
      Thanks.
      I'll consider much more about this and I'll make
      comments or questions if I have something.
      But I need much more time to consider.

Best regards,
Jun

---

From: Jun AWANO <[email-masked]>
Date: Sun, 23 Mar 2008 23:33:58 +0900

Hi Damjan,

Sorry for my late reply.
Please see inline.

Damic, Damjan wrote:
> Hi Jun,
> 
> Apologize for getting back only after the weekend.
> Please find three short responses inline...
> 
> 
>> Sent: Thursday, March 13, 2008 10:52 PM
>> To: Damic, Damjan
>> Cc: [email-masked]
> [DD]
> I guess the MS will be be missing valid addressing information, so it
> needs to send the RS. That is according to RFC4861, Sec 6.3.7:
>    ...Once the host sends a Router Solicitation, and receives a valid
>    Router Advertisement with a non-zero Router Lifetime, the host MUST
>    desist from sending additional solicitations on that interface, until
>    the next time one of the above events occurs.  Moreover, a host
>    SHOULD send at least one solicitation in the case where an
>    advertisement is received prior to having sent a solicitation.
>    Responses to solicited advertisements may contain more information
>    than unsolicited advertisements...
> 

[JA]
O.K. Thanks for your clarification.
A MN most likely sends at least one RS even if the MN received any 
unsolicited RAs.

> [DD] Precisely. One related thing... I've just seen an interesting
> debate on MEXT ML on MIP6 bootstrapping. In case of some notable
> conclusion we could explore furhter if such mechanism is also applicable
> for mobility selection scenarios...
> 

[JA]
I also checked out the ML. And I agree with you.

> [DD] I agree we should explain behavior of peers in specific
> interactions cases bit more, like for one illustrated above.
> On the other hand, I didn't quite get your comment related to scenario
> A?
> In scenario A the MN would be at liberty to trigger global mobility
> registration with its HA, once obtaining PMIP6 localized mobility
> management. In that respect, MIP6 MN needs to recognize network-based
> mobility service being provided (e.g. through our proposed NDP/DHCPv6
> extensions), and needs some additional inteligence to decide if/when
> global mobility setup is needed alongside PMIP6. Occurence of such cases
> probably can be controlled by the network when dynamic boostrapping is
> used. However, we are not yet assuming about usefulness or validity for
> the interaction scenarios, only discussing about the potential
> solutions, right?
> Believe MIP-PMIP6 interactions are becoming the NETLMM WG item, so hope
> there will be opportunity to deal with this in more details soon.
> 

[JA]
Scenario A assumes that MIPv6 over PMIPv6.
I thought the system(operator) which adopts scenario A always expects
that a MN uses MIPv6 and network uses PMIPv6.
But there would be a possibility where MN doesn't use MIPv6 as you said.
However, scenario A is different from scenario B/C.
In the scenario B/C, network chooses whether it serves PMIPv6 or MIPv6 
alternatively.
In the scenario A, network chooses whether it allows the MN to use MIPv6 
or not regardless of serving PMIPv6

Best regards,
Jun