Subject: Re: [netext] [Netext] localized route optimization - roaming issue

From: Qin Wu <[email-masked]>
Date: Mon, 07 Sep 2009 11:01:34 +0800

Hi,Mohana and Marco:
I am wondering whether we need to write something to address roaming issue
or what we talk about here is just to clarify how to understand local MAG routing applicability.
As for me, I think it is beneficial to have some explaination text/section addressing this in the PS draft.

Regards!
-Qin
----- Original Message ----- 
From: "Mohana Jeyatharan" <[email-masked]>
To: "Marco Liebsch" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; "Cypher, David E." <[email-masked]>; <[email-masked]>
Sent: Friday, September 04, 2009 4:44 PM
Subject: RE: [Netext] localized route optimization - roaming issue

Hi Marco,

Such disussion we had is more to understand the local MAG routing
applicability. 

>Or should we provide additional info in the
> PS?
So, I think in PS we need not talk about SA between MAG. Or LMA or some
other entity helping in creating the security association between MAGs. 

Thanks.

BR,
Mohana
> -----Original Message-----
> From: Marco Liebsch [mailto:[email-masked]]
> Sent: Friday, September 04, 2009 4:19 PM
> To: Mohana Jeyatharan
> Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.;
> [email-masked]
> Subject: Re: [Netext] localized route optimization - roaming issue
> 
> Hi Mohana,
> 
> Mohana Jeyatharan schrieb:
> > Hi Marco and all,
> >
> >
> >> The PMIPv6 domain term does not fit in here, in my opinion, as we
> >> do not talk about the scope of a single MN's mobility, but the
> >>
> > relation
> >
> >> between mobility management components of two MNs.
> >>
> >
> > I agree on this.
> >
> >
> >> solution: PMIPv6 components, which exchange signaling in the
context
> >>
> > of
> >
> >> route optimization, must share a security association. Everything
else
> >>
> > is
> >
> >> deployment specific.
> >>
> >
> > Here we can probably explain which entities need security
association
> > for RO to be succussful. This is more towards solution space tied to
> > different local MAG RO scenarios. I think the current localized RO
> > solution drafts have captured these.
> >
> We can only provide examples. To establish a forwarding tunnel between
> MAGs does not mean
> we need an SA between them. Only if we perform signaling between MAGs,
> the SA is required.
> As you said, this is solution specific. So, to be on the safe side, we
> could discuss the
> picture and indicate that the solution may need an SA between the two
> associated LMAs
> and the two associated MAGs. Or should we provide additional info in
the
> PS?
> 
> marco
> 
> > BR,
> > Mohana
> >
> >> -----Original Message-----
> >> From: Marco Liebsch [mailto:[email-masked]]
> >> Sent: Thursday, September 03, 2009 11:56 PM
> >> To: Qin Wu
> >> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco
> >>
> > Liebsch;
> >
> >> [email-masked]
> >> Subject: Re: [Netext] localized route optimization - roaming issue
> >>
> >> Now coming back to my original opinion that I don't see benefit in
> >> mandating support for or ruling out any particular roaming
scenarios.
> >> The picture I proposed could be used in the Problem Statement (PS)
> >> at the most to discuss *issues* when components being associated
> >> with MN1 and MN2 are distributed between administrative domains.
> >> The PMIPv6 domain term does not fit in here, in my opinion, as we
> >> do not talk about the scope of a single MN's mobility, but the
> >>
> > relation
> >
> >> between mobility management components of two MNs.
> >>
> >>  From that picture I see that only one requirement derives for the
> >> protocol
> >> solution: PMIPv6 components, which exchange signaling in the
context
> >>
> > of
> >
> >> route optimization, must share a security association. Everything
else
> >>
> > is
> >
> >> deployment specific.
> >>
> >> marco
> >>
> >>
> >>
> >> Qin Wu wrote:
> >>
> >>> Thank for your clarification.
> >>> In this sense, no matter which domain the MN's MAG belongs to,  as
> >>>
> > long
> >
> >> as the MN does not change LMA and MN's current MAG can setup SA
with
> >>
> > MN's
> >
> >> LMA, MN is still in the same PMIP6 domain as its LMA. Right?
> >>
> >>> Regard!
> >>> -Qin
> >>> ----- Original Message -----
> >>> From: "Sri Gundavelli" <[email-masked]>
> >>> To: "Qin Wu" <[email-masked]>
> >>> Cc:
>

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Mon, 7 Sep 2009 11:29:32 +0800

Hi Qin, Marco and all,

> or what we talk about here is just to clarify how to understand local
MAG
> routing applicability.

Yes, I agree. The PS needs to mention about some deployment scenarios
wherevthe local MAG routing can be applied (ex bcos of SA available) and
scenarios where cannot be applied (SA cannot be established so cannot
perform). 
*The scenarios Marco attached previously can be used. 
*Perhaps some terminilogy such as PMIPv6 domain, administrative domain
etc in the PS will be helpful. I mean PMIPv6 doamin is already well
defined but re-emphasizing it w.r.t. to the work in local MAG routing
will be useful.

I guess these canbe captured without any details of solutions in the PS
draft. Such capturing is useful to identify whether the solution drafts
we have address all such cases of local MAG route optimization
Again this is my opinion.

Thanks.

BR,
Mohana

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Qin Wu
> Sent: Monday, September 07, 2009 11:02 AM
> To: Mohana Jeyatharan; Marco Liebsch
> Cc: [email-masked]
> Subject: Re: [netext] [Netext] localized route optimization - roaming
> issue
> 
> Hi,Mohana and Marco:
> or what we talk about here is just to clarify how to understand local
MAG
> routing applicability.
> As for me, I think it is beneficial to have some explaination
text/section
> addressing this in the PS draft.
> 
> Regards!
> -Qin
> Cc: "Qin Wu" <[email-masked]>; "Sri Gundavelli"
<[email-masked]>;
> "Cypher, David E." <[email-masked]>; <[email-masked]>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 08 Sep 2009 14:31:36 +0200

