[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [netext] [Netext] roaming issue-proposed text for roamingsection

Hi Qin,

please see inline for my view.

Qin Wu schrieb:
Hi, ----- Original Message ----- From: "Koodli, Rajeev" <rkoodli at starentnetworks.com> 
To: <netext at ietf.org>
Sent: Wednesday, September 16, 2009 10:39 AM
Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection



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.


[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? 


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.
[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.


Since LMA is the control entity, we can assume it to exert such policy
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*?
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


Regards,

-Rajeev




What do you think?

Regards,

-Rajeev






-----Original Message-----
From: netext-bounces at ietf.org
[mailto:netext-bounces at ietf.org] On Behalf Of Qin Wu
Sent: Tuesday, September 15, 2009 1:22 AM
To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil at nokia.com
Cc: netext at ietf.org
Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 

Hi, Mohana:
Thank for your reply.
----- Original Message -----
From: "Mohana Jeyatharan" <Mohana.Jeyatharan at sg.panasonic.com>
To: "Qin Wu" <sunseawq at huawei.com>; "Marco Liebsch" <liebsch at nw.neclab.eu>; <Basavaraj.Patil at nokia.com> 
Cc: <netext at ietf.org>
Sent: Tuesday, September 15, 2009 3:45 PM
Subject: RE: [Netext] roaming issue-proposed text for 
roaming section

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.
[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


-----Original Message-----
From: Qin Wu [mailto:sunseawq at huawei.com]
Sent: Thursday, September 10, 2009 8:30 PM
To: Marco Liebsch; Basavaraj.Patil at nokia.com
Cc: netext at ietf.org; Mohana Jeyatharan
Subject: Re: [Netext] roaming issue-proposed text for

roaming section

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)

[Mohana: tied to a given MN]

[Qin]:Okay.

can be

distributed into different PMIPv6 domains

[Mohana: adminsitrative
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
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] 

[Qin]: see above.

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.

[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.
-------------------------------------------------------------- 
----------
--

------



                                    |
          +-----+       +-----+     |      +-----+
          |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
----- Original Message -----
From: "Marco Liebsch" <liebsch at nw.neclab.eu>
To: <Basavaraj.Patil at nokia.com>
Cc: <netext at ietf.org>; <Mohana.Jeyatharan at sg.panasonic.com>
Sent: Wednesday, September 09, 2009 11:07 PM
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

Basavaraj.Patil at nokia.com wrote:

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

_______________________________________________
netext mailing list
netext at ietf.org
https://www.ietf.org/mailman/listinfo/netext


_______________________________________________
netext mailing list
netext at ietf.org
https://www.ietf.org/mailman/listinfo/netext

_______________________________________________
netext mailing list
netext at ietf.org
https://www.ietf.org/mailman/listinfo/netext

_______________________________________________
netext mailing list
netext at ietf.org
https://www.ietf.org/mailman/listinfo/netext

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.