Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03

From: <[email-masked]>
Date: Tue, 4 Jan 2011 18:07:19 +0000

At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem
Statement" I-D following a WG last call.
The I-D has gone through a WG last call previously. Please consider this
as the WG last call for the following I-D:
draft-ietf-netext-pmip6-lr-ps-03.txt

Reviews and feedback are appreciated. The WG last call will expire on Jan
20th. 

Please note that progress of documents is only possible when we have
enough people reviewing the WG documents.

-Chairs

---

From: <[email-masked]>
Date: Wed, 5 Jan 2011 12:29:54 +0100

Dear all,
I have read the draft and think it has improved, is concise, clear, and
correct ... Beyond some nits detected as follows: 

Ch. 3.1: 
   Hence, providing the
   necessary protocol specification to enable localized routing in
   PMIPv6 is necessary.
=> I think it sounds nice when we exchange 'necessary' by 'required' or
'strongly recommended'

Ch. 3.2:
s/being build by the CN's/being built by the CN's/
=> or may we omit 'being' completely? 

... considered as the MN's current pCoA,
=> add explanation (previous CoA, Proxy-CoA, ... ?)

s/Accordingly, these topological difference are denoted/Accordingly,
these topological differences are denoted/ 

s/without traversing the MNs' LMA(s)/without traversing the MNs'
LMA(s)./

Ch. 3.3.2:

s/domain .  Optional mechanisms for negotiating the IP version to use as
well as the encapsulation mode to use are outside the scope/domain.
Design of optional mechanisms for negotiating the IP version to use as
well as the encapsulation mode to use is outside the scope/ 

Ch.5:
s/registration of the MN or the CN respectively./registration of the MN
or the CN, respectively./