Hi Mohana, Qin,

ok, we can take a section "Roaming Aspects" into account for the PS and 
discuss
applicability of localized routing. We can add this section to the 
initial WG draft
of the PS. If folks consider this later as not useful, we can take it 
out again.

Btw, I think this discussion can happen in parallel to protocol design, 
just to address
some folks' concern with a PS to delay the protocol design.

 From the discussion we had so far, obviously it's common understanding that
use cases with two LMAs should be supported, right?

Thanks,
marco

Mohana Jeyatharan wrote:
> Hi Qin, Marco and all,
>
>   
>> I am wondering whether we need to write something to address roaming
>>     
> issue
>   
>> I am wondering whether we need to write something to address roaming
>>     
> issue
>   
>> So, I think in PS we need not talk about SA between MAG. Or LMA or
>>     
> some
>   
>> other entity helping in creating the security association between
>>     
> MAGs.
>   
>> Thanks.
>>
>> BR,
>> Mohana
>>     
>>>> for RO to be succussful. This is more towards solution space tied
>>>>         
> to
>   
>>> We can only provide examples. To establish a forwarding tunnel
>>>       
> between
>   
>>> MAGs does not mean
>>> we need an SA between them. Only if we perform signaling between
>>>       
> MAGs,
>   
>>> the SA is required.
>>> As you said, this is solution specific. So, to be on the safe side,
>>>       
> we
>   
>>> could discuss the
>>> picture and indicate that the solution may need an SA between the
>>>       
> two
>   
>>> associated LMAs
>>>>> Subject: Re: [Netext] localized route optimization - roaming
>>>>>           
> issue
>   
>>>>> Now coming back to my original opinion that I don't see benefit
>>>>>           
> in
>   
>>>>> The picture I proposed could be used in the Problem Statement
>>>>>           
> (PS)
>   
>>>>>  From that picture I see that only one requirement derives for
>>>>>           
> the
>   
>>>>> protocol
>>>>>> In this sense, no matter which domain the MN's MAG belongs to,
>>>>>>             
> as
>   
>>>> long
>>>>
>>>>

---

From: <[email-masked]>
Date: Tue, 8 Sep 2009 17:23:07 +0200

Hi Marco,

One of the issues that we got hung up at IETF75 during the LR discussion was
on roaming. It would be good to have a clear description of the relationship
between the MAG and LMA in the context of a PMIP6 domain especially when you
consider home and visited network scenarios wherein the MAG/LMA entities are
in different domains.

The PMIP6 domain definition in RFC5213:
"
      Proxy Mobile IPv6 domain refers to the network where the mobility
      management of a mobile node is handled using the Proxy Mobile IPv6
      protocol as defined in this specification.  The Proxy Mobile IPv6
      domain includes local mobility anchors and mobile access gateways
      between which security associations can be set up and
      authorization for sending Proxy Binding Updates on behalf of the
      mobile nodes can be ensured.
"

does not have any references to home/visited network concepts. The only
criteria for an entity (MAG/LMA) being considered being a part of the PMIP6
domain is the existence of a security association. It would be good to
elaborate how this maps to the current discussion in LR.

-Raj

---

From: Qin Wu <[email-masked]>
Date: Wed, 09 Sep 2009 16:46:23 +0800

Hi, Marco:
I think roaming case is very usful. It help us to better understanding
on how local routing works when MN roams over PMIPv6 domain.
So I support to add a new section to talk about roaming section. 

In this sense, we can loose requirements on PMIPv6 components distribution.
i.e., MN's LMA and CN's LMA need not stay with MN and CN within the same
PMIPv6 domain, But it is required that MN and CN should connect to corresponding MAGs
within the same PMIPv6 domain,  am I right?
Based these loose requirements or assumption, I think use case with two LMAs can be supported.

As regarding protocol desgin, I think there is no reason to delay this work if folks have arrived at common understanding.

Regards!
-Qin

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 09 Sep 2009 17:07:58 +0200

Hi Raj,

yes, agreed, that's why it has been proposed to add a section on this in 
the PS. The picture
could be based on what I sent some mails ago. We're currently preparing 
some text, but
I think it makes sense to discuss and agree on the text before it goes 
to the PS draft.

marco

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 09 Sep 2009 17:15:46 +0200

Hi Qin,

> So I support to add a new section to talk about roaming section. 
Yes, I am ok with this.
> within the same PMIPv6 domain,  am I right?
I think your text fits better when talking about administrative domains ;-)
I'd propose to take the last picture about the roaming case and take this as
base for the discussion. In my opinion, we need to talk about administrative
domains to resolve this. I also see the need to define (according to 
David's comment)
what's an administrative domain this the context of this discussion.

marco

---

From: Qin Wu <[email-masked]>
Date: Thu, 10 Sep 2009 20:29:57 +0800

Hi, all:
Since folks has no objection to add a section to talk about roaming issues. I would like to propose
some texts based on roaming picture proposed by Marco. The proposed text is as follows:
"
In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) can be distributed into different PMIPv6 domains. In order to support localized routing, it is required that MAGs to which MN and CN connect  are within the same PMIPv6 domain and each MAG setup security relationship respectively with corresponding LMAs which maintain specific context to which MN and CN belong. It is not required that LMAs anchored by MN and CN are part of PMIPv6 domain as MAGs attached by MN and CN. MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or over different PMIPv6 domains(i.e., MN's visited domains). CN should stay with MN within the same PMIPv6 domain.  Figure x shows PMIPv6 roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 domain. In this figure, four PMIPv6 roaming cases need to be taken into account.
Roaming case 1:
MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are located in the same PMIPv6 domain A as described in the figure 2.
Roaming case 2:
MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain B.
Roaming case 3:
MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A
Roaming case 4:
MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) is located in the PMIPv6 domain B

