Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt

From: Marco Liebsch <[email-masked]>
Date: Thu, 19 Nov 2009 18:16:42 +0100

Hi Mohana,

thanks again for your comments. All of them are valuable and, as said during
last week's meeting, we'll take them in the next update into account.
Please see in-line for specific feedback.

Mohana Jeyatharan schrieb:
>
> Hi all,
>
>  
>
> I went through the draft and have few comments.
>
>  
>
>  
>
> 1)Introduction first para says
>
> " Even though two communicating MNs might be attached to the
>
>    same MAG or to different MAGs of the same local mobility domain,
>
>    packets will traverse the MNs' LMA(s)."
>
> [Mohana] Mn and CN may be better word. Bcos later in draft communication
>
> End points are defined as MN and CN.
>
Yes, definitely we should keep this consistent.

>  
>
> 2)Introduction second para says
>
> " Objectives of designing a solution for localized routing in PMIPv6
>
>    are to specify protocol messages and enable associated protocol
>
>    operation between PMIPv6 components to support the set up of a direct
>
>    routing path for data packets between the MNs' MAGs without
>
>    forwarding these packets through the MNs' LMA(s) and to maintain
>
>    localized routing in case one or both MNs handover to a different
>
>    MAG."
>
>  
>
> [Mohana] Here again it says that direct path between MN's MAGs.  I 
> think it is between Mn's MAG and CN's MAG.  
>
True.

>  
>
> 3)In the conventions and terminology section
>
>  
>
> The second bullet:
>
>  
>
> Correspondent Node (CN): Correspondent Node with or without IP
>
>       mobility support.  The CN represents the communication peer of an
>
>       MN, which is attached to a MAG and registered with an LMA
>
>       according to the PMIPv6 specification.
>
>  
>
> [Mohana]The usage of "an" in front of MN and LMA should be changed to a.
>
Ok.

>  
>
> 4)In the conventions and terminology section
>
>  
>
> The third bullet: there is mentioning about a single PMIPv6 domain.
>
> [Mohana] Is it MN and CN placed in single operator/provider domain 
> running PMIPv6?
>
Yes, true. This is still from the previous understanding of the 
localized routing scope.
We'll update the description.

>  
>
> 5)In the conventions and terminology section
>
> Fourth bullet mentions about IDs
>
>  
>
> [Mohana] Is it only ID? What other information stored.  What are these 
> IDs?
>
> Perhaps a description will be good.
>
One example could be the MNID as per RFC5213, which is stored together with
localized routing states. Could also be localized routing specific IDs 
which serve
as a key to the MN's states, but we should not assume anything from a 
solution
here. So, do you think describing the MNID as specific example is 
sufficient?

>  
>
> 6)In section 3.1 general observation section 1st para
>
>  
>
> " Following the architecture of PMIPv6, rather entities of the network
>
>    infrastructure are dedicated to perform signaling to set up a more
>
>    direct route between an MN and a CN."
>
>  
>
> [Mohana] I am not sure the meaning of this.  Does it mean that when 
> PMIP is present, RO needs to be established by using signaling between 
> network entities? Perhaps a rewording is useful.
>
It means that MNs cannot perform mobility signaling as per requirement 
of NetLMM, which applies
also for localized routing set up. The paragraph just explains that 
network components, most probably
PMIPv6 specific components (MAG, LMA) need to take over this 
responsibility and perform signaling
to set up a MN's localized routing path.

I'll try to find better wording, assumed you agree to the explanation above.

>  
>
> 7)In section 3.1 general observation section last paragraph
>
> [Mohana] It is mentioned two benefits of loacl MAG routing.There is 
> mentioning about lower cost, lower delay, lower packet loss.  But 
> clear indication as to the two benefits was not present.
>
They're in, but not so obvious, as I must admit. One is the costs aspect 
(MAG-LMA
more costly), the other is the benefit for the user (delay). I'll write 
to find clearer text.

>  
>
> 8) In section 3.2 all mentioning is about "PMIPv6 domain".  
>
> [Mohana] I do not want to start the discussion again. But, isn't it 
> better to say what this PMIPv6 domain is. MN and CN in same operator 
> domain or something like that. Bcos there is another section on 
> roaming which is different from this.
>
Yes, same as above and still not yet updated in this version.
Thanks for the hint, we'll rewrite this for the update.

>  
>
> 9) [Mohana]Again in section 3.2, there is mentioning about some race 
> issue in multiple LMA
>
> Case, when there is handoff.  But no clear description of such issue 
> is highlighted. A small description will be good.
>
Ok, I'll add text here.

>  
>
> 10) In section 3.2, the local MAG issues are highlighted into 
> cases(case A11, A..) and again some issues (multiple LMA, handoff in 
> multiple LMA) are captured in bullet form.  I am not sure whether 
> there are any overlap in text here.
>
Maybe there is some overlap. A11 etc. analyze issues that come with a 
particular
topology (multi-LMA etc). The bullet list summarizes general problems, 
which may
also cover one or the other issue from above. I think it makes sense to have
problems summarized in one place, even though they may appear at a different
place already with details about where the problem comes from.