s/by CN's MAG (MAG2/MAG2') and its LMA (LMA2)./by CN's MAG (MAG2/MAG2')
and its LMA (LMA2/LMA2')./ 

s/are located in provider domain A/are located in provider domain A./

s/and CN's LMA (LMA2) is located in provider domain B/and CN's LMA
(LMA2') is located in provider domain B./

Thanks for all the work to editors and chairs ... And a Happy New Year
to all!

Best regards
Dirk
 
Von: [email-masked] [mailto:[email-masked]] Im Auftrag
von [email-masked]
Gesendet: Dienstag, 4. Januar 2011 19:07
An: [email-masked]
Betreff: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03

Reviews and feedback are appreciated. The WG last call will expire on
Jan
20th. 

-Chairs

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

---

From: Frank Xia <[email-masked]>
Date: Wed, 05 Jan 2011 15:35:51 -0800

Hi guys

I have a quick review of this draft. My main concern is about
the concept of CN(Correspondent Node).

Firstly, there is another definition in RFC3775 regarding CN.
What is the relationship between these two definitions?

Secondly, My impression is that the draft mostly assumes 
CNs are always attached to MAGs.  The draft should make
it clear that CNs could be mobile or stationary. It would 
be better to state why stationary CNs are not taken into account.

Lastly, this draft uses "set up" as a noun, e.g "The set up 
and maintenance of localized routing". I am not sure if its
appropriate.

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, January 04, 2011 10:07 AM
To: [email-masked]
Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03

-Chairs

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 07 Jan 2011 15:36:12 +0800

Hi,

I have read this draft, and I have some comments.

The scope of the base
   protocol covers the set up and maintenance of a forwarding tunnel
   between an MN's Mobility Access Gateway (MAG) and its selected Local
   Mobility Anchor (LMA).

MAG is defined as Mobile Access Gateway in RFC5213.

Localized Routing States: Information for localized routing on
      relevant forwarding entities on the direct data path between an MN
      and a CN.

"direct data path" seems not clear enough.

Mechanisms for
   route optimization in MIPv6 cannot be directly applied in PMIPv6, as
   MNs do not take part in mobility management and associated signaling.
   Following the paradigm of PMIPv6, MNs are not involved in mobility
   signaling, hence cannot perform signaling to set up localized routes.

These two sentences seem a bit duplicated or redundant to me.

Instead, the PMIPv6 functional entities of the LMA and MAG, which are
   involved in the mobility management of the MN and the CN, must be
   able to find out whether or not a localized route is to be used and
   then control the setup and maintenance of localized routing states
   accordingly without any assistance from the MN and the CN.

I feel uncomfortable in the "must".

Section 2 reads,
   o  Localized Routing: Result of signaling to set up routing states on
      relevant network entities to allow forwarding of data packets
      between an MN and a CN, which are attached to the **same provider
      domain** without intervention of the MN's LMA and the CN's LMA in
      data forwarding.

However, section 5 says,
A solution for localized routing cannot take any
   assumption about **whether or not MN and CN share the same PMIPv6
   domain**, ...
It is not required that LMAs, which hold the registration for the MN
   and the CN respectively, are part of the **same provider domain** as the
   MAGs where MN and CN attach.

it is confusing, localized routing is intra-domain-only or
inter-domain-possible?

Regards,
Xiangsong

> Sent: Wednesday, January 05, 2011 2:07 AM
> To: [email-masked]

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 7 Jan 2011 16:10:16 +0700

> "direct data path" seems not clear enough.

Have a suggestion?

...

> I feel uncomfortable in the "must".

I don't understand why not.

...

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 07 Jan 2011 17:33:07 +0800

> > "direct data path" seems not clear enough.

This is a difficult job to me, too, but I would like to try.
Localized Routing States: Information for localized routing on relevant
forwarding entities, which route the packets directly to the care-of address
of the destination node, rather than the home address.

> I don't understand why not.

Is it wrong if the entity is NOT able to find out ... ?

Xiangsong

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 7 Jan 2011 16:58:11 +0700

...

> Is it wrong if the entity is NOT able to find out ... ?

If both the LMA & MAG support localized routing but can't decide whether or
not to use it, that seems like a problem to me.

...

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 07 Jan 2011 18:05:05 +0800

> not to use it, that seems like a problem to me.

This is just a problem statement, why do you have the assumption of "LMA &
MAG support localized routing"?

Xiangsong

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 11 Jan 2011 16:15:13 +0100

Hi Dirk,

thanks a lot for the review and your comments! Please find
some feedback inline.

> => I think it sounds nice when we exchange 'necessary' by 'required' or
'recommended' sounds good.

> => or may we omit 'being' completely? 
yes, too many beings.. I think simply 'PMIP6 domain built by the CN's 
LMA..' should be ok.

> => add explanation (previous CoA, Proxy-CoA, ... ?)
good point, I'll expand it.

> these topological differences are denoted/ 
ok

> s/without traversing the MNs' LMA(s)/without traversing the MNs'
ok

> well as the encapsulation mode to use is outside the scope/ 
ok

> or the CN, respectively./
ok

> and its LMA (LMA2/LMA2')./ 
true

> s/are located in provider domain A/are located in provider domain A./
ok

> (LMA2') is located in provider domain B./
ok

> Thanks for all the work to editors and chairs ... And a Happy New Year
Many thanks to you for finding and proposing revision to all these 
editorial items.

Best regards,
marco

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 11 Jan 2011 17:14:26 +0100

Hi Frank,

thanks for your feedback. Please see inline.

> What is the relationship between these two definitions?
I do not see these two definitions conflicting. RFC3775 says:
"A peer node with which a mobile node is communicating. The 
correspondent node
may be either mobile or stationary."
For the LR discussion, NetExt considers a specific setup, which has the
MN's communication peer attached at a MAG as well. Only such use case
is relevant for NetExt. The additional definition for the CN in the PS draft
is to clarify where the CN is assumed for the use cases discussed in the PS.

We had a discussion long time ago about using MN1-MN2 or MN-CN. We
sticked to MN-CN to indicate also the direction of the communication setup.
Hence, MN sends first data packets to CN, which can trigger the setup of a
localized routing path. I also feel more comfortable in writing and reading
such notation rather than always using MN1, MN2.
If the WG finds this important to change, I can revise it.

> be better to state why stationary CNs are not taken into account.
Well, the CN can be stationary as long as it is attached to a MAG and
managed by PMIPv6. I agree that managing such node with PMIP may not
make too much sense. When it's stationary and *not* managed by PMIP,
we enter the discussion again to consider regular IPv6 nodes on an
access router. That has been addressed by Carlos long time ago.
We mention this in section 3.1, 2nd paragraph, but chairs ruled it out
from the solution.

I agree that the definition of CN in the PS repeats some parts of RFC3775.
We could revise text to say something like 'Take the definition according to
RFC3775 and assume further characteristics for the CN, such as MAG-attached,
PMIP managed.' Do you think this makes it clearer?

> and maintenance of localized routing". I am not sure if its
Ok, I'll check.

Thanks,
marco

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 11 Jan 2011 17:49:50 +0100

Hi Xiangsong,

thanks for your comments. Please see inline.

> MAG is defined as Mobile Access Gateway in RFC5213.
Ok, I'll revise the expanded wording accordingly.

> "direct data path" seems not clear enough.
I remember we had some discussion on this. What about the following:
'...entities on the optimized path between...' ?

> These two sentences seem a bit duplicated or redundant to me.
Ok, let's omit the second part of the first sentence:
'Mechanisms for route optimization in MIPv6 cannot be directly
applied in PMIPv6. Following the paradigm of PMIPv6, MNs are
not involved in mobility signaling, hence cannot perform signaling
to set up localized routes.'

> I feel uncomfortable in the "must".
This has been discussed in further mails. I'll reply using the latest one
of your discussion with Glen.

> it is confusing, localized routing is intra-domain-only or
Ok, I see. The first paragraph (Terminology) refers to the two MAGs, which
must share the same provider domain according to a NetExt WG decision.
The paragraph in section 5 refers to the anchors of the MN and the CN,
hence talks about the LMAs in the roaming model.
I agree we need to clarify this. What about the following:

' o  Localized Routing: Result of signaling to set up routing states on
      relevant network entities to allow forwarding of data packets
      between an MN and a CN, which are attached to MAGs sharing the
      same provider domain without intervention of the MN's LMA and the
      CN's LMA in data forwarding.'

Section 5:

'A solution for localized routing cannot take any assumption about 
   whether or not the MN's and CN's LMAs share the same PMIPv6
   domain, ...'

Does this revision make the text clearer?

Thanks and best regards,
marco

>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>     
> Of
>

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 11 Jan 2011 18:02:12 +0100

Hi Xiangsong,

please see inline.

Glen Zorn wrote:
>>>> Instead, the PMIPv6 functional entities of the LMA and MAG, which
>>>>         
>> are
>>     
>>>>    able to find out whether or not a localized route is to be used
>>>>         
>> and
>>     
>>>>    then control the setup and maintenance of localized routing
>>>>         
>> states
>>     
The sentence comprise two aspects: Finding out whether or not to 
optimize, and
controlling the setup. 'Finding out' can be based on a third component 
or an indication,
even a static policy to optimize for a particular pool of MN/CN 
prefixes. Still, it's the
PMIP components who find out, using whatever mechanism This is needed, 
hence a must.
Also the 'control of LR setup': We can rely only on existing PMIP components
to enable LR, at least for the key functions like signaling etc. To 
solve the problem,
I also see here a must.

But if you have a proposal which takes these requirements into account 
and makes
you feeling more comfortable, we can discuss this.

marco

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 11 Jan 2011 18:05:41 +0100

Xiangsong Cui wrote:
>> If both the LMA & MAG support localized routing but can't decide whether
>>     
> or
>   
I think because these are the only components we can do something to enable
LR, which is the problem we want to analyze and solve.

marco

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 12 Jan 2011 09:41:55 +0800

> '...entities on the optimized path between...' ?

Yeah ;) 
the new words is ok to me.

> to set up localized routes.'

Ok.

> of your discussion with Glen.

Ok.

> Does this revision make the text clearer?

Good, I see the points.

Thanks and regards,
Xiangsong

Jan

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 12 Jan 2011 09:48:24 +0800

> LR, which is the problem we want to analyze and solve.

If you say "To achieve localized routing, the entities must be able to (or
say have to be able to) ...", I would be ok.
But as Raj mentioned, the PS document should not say anything about the
solution space, I'm not sure is it appropriate under this criterion.

Regards,
Xiangsong

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 12 Jan 2011 15:36:44 +0100

Hi Xiangsong,

one correction of my proposal inline.

Xiangsong Cui wrote:
>>>       between an MN and a CN, which are attached to the **same
>>>       
>> provider
>>     
>>>    and the CN respectively, are part of the **same provider domain** as
>>>       
>> the
>>     
The paragraphs talk about different domains. The first one refers to the 
provider
domain, whereas Section 5 refers to the PMIPv6 domain. I still think 
that the
proposed revision to the Terms section helps to understand the requirement,
that both MAGs must share the provider domain. For Section 5, I think we
should stick to the original text, as it talks about PMIP domains, which are
defined by the relation between an MN's MAG-LMA association. Ok with you?

marco

>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>         
> Behalf
>   
>>> Of
>>>
>>>       
>>>> The I-D has gone through a WG last call previously. Please consider
>>>>         
> this
>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 12 Jan 2011 16:30:02 +0100

Xiangsong Cui wrote:
>>> This is just a problem statement, why do you have the assumption of "LMA
>>>       
> &
>   
>> I think because these are the only components we can do something to
>>     
> enable
>   
Ok. 'Entities' is not really clear, IMHO. What about using 'the solution'
and refer in this context to functions in the network as we cannot rely on
the MN?

Result:
'...the solution must consider functions in the network to find out whether
or not a localized route is to be used and then control the setup and 
maintenance
of localized routing states accordingly without any assistance from the 
MN and the CN.'

Is that ok?

marco

---

From: Frank Xia <[email-masked]>
Date: Wed, 12 Jan 2011 13:29:02 -0800

Hello Marco

Thank your response.
Please also check my inline comments...

BR
Frank

-----Original Message-----
From: Marco Liebsch [mailto:[email-masked]] 
Sent: Tuesday, January 11, 2011 8:14 AM
To: Frank Xia
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03

Hi Frank,

Well, the CN can be stationary as long as it is attached to a MAG and
managed by PMIPv6. I agree that managing such node with PMIP may not
make too much sense. When it's stationary and *not* managed by PMIP,
we enter the discussion again to consider regular IPv6 nodes on an
access router. That has been addressed by Carlos long time ago.
We mention this in section 3.1, 2nd paragraph, but chairs ruled it out
from the solution.
Frank=>Stationary CN means here regular IPv6 nodes attaching an access
router.
This is a ps document even though only some of the problems could be dealt
with.
Whole picture of the problems is important to understand.

Frank=>I don't think so. Anyway, you figure it out, and this is not
very important issue.

Ok, I'll check.

Thanks,
marco

Of

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 13 Jan 2011 11:41:20 +0800

> defined by the relation between an MN's MAG-LMA association. Ok with you?

I think I understand your point, but I still think the words is not clear
enough.

Firstly, I would like to see the terminology of "provider domain" and "PMIP
domain". In addition, "home domain" is mentioned in section 5.

In Section 2, localized routing is defined as (I refer to PS-draft-04),

   o  Localized Routing: Result of signaling to set up routing states on
      relevant network entities to allow forwarding of data packets
      between an MN and a CN, which are attached to MAGs sharing the
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      same provider domain, without intervention of the MN's LMA and the
      CN's LMA in data forwarding.

My questions to this definition are,
If MN is attached to MAG1 while CN is attached to MAG2, however, MAG1 and
MAG2 are from different carriers (the hint here is that the corresponding
LMAs are also from different carriers), is this scenario falls in the scope
of localized routing?  MN and CN are NOT attached to MAGs in the same
carrier network, is it true that the MAGs are NOT sharing the same "provider
domain" in this case?

In section 5, also saying about "provider domain",
   Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g.,
   LMAs, MAGs) tied by MN and CN may be distributed between different
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   provider domains (i.e., domain A, B, C) and MN and/or CN moves from
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   one provider domain to another one.  In order to support localized
   routing when roaming occurs, it is required that MAGs to which MN and
                                          ^^^^^^^^^^^^^^^^^^^
   CN connect are within the same provider domain and each MAG has a
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   security relationship with the corresponding LMA which maintains the
   registration of the MN or the CN, respectively.

The front says, in Figure 2, MAGs may be in different provider domains, and
section 5 mainly refers to figure 2 (where MAGs are actually distributed in
different provider domains), taking this as a basis, right?
The end of this paragraph says it is required that MAGs are within the same
provider domain, so should a "sharing-domain-figure" be provided as
reference?

Xiangsong

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 13 Jan 2011 14:08:48 +0100

Hi Frank,
please see inline.

> Whole picture of the problems is important to understand.

If I understand correctly, you propose having a section in the PS that 
analyzes
the use case of setting up a localized route between an MN's MAG and a
regular IPv6 node being attached to an access router, even though such
scenario is out of scope of NetExt. Correct?

ok

Marco

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 13 Jan 2011 14:41:32 +0100

Hi Xiangsong,
please see inline.

> domain". In addition, "home domain" is mentioned in section 5.

PMIPv6 domain is defined in RFC5213.

Nodes in a 'provider domain' are administered by one authority, the 
mobile network provider.
For details of the discussion in this context, please refer to the eMail 
conversation from
Sept 2009. Do you propose to define the term of a 'provider domain' in 
the PS?

> LMAs are also from different carriers),
I don't think you can map the MAG association to the LMAs. In case of 
roaming, both,
MN and CN can be anchored at two LMAs of the same provider, their home 
provider A.
The case you refer to assumes that MAG1 is with provider B and MAG2 is with
provider C, hence, MAGs do not share the same provider. Such case is 
possible,
but not considered for localized routing in NetExt.