"

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

> 
> 
>                                     |
>           +-----+       +-----+     |      +-----+
>           |LMA1 |       |LMA2 |     |      |LMA2'|
>           +-----+       +-----+     |      +-----+
>                                     |
>                                     |
>                                     |
>                                     |
>           +-----+       +-----+     |
>           |MAG1 |       |MAG2 |     |
>           +-----+       +-----+     |
>                                     |
>                                     |
>                                  A  |  B
>       ------------------------------+-------------------------------
>                                     C
> 
> 
>                          +-----+        +-----+
>                          |MAG1'|        |MAG2'|
>                          +-----+        +-----+
> 
> 
> 
> 
> 
> 
> 

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

If people prefer to use administrative domain, we can replace all PMIPv6 domain in the proposed text with *administrative domain*, Welcome your bash,:-)
Regards!
-Qin

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 10 Sep 2009 14:58:34 +0200

Hi Qin,

thanks for proposing some text. I think it's a good starting point.
Please see for a comment inline.

marco

Qin Wu wrote:
> In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) can be distributed into different PMIPv6 domains. In order to support localized routing, it is required that MAGs to which MN and CN connect  are within the same PMIPv6 domain and each MAG setup security relationship respectively with corresponding LMAs which maintain specific context to which MN and CN belong.
I am not sure if we can say that the two MAGs belong to the same PMIP
domain, can we? Look at the picture: MAG1' and MAG2' (roaming case)
belong to one PLMN (or administrative domain), I think that was the
requirement we talked about some time ago. Now, MN is attached to MAG1'
and registered with LMA1, whereas CN is attached to MAG2' and registered
with LMA2 or LMA2'. MAG1' and LMA1 build one PMIP domain, MAG2'
and LMA2/LMA2' build one PMIP domain. I don't think this implies that
MAG1' and MAG2' are in the same PMIP domain. This also means that
we cannot assume that MAG1 has an SA with LMA2/LMA2'. Hence, MN
and CN are attached to different PMIPv6 domains. That's at least my view.

