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 > > > > >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.