>   is this scenario falls in the scope
> of localized routing?
technically: yes, but the other question is if there is benefit in 
setting up
a route between these two MAGs. Depends on how the two domains are 
connected.
When inter-domain traffic traverses LMAs anyway, there is no benefit.

>    MN and CN are NOT attached to MAGs in the same
yes.

> The front says, in Figure 2, MAGs may be in different provider domains,
where? Please point ot the text.

> different provider domains), taking this as a basis, right?
Do not confuse the components which are shared or located in different 
provider domains.
This is about MAGs only. When its says 'MAG1 and MAG2 are in the same 
provider
domain', this is independent of whether LMA1/2 is also in the same 
provider domain or not.
The discussion about the MN's LMA location relative to the associated 
MN's MAG location is
different from the location of two MAGs.

> provider domain, so should a "sharing-domain-figure" be provided as
it does. Fig 2 and associated text consider only MAGs in the same 
provider domain,
MAG1-MAG2, and MAG1'-MAG2', respectively.

marco

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 22:02:43 +0000

Marco,

>scenario is out of scope of NetExt. Correct?

RFC5213 covers the case where the CN (non-PMIP6 attached host) and the MN
(PMIP6 attached host) are associated with the same access router (MAG from
MNs perspective). So no reason to mention this.
But the case where the MN is attached to a MAG and the CN (non PMIP6 host)
is attached to another AR (which is a MAG in the scope of the PMIP6
domain) is best left out of scope.