>  It is not required that LMAs anchored by MN and CN are part of PMIPv6 domain as MAGs attached by MN and CN. MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or over different PMIPv6 domains(i.e., MN's visited domains). CN should stay with MN within the same PMIPv6 domain.  Figure x shows PMIPv6 roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 domain. In this figure, four PMIPv6 roaming cases need to be taken into account.
> Roaming case 1:

---

From: Qin Wu <[email-masked]>
Date: Fri, 11 Sep 2009 10:23:04 +0800

Hi, Marco and all:
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, September 10, 2009 8:58 PM
Subject: Re: [Netext] roaming issue-proposed text for roaming section

> and CN are attached to different PMIPv6 domains. That's at least my view.

[Qin]: I know your concerns. I think we have some misunderstanding on PMIPv6 domain or *administrative domain*
In my mind, *Administrative A, B,C* are really *PMIPv6 domain A, B,C* I understand respectively. In this way, we can see
1.LMA1,LMA2,MAG1,MAG2 do not leave PMIPv6 domain A 
2. LMA2' does not leave PMIPv6 domain B
3. MAG1',MAG2' do not leave PMIPv6 domain C.
Only MN and CN can roam within one PMIPv6 domain or roam over different PMIPv6 domain. whatever MN move around, MN still belong to the same PMIPv6 domain as LMA which maintains MN's context information.

As regarding whether MAG1' and LMA1 build one PMIP domain, MAG2' and LMA2/LMA2' build one PMIP domain,
I have the same understanding as you before. But from the discussion in the ML, I have new understanding.

In my opinion, MAG1' belongs to PMIPv6 domain C, when MN is attached to the MAG1', MN will be achcored to LMA1 in the PMIPv6 domain A(i.e., MN's home PMIPv6 domain) through MAG1' in the PMIPv6 domain C(i.e., one visited PMIPv6 domain). In this sense, MAG1' still belong to PMIPv6 domain C and MN and MN's LMA(i.e., LMA1) still belong to the PMIPv6 domain A. So it seems not reasonable to say we build one new PMIPv6 domain containing MAG1' and LMA1. 
So my conclusion is PMIPv6 domain can be understand as PLMN, we can allow two different PMIPv6 domains are interconnected with each other, but we are not necessary to understand them as one big PMIPv6 domain. 

On the other hand, MAGs in one PMIPv6 domain can be attached by MN which belongs to the same PMIPv6 domain as these MAGs.
  and MAGs in one PMIPv6 domain also can be attached by MN moving from another PMIPv6 domain, in other words MN and MAGs may belong to different PMIPv6 domains although  MN communicates with LMAs through these MAGs.
So if MAGs does not leave one PMIPv6 domain, these MAGs can be understood to belong to this PMIPv6 domain. And these MAGs can be used to access LMAs  by MNs which belong to different PMIPv6 domain.

Does this make sense?

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 11 Sep 2009 11:24:32 +0200

Hi Qin,

please see inline.

> I have the same understanding as you before. But from the discussion in the ML, I have new understanding.
I don't understand why, as the PMIPv6 domain is clearly defined. Sri 
posted in the context of
this discussion the definition which says inter alia "...From the 
protocol perspective, as long as
there is a SA between the LMA and MAG, that defines the PMIPv6 
domain..." So, according to
my understanding, if a MAG-LMA combination supports network-based 
mobility for a node,
this defines the PMIPv6 of the node.

> So my conclusion is PMIPv6 domain can be understand as PLMN,
I see, hmm, so roaming seems to be moving between PMIPv6 domains in your 
understanding, right?
I think we have different views here and may need more opinions.

I think it's difficult to stick to PMIP domains only and not talk about 
administrative domains or PLMNs
if folks want to discuss roaming cases for localized routing.

marco

>  we can allow two different PMIPv6 domains are interconnected with each other, but we are not necessary to understand them as one big PMIPv6 domain. 
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 11 Sep 2009 18:08:50 +0800

Hi, Marco:
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, September 11, 2009 5:24 PM
Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section

> domain..." 

[Qin]: There is no confusion here. In my understanding, the PMIPv6 domain 
mentioned above is LMA's PMIPv6 domain. Because MN does not change 
LMA but MN can frequently change its MAG when inter-MAG handover 
occurs.MAG may belong to the same PMIPv6 domain as LMA, also MAG 
may belong to another PMIPv6 domain .
So It does not matter MAG is located in the MN's home PMIPv6 domain to
 which MN's LMA belong or MAG is located in the MN's visited PMIPv6 
domain to which MN's LMA does not belong.
In this sense, wherever MN moves around, MN does not change its home
 PMIPv6 domain and LMA. Am I right?

>So, according to

[Qin]: In my understanding, each PMIPv6 domain has its boundary. 
otherwise, we can say there are millions of PMIPv6 domains.
Because we can find millions of MAG-LMA combinations. 

> I see, hmm, so roaming seems to be moving between PMIPv6 domains in your 

[Qin] Yes, but you can call this kind of PMIPv6 domain as *administrative domain*.

> I think we have different views here and may need more opinions.

[Qin]: Agree. We need more opinions on this.

> if folks want to discuss roaming cases for localized routing.

[Qin]: I am not sure whether it is necessary to define new terminology.
But I agree using administrative domains helps us well understand romaing issues.

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 15 Sep 2009 15:45:54 +0800

Hi Qin,

Sorry wanted to comment on your text, but here are some comments.  

I think we should stick to the definition of PMIPv6 domain as in RFC
5213 and not change it. That is, as long as the MAG-LMA tunnel can be
created, it is considered as one PMIPv6 domain of MN. While being
attached to such PMIPv6 domain, the MN may change administrative domain.
i.e. move from home domain to another administrative domain (foreign
domain).  Now, please see some comments on the text proposed.

BR,
Mohana

> From: Qin Wu [mailto:[email-masked]]
> Sent: Thursday, September 10, 2009 8:30 PM
> To: Marco Liebsch; [email-masked]
> Cc: [email-masked]; Mohana Jeyatharan
> Since folks has no objection to add a section to talk about roaming
issues.
> I would like to propose
> some texts based on roaming picture proposed by Marco. The proposed
text
> is as follows:
> "
> In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs)
[Mohana: tied to a given MN]can be
> distributed into different PMIPv6 domains[Mohana: adminsitrative
domain. Example LMA placed in one administrative domain and MAG placed
in another administrative domain]. In order to support localized
> routing, it is required that MAGs to which MN and CN connect  are
within
> the same PMIPv6 domain [Mohana: within the same administrative
domain.]and each MAG setup security relationship
> respectively with corresponding LMAs which maintain specific context
to
> which MN and CN belong. It is not required that LMAs anchored by MN
and CN
> are part of PMIPv6 domain [Mohana:administrative domain] as MAGs
attached by MN and CN. MN is allowed to
> roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA
is
> located) or over different PMIPv6 domains(i.e., MN's visited domains).
[Mohana: I would say MN is allowed to roam from home adminsitartive
domain to visted administrative domain all tied to a single PMIPv6
domain of Mn] CN
> should stay with MN within the same PMIPv6 domain [Mohana:
administrative domain].  

Figure x shows PMIPv6
> roaming cases where MAGs attached by MN and CN belong to the same
PMIPv6
> domain. In this figure, four PMIPv6 roaming cases need to be taken
into
> account.
> Roaming case 1:
> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are
located
> in the same PMIPv6 domain A as described in the figure 2.
> Roaming case 2:
> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same
> PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain
B.
> Roaming case 3:
> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C
while
> MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A
> Roaming case 4:
> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C
while
> MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2)
is
> located in the PMIPv6 domain B
> 
> "
[Mohana] I think, where description is made regarding MN and CN
placement in a certain PMIPv6 domain, it is better to say in the same
administrative domain.  It is just that MN is roaming in its PMIPv6
domain and CN is roaming in its PMIPv6 domain, and local MAG routing
canbe performed when MN's MAG and CN's MAG are the same or are placed in
the same adminstrative domain.  I think such things need to be captued. 
------------------------------------------------------------------------
--
> ------
------------------------------------------------------------------------
--
> ------
> 
> If people prefer to use administrative domain, we can replace all
PMIPv6
> domain in the proposed text with *administrative domain*, Welcome your
> bash,:-)
> Regards!
> -Qin
> >> criteria for an entity (MAG/LMA) being considered being a part of
the
> PMIP6

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Sep 2009 16:21:55 +0800

Hi, Mohana:
Thank for your reply.
----- Original Message ----- 
From: "Mohana Jeyatharan" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Marco Liebsch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 15, 2009 3:45 PM
Subject: RE: [Netext] roaming issue-proposed text for roaming section

Hi Qin,

I think we should stick to the definition of PMIPv6 domain as in RFC
5213 and not change it. That is, as long as the MAG-LMA tunnel can be
created, it is considered as one PMIPv6 domain of MN. 

[Qin]: you are right, wherever MN moves around, MN does not change the PMIPv6 domain to which MN belongs,
i.e., MN's home PMIPv6 domain.

