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

[Marco Liebsch <[e-mail]>]

Hi Mohana,

please see in-line.

Mohana Jeyatharan wrote:
> Hi Marco,
>
> Thanks for reply. Please see few minor comments in line.
>
> BR,
> Mohana
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>>     
> Behalf
>   
>> Of Marco Liebsch
>> Sent: Friday, November 20, 2009 1:17 AM
>> To: Mohana Jeyatharan
>> Cc: [e-mail]
>> Subject: Re: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-
>> 00.txt
>>
>> 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.
>>     
>
> [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.
>   
Since it's abbreviated, I thought s about the latter one :-)

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

>>> 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.
>>
>>     
> [Mohana] Ok, thanks. That is good.
>   
>>> 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.
>>     
> [Mohana] Saw some text removal in the revised version.  I will wait for
> the revised version.
>   
Ok.

Thanks,
marco

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