-Raj

---

From: Frank Xia <[email-masked]>
Date: Thu, 13 Jan 2011 14:29:25 -0800

Hi Marco

Please check again.

BR
Frank

-----Original Message-----
From: Marco Liebsch [mailto:[email-masked]] 
Sent: Thursday, January 13, 2011 5:09 AM
To: Frank Xia
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03

Hi Frank,
please see inline.

If I understand correctly, you propose having a section in the PS that 
analyzes
the use case of setting up a localized route between an MN's MAG and a
regular IPv6 node being attached to an access router, even though such
scenario is out of scope of NetExt. Correct?
Frank=>I don't see any text saying such scenario is out of scope of Netext.
I encourage you to describe this use case. This is not a solution document.

ok

Marco

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 14 Jan 2011 09:11:00 +0800

> Sent: Thursday, January 13, 2011 9:42 PM
> To: Xiangsong Cui
> Cc: [email-masked]
> >> should stick to the original text, as it talks about PMIP domains,
which
> Sept 2009. Do you propose to define the term of a 'provider domain' in

Sorry I didn't follow the thread closely, but I think it would be better if
there was a definition.

> When inter-domain traffic traverses LMAs anyway, there is no benefit.

Thanks for the clarification.

> where? Please point ot the text.

The first sentence of section 5,
Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs,
MAGs) tied by MN and CN may be distributed between different provider
domains (i.e., domain A, B, C) and MN and/or CN moves from    one provider
domain to another one.