While being attached to such PMIPv6 domain, the MN may change administrative domain.
i.e. move from home domain to another administrative domain (foreign
domain).  

[Qin]: Another administrative domain you mentioned above can be viewed as MN's visited PMIPv6 domain.
that is to say, although MN changes from one visited PMIPv6 domain to another, MN does not change its home 
PMIPv6 domain, does this sounds reasonable? Anyway, you can stick to use administrative to describe roaming if
you like.

Now, please see some comments on the text proposed.

BR,
Mohana

issues.
text
> In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs)
[Mohana: tied to a given MN] 

[Qin]:Okay.

can be
domain. Example LMA placed in one administrative domain and MAG placed
in another administrative domain]. 

[Qin]: I think we have two choices to describe roaming:
1) define administrative domain 
2) Separate PMIPv6 domains into PMIPv6 home domain and PMIPv6 visited domain
Both can be used to describe roaming, in my mind.

>In order to support localized
within
to
and CN
is

domain of Mn] 

[Qin]: see above.

CN
administrative domain].  

Figure x shows PMIPv6
PMIPv6
into
located
B.
while
while
is
administrative domain.  

[Qin] I think for now some people support this, some not.

It is just that MN is roaming in its PMIPv6 domain and CN is roaming in its PMIPv6 domain, and local MAG routing
canbe performed when MN's MAG and CN's MAG are the same or are placed in
the same adminstrative domain.  I think such things need to be captued. 

[Qin] Right.

PMIPv6
the

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 15 Sep 2009 12:26:58 -0400

Hello folks,

There has been some good discussion on this topic. Here's my take to
converge and make progress.
Please read all the point below before responding.

1. We do not deviate from the definition of a PMIPv6 domain as in RFC
5213.

2. No new definitions of "domain"

3. Roaming is simply defined as "access to the Internet when the MAG and
LMA are in different provider domains"
(We do not need to explain the underlying reasons IMO. "Access to the
Internet" means the traditional connectivity via MAG and LMA as in RFC
5213; we should not delve into "service-specific" definitions here)

4. If an SA exists between a MAG and an LMA, there will be packet
forwarding (i.e., MAG and LMA can be in different provider domains)

5. We need to state somewhere that for the roaming case, localized
routing is subject to policy governing the service level agreements
between the providers. This means that merely having an SA between a
(visited) MAG and a (home) LMA does not translate to enabling localized
routing when (at least) one of the MN's is roaming.

What do you think?

Regards,

-Rajeev

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Tuesday, September 15, 2009 1:22 AM
> To: Mohana Jeyatharan; Marco Liebsch; [email-masked]
> Cc: [email-masked]
> Subject: Re: [netext] [Netext] roaming issue-proposed text 
> for roamingsection
> 
> Hi, Mohana:
> Thank for your reply.
> To: "Qin Wu" <[email-masked]>; "Marco Liebsch" 
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> [Qin]: you are right, wherever MN moves around, MN does not 
> change the PMIPv6 domain to which MN belongs,
> that is to say, although MN changes from one visited PMIPv6 
> domain to another, MN does not change its home 
> PMIPv6 domain, does this sounds reasonable? Anyway, you can 
> stick to use administrative to describe roaming if
> you like.
> 
> It is just that MN is roaming in its PMIPv6 domain and CN is 
> roaming in its PMIPv6 domain, and local MAG routing
> > >> between the MAG and LMA in the context of a PMIP6 domain 
> especially
> > when you
> > >>       management of a mobile node is handled using the 
> Proxy Mobile
> > IPv6
> > >>       protocol as defined in this specification.  The 
> Proxy Mobile
> IPv6
> > >>       authorization for sending Proxy Binding Updates on 
> behalf of
> the
> > >> does not have any references to home/visited network 
> concepts. The
> only
> > >> domain is the existence of a security association. It 
> would be good
> to

---

From: Qin Wu <[email-masked]>
Date: Wed, 16 Sep 2009 10:18:15 +0800

> routing when (at least) one of the MN's is roaming.

[Qin]:  So I think if policy governing the SLA can afffect localized routing directly,
the MN's MAG and MN's LMA should belong to different domain.
In this sense, if MN's MAG and MN's LMA are located in the same domain, SLA policy
can not affect localize routing, am I right?

Furthermore, besides SLA policy, I think there are other policies that also affect localized routing
e.g., in roaming scenario even though MAG and LMA are located in the same domain, 
having SA between MAG and LMA does not mean localized routing can be performed, 
because use of local routing may be subject to accounting and routing policies relating to the mobile node, 
, therefore localized routing signaling between MAG and LMA is required to
negotiate localized routing policy information and enable/disable localized routing. Am  I right?

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 15 Sep 2009 22:39:44 -0400

Hi,

> [Qin]:  So I think if policy governing the SLA can afffect 
> localized routing directly, the MN's MAG and MN's LMA should 
> belong to different domain.
> In this sense, if MN's MAG and MN's LMA are located in the 
> same domain, SLA policy can not affect localize routing, am I right?

Well, typically SLAs are between provider domains; at least that's how I
was referring to.

> 
> Furthermore, besides SLA policy, I think there are other 
> policies that also affect localized routing e.g., in roaming 
> scenario even though MAG and LMA are located in the same 
> domain, having SA between MAG and LMA does not mean localized 
> routing can be performed, because use of local routing may be 
> subject to accounting and routing policies relating to the 
> mobile node, , therefore localized routing signaling between 
> MAG and LMA is required to negotiate localized routing policy 
> information and enable/disable localized routing. Am  I right?
> 

Yes, localized routing is subject to policy constraints regardless of
roaming.

My point was specific to roaming when the policy allows a MAG to provide
localized routing.