>  
>
> 11)Section on IPv4 considerations. I think the current text is fine. 
>  It is not too complex and highlights how local MAG routing canbe done 
> when there is IPv4 HoA or IPv4 transport.
>
Ok, thanks. Your review is based on version 00. For the latest update, 
we had to
remove the NAT and the private IPv4 address conflict,.as the solution 
will not
address them. Hope the text is still clear in version1.

Thanks and best regards,
marco

> BR,
> Mohana

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 20 Nov 2009 11:22:47 +0800

Hi Marco,

Thanks for reply. Please see few minor comments in line.

BR,
Mohana

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Marco Liebsch
> Sent: Friday, November 20, 2009 1:17 AM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-
> 00.txt
> 
> Hi Mohana,
> 

[Mohana] Here my initial thinking was, if it is a mobile node and a
local mobility anchor then the usage of a appropriate.  But if you
consider it as a MN(making sound "em") and LMA(making sound "el"), then
usage of an is also possible.
So, I will leave it to your'll to decide.
> here. So, do you think describing the MNID as specific example is
[Mohana] Probably MNID as defined in RFC 5213 will suffice.  But I 
Think some more parameters are needed in the MAG.  Such as CN prefix and
CN MAG address. I leave it to your'll to decide whether this needs to be
captured in conventions and terminology section.  When we are talking
about routing state, then probably these needs to be captured as well.

> I'll try to find better wording, assumed you agree to the explanation
[Mohana] Ok, thanks.  Marco I understood your intention but the wording
was not clear when I read.  As you mentioned a re-wording might be
useful.

> > is highlighted. A small description will be good.

[Mohana] Thanks.  Going through the solution drafts we have, I could not
find clear description of the racing issue.  Perhaps your solution draft
covered this.
> also cover one or the other issue from above. I think it makes sense
to
> have
[Mohana] Ok, thanks. That is good.
> address them. Hope the text is still clear in version1.
[Mohana] Saw some text removal in the revised version.  I will wait for
the revised version.

> Thanks and best regards,
> marco
> 
> >
> >
> > BR,
> >
> > Mohana
> >
> >
> >
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 20 Nov 2009 11:09:15 +0100

Hi Mohana,

please see in-line.

Mohana Jeyatharan wrote:
>>> [Mohana] Mn and CN may be better word. Bcos later in draft
>>>       
> communication
>   
>>>    operation between PMIPv6 components to support the set up of a
>>>       
> direct
>   
>>>       mobility support.  The CN represents the communication peer of
>>>       
> an
>   
>>> [Mohana]The usage of "an" in front of MN and LMA should be changed
>>>       
> to a.
>   
>> Ok.
>>     
>
Since it's abbreviated, I thought s about the latter one :-)

>>> [Mohana] Is it only ID? What other information stored.  What are
>>>       
> these
>   
>>> IDs?
>>>
Of course prefixes are needed, but I did not consider them to
be IDs. The term section was just to provide examples what we
mean with localized routing states. But I agree that it's obvious
to have prefixes and tunnel endpoints (MAGs) in the conceptual
data structures to maintain localized routing states, I can add
them for clarification. Thanks. for the hint.
>>> " Following the architecture of PMIPv6, rather entities of the
>>>       
> network
>   
>>>    infrastructure are dedicated to perform signaling to set up a
>>>       
> more
>   
>>> PMIP is present, RO needs to be established by using signaling
>>>       
> between
>   
yes.
>> They're in, but not so obvious, as I must admit. One is the costs
>>     
> aspect
>   
>> (MAG-LMA
>> more costly), the other is the benefit for the user (delay). I'll
>>     
> write
>   
>> to find clearer text.
>>
>>     
Just assume MN is attached to MAG1 and CN is attached to MAG2.
MAGs have a direct tunnel for localized routing established. If MN
moves to MAG1* and CN moves to MAG2*, each side does not
know about the other side's move. Hence, dependent on signaling
operation, MAG1/MAG1* may try to update MAG2 according to
MN1's move, even though CN moved to MAG2*. Same applies to
the other direction. This is what I mean with race condition and
these things could be resolved by a kind of rendezvous point.

>>>  It is not too complex and highlights how local MAG routing canbe
>>>       
> done
>   
Ok.

Thanks,
marco

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 20 Nov 2009 18:35:34 +0800

Hi Marco,

Thanks for reply. Pease see replies below.

BR,
Mohana

> From: Marco Liebsch [mailto:[email-masked]]
> Sent: Friday, November 20, 2009 6:09 PM
> To: Mohana Jeyatharan
> Cc: Marco Liebsch; [email-masked]
> >> thanks again for your comments. All of them are valuable and, as
said
> >> during
> >> One example could be the MNID as per RFC5213, which is stored
together
> >> with

[Mohana] Ok, this is not a major thing.  But if possible some inclusion
will be good.
> >> I'll try to find better wording, assumed you agree to the
explanation
> >> above.
[Mohana] ok, looking at this I was reminded of the simultanoeus mobility
issue that was presented in the MEXT wg.  I think there is similarity
here bcos the upadtes goes to wrong nodes.