Let me try to simplify this sentence, it is describing the roaming case
which is showed in Figure 2, 
The front half of the subordinate clause says, "PMIPv6 components (e.g.,
LMAs, MAGs) tied by MN and CN may be distributed between different provider
domains" does this mean MAGs may be in different provider domain?
The end half of the subordinate clause says, "MN and/or CN moves from one
provider domain to another one". Does the *or* means that the nodes may roam
one by one? So even MAGs are in same provider domain, it would be changed
when one node is roaming (to a new MAG in another provider domain).

> different from the location of two MAGs.

Yes, I have known the difference on location of LMA and MAG.

> MAG1-MAG2, and MAG1'-MAG2', respectively.

Do you mean MN and CN are roaming exactly simultaneously? From MAG1/MAG2
pair to MAG1'/MAG2' pair?
In my impression, when MN (or CN) moves to a new provider domain, it would
lie in a different provider domain with CN (or MN), so the localized routing
should be released, right?
If you say they are exactly simultaneously roaming, supposed they are
registered in the same LMA, the LMA would receive PBU from MAG1' and MAG2'
respectively, I think here should be a single thread program, so it is
impossible for the LMA to receive exactly simultaneous message, do you mean
the LMA should hold one PBU for some time (not destroy localized routing
immediately although "different provider domain") and wait for the other PBU
(to continue the localized routing on new MAG pair)? This is of course
purely implementation issue, here my point is just to check the case.