I do not think we need to design signaling for exchanging this policy,
with or without roaming.
Since LMA is the control entity, we can assume it to exert such policy
control by instructing the MAG to provide localized routing.

Regards,

-Rajeev

> >> Subject: Re: [netext] [Netext] roaming issue-proposed text for 
> >> roamingsection
> >> 
> >> Hi, Mohana:
> >> Thank for your reply.
> >> [Qin]: you are right, wherever MN moves around, MN does not change 
> >> the PMIPv6 domain to which MN belongs, i.e., MN's home 
> PMIPv6 domain.
> >> 
> >> that is to say, although MN changes from one visited 
> PMIPv6 domain to 
> >> another, MN does not change its home
> >> PMIPv6 domain, does this sounds reasonable? Anyway, you 
> can stick to 
> >> use administrative to describe roaming if you like.
> >> 
> >> domain. Example LMA placed in one administrative domain and MAG 
> >> placed in another administrative domain].
> >> 
> >> 2) Separate PMIPv6 domains into PMIPv6 home domain and 
> PMIPv6 visited 
> >> domain Both can be used to describe roaming, in my mind.
> >> 
> >> > MN's LMA(LMA1) and CN's LMA(LMA2) are located in the 
> PMIPv6 domain 
> >> > A Roaming case 4:
> >> It is just that MN is roaming in its PMIPv6 domain and CN 
> is roaming 
> >> in its PMIPv6 domain, and local MAG routing canbe 
> performed when MN's 
> >> MAG and CN's MAG are the same or are placed in the same 
> adminstrative 
> >> domain.  I think such things need to be captued.
> >> 
> >> [Qin] Right.
> >> 
> >> >
> >> > > yes, agreed, that's why it has been proposed to add a 
> section on
> >> this in
> >> > > the PS. The picture
> >> > > I think it makes sense to discuss and agree on the 
> text before it
> >> goes
> >> > > to the PS draft.
> >> > >
> >> > > marco
> >> > >
> >> > >> on roaming. It would be good to have a clear 
> description of the
> >> > relationship
> >> > >> consider home and visited network scenarios wherein 
> the MAG/LMA
> >> > entities are
> >> > >> in different domains.
> >> > >>
> >> > >> criteria for an entity (MAG/LMA) being considered 
> being a part 
> >> > >> of
> >> the
> >> > PMIP6

---

From: Qin Wu <[email-masked]>
Date: Wed, 16 Sep 2009 11:01:37 +0800

Hi, 
----- Original Message ----- 
From: "Koodli, Rajeev" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 16, 2009 10:39 AM
Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection

> Well, typically SLAs are between provider domains; at least that's how I

[Qin]: I agree.

> I do not think we need to design signaling for exchanging this policy,

[Qin]: Okay, that is to say information exchange between MAG and LMA is required, 
But the information is not necessary to be taken as any policy. am I right?

> control by instructing the MAG to provide localized routing.

[Qin]: I am wondering whether instructing the MAG to or not to provide localized routing
(i.e., enable/disable localized routing) can be viewed as *policy*?

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 16 Sep 2009 10:58:46 +0200

Hi Rajeev,

thanks for your take. Please find some comments inline.

> 1. We do not deviate from the definition of a PMIPv6 domain as in RFC
Agree.
> 2. No new definitions of "domain"
Which domain? If it's PMIPv6 domain, I agree and it's covered by 1.
> LMA are in different provider domains"
Provider domain is a new term on the table in the context of this 
discussion.
Do we need to define it? Or is it clear, so we can just use it? I think 
the Provider domain
is what we so far considered as Administrative domain,.
> forwarding (i.e., MAG and LMA can be in different provider domains)
.
> routing when (at least) one of the MN's is roaming.
I think that all involved (home) LMAs needs to show green light for 
establishing localized routing
between the MNs. And what RFC5213 sais in the context of single-MAG 
local routing is, that the
LMA should control the setup. So, the LMA could initiate localized 
routing at a MAG in
the visited network. According to the policy of the visited provider 
domain, the MAG can
either accept or reject localized routing. Localized routing will be 
successful when both LMAs
and both MAGs accept localized routing.

For the protocol spec, I think we just need to consider status codes 
which allow LMAs/MAGs
to *negative ack* a request to establish locaized routing. That reflects 
the SLAs on the
mobility protocol layer. I don't think that the localized routing 
protocol needs to handle SLAs
itself.

Hope that makes sense.

marco

>>> Subject: Re: [Netext] roaming issue-proposed text for 
>>>       
>> roaming section
>>     
>>> Hi, all:
>>> distributed into different PMIPv6 domains
>>>       
>> [Mohana: adminsitrative
>>> roam within its PMIPv6 domain (i.e, MN's home domain in 
>>>       
>> which MN's LMA
>> is
>>     
>>> located) or over different PMIPv6 domains(i.e., MN's 
>>>       
>> visited domains).
>>
>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located 
>>>       
>> in the same
>>     
>>> PMIPv6 domain A while CN's LMA(LMA2') is located in the 
>>>       
>> PMIPv6 domain
>> B.
>>     
>>> Roaming case 3:
>>> domain in the proposed text with *administrative domain*, 
>>>       
>> Welcome your
>>     
>>> bash,:-)
>>> Regards!
>>> -Qin
>>> Subject: Re: [netext] [Netext] localized route optimization 
>>>       
>> - roaming
>>     
>>> issue
>>>
>>>
>>>       
>>>> Hi Raj,
>>>>
>>>> yes, agreed, that's why it has been proposed to add a section on
>>>>         
>> this in
>>     
>>>> the PS. The picture
>>>> could be based on what I sent some mails ago. We're currently
>>>>         
>> preparing
>>     
>>>> some text, but
>>>> I think it makes sense to discuss and agree on the text before it
>>>>         
>> goes
>>     
>>>> to the PS draft.
>>>>
>>>> marco
>>>>
>>>>> One of the issues that we got hung up at IETF75 during the LR
>>>>>           
>>> discussion was
>>>       
>>>>> on roaming. It would be good to have a clear description of the
>>>>>           
>>> relationship
>>>       
>>>>> consider home and visited network scenarios wherein the MAG/LMA
>>>>>           
>>> entities are
>>>       
>>>>> in different domains.
>>>>>
>>>>>       Proxy Mobile IPv6 domain refers to the network where the
>>>>>           
>> mobility
>>     
>>>>>       domain includes local mobility anchors and mobile access
>>>>>           
>> gateways
>>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 16 Sep 2009 12:13:55 +0200

