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" <rkoodli at starentnetworks.com> To: "Marco Liebsch" <marco.liebsch at nw.neclab.eu>; "Qin Wu" <sunseawq at huawei.com> Cc: <netext at ietf.org> Sent: Saturday, September 19, 2009 5:57 AM Subject: RE: [netext] [Netext] roaming issue-proposed text for roamingsection 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 > -----Original Message----- > From: Marco Liebsch [mailto:marco.liebsch at nw.neclab.eu] > Sent: Wednesday, September 16, 2009 3:14 AM > To: Qin Wu > Cc: Koodli, Rajeev; netext at ietf.org > Subject: 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 > > > > > 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 postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.