Xiangsong

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 14 Jan 2011 11:12:44 +0100

Hi Frank,

Am 13.01.2011 23:29, schrieb Frank Xia:
> H
Technical scope of NetExt LR has been decided throughout the discussion.
Authors of the PS have been asked to reflect this in the PS. For the use 
case
to set up a localized route with a regular IPv6 node, the 3.1 has the 
following text:

"Maintaining local forwarding between the MN and the regular IPv6 CN
gets more complex in case the MN performs a handover to a different
MAG.  Such use case is not considered in the specification and out
of scope of this problem statement.  This document focuses on use
cases, where both nodes, the MN and the CN,are each registered with
an LMA and both obtain PMIPv6 mobility service."

Pleaase propose new or additional text in case you think this in not 
sufficient.

> I encourage you to describe this use case. This is not a solution document.

I am ok with having a short section analyzing this case. Would appreciate if
you have some input on this. Bullet lists is fine. I can make text out 
of that.
This assumes nobody (incl. chairs) object having such text in the PS.
Chairs?

marco

>> I agree tha

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 14 Jan 2011 11:15:59 +0100

Am 13.01.2011 23:02, schrieb [email-masked]:
> Marco,
>
> On 1/13/11 7:08 AM, "ext Marco Liebsch"<[email-masked]>  wrote:
>

Clear. That's why we added associated text in 3.1 Please check my last
reply to Frank in this context and let me know if this is sufficient.

marco

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 17:21:31 +0000

Hi Marco,

>reply to Frank in this context and let me know if this is sufficient.

I am okay with what you proposed. Thanks.
-Raj