Hi Qin,

please see inline for my view.

> But the information is not necessary to be taken as any policy. am I right?
I don't think the protocol should not be used to echange policies, which 
even does not make
sense to me to transfer e.g. provider policies beyond domains, as the 
remote provider may
have different policies. I think components (LMA, MAG) must operate 
according to their
provider's policy and the protocols should just reflect the policy by 
means of requests
to set up localized routing, which can be accepted or not and indicated 
accordingly in a
status/reason code.

> (i.e., enable/disable localized routing) can be viewed as *policy*?
I think it's more that the LMA acts according to it's operator's policy. 
If the policy does not permit
localized routing, the LMA would not send the request. The 
instruction/request itself does not
convey policies, as I understand from your question. This is my view.

marco

>>>>> Subject: RE: [Netext] roaming issue-proposed text for 
>>>>>           
>>> roaming section
>>>       
>>>>> Hi Qin,
>>>>>
>>>>> I think we should stick to the definition of PMIPv6 domain 
>>>>>           
>>> as in RFC
>>>       
>>>>> 5213 and not change it. That is, as long as the MAG-LMA 
>>>>>           
>>> tunnel can be 
>>>       
>>>>> i.e. move from home domain to another administrative 
>>>>>           
>>> domain (foreign 
>>>       
>>>>> domain).
>>>>>
>>>>>> Since folks has no objection to add a section to talk 
>>>>>>             
>>> about roaming
>>>       
>>>>> issues.
>>>>>           
>>>>>> I would like to propose
>>>>>> some texts based on roaming picture proposed by Marco. 
>>>>>>             
>>> The proposed
>>>       
>>>>> text
>>>>>           
>>>>>> is as follows:
>>>>>> "
>>>>>> In the real PMIPv6 deployment, PMIPv6 components(e.g., 
>>>>>>             
>>> LMAs, MAGs)
>>>       
>>>>>> which MN and CN belong. It is not required that LMAs 
>>>>>>             
>>> anchored by MN
>>>       
>>>>> and CN
>>>>>           
>>>>> [Mohana: I would say MN is allowed to roam from home 
>>>>>           
>>> adminsitartive 
>>>       
>>>>>> domain. In this figure, four PMIPv6 roaming cases need 
>>>>>>             
>>> to be taken
>>>       
>>>>> into
>>>>>           
>>>>>> account.
>>>>>> Roaming case 1:
>>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the 
>>>>>>             
>>> PMIPv6 domain C
>>>       
>>>>> while
>>>>>           
>>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the 
>>>>>>             
>>> PMIPv6 domain C
>>>       
>>>>> while
>>>>>           
>>>>> placement in a certain PMIPv6 domain, it is better to say 
>>>>>           
>>> in the same 
>>>       
>>>>> administrative domain.
>>>>>

---

From: Qin Wu <[email-masked]>
Date: Wed, 16 Sep 2009 20:23:29 +0800

Hi, Marco:
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Koodli, Rajeev" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 16, 2009 6:13 PM
Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection

> to set up localized routing, which can be accepted or not and indicated 
[Qin]: Right, that is to say, policy from different providers may affect localized routing, 
but it is not necessary to be reflected in the protocol design. policy enforcement information or  instructions
can be encapsulated in the localized routing signaling to indicate results to the MAGs.
Whether we use status or reason code, it depends on specific the implementation. 
> convey policies, as I understand from your question. This is my view.

[Qin]: Well,  I agree it is not policies but policies enforcement results that need to be exchanged.

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 16 Sep 2009 12:12:28 -0400

> [Qin]: Okay, that is to say information exchange between MAG 
> and LMA is required, But the information is not necessary to 
> be taken as any policy. am I right?

Not sure what you mean. The signaling is for establishing localized
routing, which is subject to policy constraints.
We do not design policy exchange signaling here. 
 
> [Qin]: I am wondering whether instructing the MAG to or not 
> to provide localized routing (i.e., enable/disable localized 
> routing) can be viewed as *policy*?

The trigger for LMA to initiate LR could be policy, yes.

-Rajeev

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 16 Sep 2009 12:22:41 -0400

Hi,

> Which domain? If it's PMIPv6 domain, I agree and it's covered by 1.

Any domain. We should not be re-inventing any domain definitions. 

> > 3. Roaming is simply defined as "access to the Internet when the MAG

> > and LMA are in different provider domains"
> >   
> Provider domain is a new term on the table in the context of 
> this discussion.
> Do we need to define it? Or is it clear, so we can just use 
> it? I think the Provider domain is what we so far considered 
> as Administrative domain,.

I see your point. Provider domain is what belongs to a provider. It is
most relevant for roaming.
I am okay if you state it. 

> > (visited) MAG and a (home) LMA does not translate to enabling 
> > localized routing when (at least) one of the MN's is roaming.
> >   
> I think that all involved (home) LMAs needs to show green 
> light for establishing localized routing between the MNs. And 
> what RFC5213 sais in the context of single-MAG local routing 
> is, that the LMA should control the setup. So, the LMA could 
> initiate localized routing at a MAG in the visited network. 
> According to the policy of the visited provider domain, the 
> MAG can either accept or reject localized routing. Localized 
> routing will be successful when both LMAs and both MAGs 
> accept localized routing.

Agree to LMA initiating the LR.

Policy is not limited to visited network only (this is not a protocol
issue for us BTW).
The home LMA may not initiate LR if the policy does not allow. 

> 
> For the protocol spec, I think we just need to consider 
> status codes which allow LMAs/MAGs to *negative ack* a 
> request to establish locaized routing. That reflects the SLAs 
> on the mobility protocol layer. I don't think that the 
> localized routing protocol needs to handle SLAs itself.
> 

Agree, the LR design itself should not deal with any SLAs.

-Rajeev

> PMIPv6 domain A

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 17 Sep 2009 08:10:35 +0800

Hi Rajeev,

Please see some of my comments.

Thanks.

BR,
Mohana

Behalf
> Of Koodli, Rajeev
> Sent: Wednesday, September 16, 2009 12:27 AM
> To: [email-masked]

Yes, we should not redefine this for local MAG routing. The same
definition must be used.

> 2. No new definitions of "domain"

Yes, this need not be redefined as well.  It refers to administrative
domain and it is well known.

> 3. Roaming is simply defined as "access to the Internet when the MAG
and
> 5213; we should not delve into "service-specific" definitions here)

Well, the definition is ok. It is something like roaming across
adminsitrative domains while being connected to ones PMIPv6 domain.

> forwarding (i.e., MAG and LMA can be in different provider domains)

This is essential, otherwise we may not be able to implement local MAG
routing.  (Unless there are ways to implmenet it without any LMA
support!
I means MN's MAG and CN'sMAG identify each other independently)

> (visited) MAG and a (home) LMA does not translate to enabling
localized
> routing when (at least) one of the MN's is roaming.

Agree, already some of the solution drafts are mentioning such things
and policy is essential to enable localized routing.  Probably
mentioning itsomewhere in the PS would be good.  But, is there a need to
mention only in roaming case.  I guess, even in the home or non-roaming
case, some policy needs to be activated.  Ofcourse at home, since all
entities belong to same admin domain, an explict policy may not be
needed.  It all depends on LMAs decision.  

Such capturing is sufficient and we can make progress in the PS
document.
> > domain. Example LMA placed in one administrative domain and MAG
placed

---

From: Qin Wu <[email-masked]>
Date: Thu, 17 Sep 2009 09:01:24 +0800

Hi,
----- Original Message ----- 
From: "Koodli, Rajeev" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 17, 2009 12:12 AM
Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection

> We do not design policy exchange signaling here. 

[Qin]: That's what I understand. 
Actually policies can be exchanged through out of band signaling ,e.g.,AAA signaling.

> The trigger for LMA to initiate LR could be policy, yes.

[Qin]: Agree.

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 18 Sep 2009 17:57:51 -0400

So, when could we have a new version available?

I also remember from the meeting that we are not going to have private
IPv4 address support, NAT traversal etc. 

Thanks,

-Rajeev

> Sent: Wednesday, September 16, 2009 3:14 AM
> To: Qin Wu
> Cc: Koodli, Rajeev; [email-masked]
> >>> [Qin]:  So I think if policy governing the SLA can 
> afffect localized 
> >>> routing directly, the MN's MAG and MN's LMA should belong to 
> >>> different domain.
> >>> In this sense, if MN's MAG and MN's LMA are located in the same 
> >>> domain, SLA policy can not affect localize routing, am I right?
> >>>       
> >> Well, typically SLAs are between provider domains; at least that's 
> >> how I was referring to.
> >>     
> >
> > [Qin]: I agree.
> >
> >   
> >>> Furthermore, besides SLA policy, I think there are other policies 
> >>> that also affect localized routing e.g., in roaming scenario even 
> >>> though MAG and LMA are located in the same domain, having 
> SA between 
> >>> MAG and LMA does not mean localized routing can be performed, 
> >>> because use of local routing may be subject to accounting and 
> >>> routing policies relating to the mobile node, , therefore 
> localized 
> >>> routing signaling between MAG and LMA is required to negotiate 
> >>> localized routing policy information and enable/disable localized 
> >>> routing. Am  I right?
> >>>
> >>>       
> >> My point was specific to roaming when the policy allows a MAG to 
> >> provide localized routing.
> >>
> >> I do not think we need to design signaling for exchanging this 
> >> policy, with or without roaming.
> >>     
> >
> > [Qin]: Okay, that is to say information exchange between 
> MAG and LMA 
> > is required, But the information is not necessary to be 
> taken as any policy. am I right?
> >   
> I don't think the protocol should not be used to echange 
> policies, which even does not make sense to me to transfer 
> e.g. provider policies beyond domains, as the remote provider 
> may have different policies. I think components (LMA, MAG) 
> must operate according to their provider's policy and the 
> protocols should just reflect the policy by means of requests 
> to set up localized routing, which can be accepted or not and 
> indicated accordingly in a status/reason code.
> 
> >   
> to provide localized routing

---

From: Qin Wu <[email-masked]>
Date: Sat, 19 Sep 2009 09:05:56 +0800

Hi, Koodli:
Probably will publish the first draft by the end of this week, Marco will do this.

Regards!
-Qin
----- Original Message ----- 
From: "Koodli, Rajeev" <[email-masked]>
To: "Marco Liebsch" <[email-masked]>; "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, September 19, 2009 5:57 AM
Subject: RE: [netext] [Netext] roaming issue-proposed text for roamingsection

Thanks,

-Rajeev

> >>>>>>>> elaborate how this maps to the current discussion in LR.

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.