Re: [Gen-art] Gen-art review of draft-ietf-dime-pmip6-lr-07

[Qin Wu <[e-mail]>]

Okay, many thanks to your valuable review.

Regards!
-Qin
----- Original Message ----- 
From: "Elwyn Davies" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "General Area Review Team" <[e-mail]>; <[e-mail]>
Sent: Wednesday, February 08, 2012 8:28 PM
Subject: Re: [Gen-art] Gen-art review of draft-ietf-dime-pmip6-lr-07


> Hi, Qin.
> 
> Fine - I think all will be good from my point of view if you say a few
> words about linking the MAGs as per your last response belwow.
> 
> Cheers,
> Elwyn
> 
> On Wed, 2012-02-08 at 19:47 +0800, Qin Wu wrote:
>> Hi, Elwyn:
>> Thank for your followup comments, please see my replies inline.
>> 
>> Regards!
>> -Qin
>> ----- Original Message ----- 
>> From: "Elwyn Davies" <[e-mail]>
>> To: "Qin Wu" <[e-mail]>
>> Cc: "General Area Review Team" <[e-mail]>; <[e-mail]>
>> Sent: Wednesday, February 08, 2012 6:58 PM
>> Subject: Re: [Gen-art] Gen-art review of draft-ietf-dime-pmip6-lr-07
>> 
>> 
>> > Hi, Qin.
>> > 
>> > Thanks for your quick reponse.. some comments in line (I have deleted
>> > the bits agreed),
>> > 
>> > /Elwyn
>> > 
>> > On Fri, 2012-02-03 at 12:53 +0800, Qin Wu wrote:
>> >> Hi,Elwyn:
>> >> Thank for your valuable review. please see our replies below.
>> >> ----- Original Message ----- 
>> >> From: "Elwyn Davies" <[e-mail]>
>> >> To: "General Area Review Team" <[e-mail]>
>> >> Cc: <[e-mail]>
>> >> Sent: Thursday, February 02, 2012 9:06 PM
>> >> Subject: Gen-art review of draft-ietf-dime-pmip6-lr-07
>> >> 
>> >> 
>> >> >I am the assigned Gen-ART reviewer for this draft. For background on
>> >> > Gen-ART, please see the FAQ at
>> >> > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> >> > 
>> >> > Please wait for direction from your document shepherd
>> >> > or AD before posting a new version of the draft.
>> >> > 
>> >> > Document: draft-ietf-dime-pmip6-lr-07.txt
>> >> > Reviewer: Elwyn Davies
>> >> > Review Date: 2 February 2012
>> >> > IETF LC End Date: 24 January 2012
>> >> > IESG Telechat date: 16 February 2012
>> >> > 
>> >> > Summary:
>> >> > I have a couple of queries/minor issues regarding checking whether LMA1
>> >> > and LMA2 are the same node and some hand waving over the idea of
>> >> > 'localized routing setup/signaliing'.  There are also a few minor nits.
>> >> > Otherwise this is ready for the IESG.
>> >> > 
>> >> > [This document missed the normal gen-art last call allocation
>> >> > notification mechanism for some reason - so I didn't realize it was on
>> >> > my allocation till the end of last call and as a result the review is a
>> >> > bit late.]
>> >> > 
>> >> > Major issues:
>> >> > None
>> >> > 
>> >> > Minor issues:
>> >> > s5.1, para 3 and s5.2, last para:
>> >> > In s5.1:
>> >> >> MAG1 can verify
>> >> >>    whether both MAGs are under the same LMA by comparing the addresses
>> >> >>    of LMA1 and LMA2.
>> >> > Is this guaranteed to work?  Should we care? Or is this just too bad if
>> >> > the LMA has multiple addresses and the two MNs have different ideas?
>> >> 
>> >> [Qin]: In the example described in the s5.1, we don't consider one LMA has two LMA address.
>> >> LMA1 and LMA2 may represent two different mobility entities identified by LMA1 adress and LMA2 adress respectively.
>> >> If LMA1 address is LMA2 address, this just indicate LMA1 and LMA2 are the same mobility entity.
>> >> Even one LMA have more than one LMA address, this still work since MAG can know if these LMA addresses come from
>> >> the same mobility entity based on MN1 and MN2's binding update list.
>> >> 
>> >> > However in s5.2:
>> >> >> In the case where MNs share the same LMA, LR should be initiated by
>> >> >>    LMA1 (i.e.,LMA2) since only LMA1 knows that both MN1 and MN2 belong
>> >> >>    to itself by looking up the binding cache entries corresponding to
>> >> >>    MN1 and MN2. 
>> >> > I am unsure whether these two statements are talking about the same
>> >> > thing - and, if so, are they contradictory?
>> >> > 
>> >> 
>> >> [Qin]: No Confliction, See above.
>> > 
>> > I think this is exactly the point: You give two different (but allegedly
>> > non-conflicting ways) of doing the same thing at two places in the
>> > draft.  From what you say, I infer that you could do either thing in
>> > both cases. If so then it would be better to give the alternatives
>> > together for the first case and refer to the previous comments when the
>> > second case is reached in the text.
>> 
>> [Qin]: Good suggestion and will follow this.
>> > 
>> >> 
>> >> > s5.1, last para:
>> >> >> Figure 4 shows another example scenario, similar to the example
>> >> >>    scenario illustrated in Figure 3, LMA1 does not respond to MAG1 with
>> >> >>    the address of LMA2, instead setting up a localized routing path
>> >> >>    directly between itself and LMA2 via localized routing signaling.
>> >> > I am unsure what 'localized routing signaliing' would involve.  What
>> >> > would the nodes do for this?  Appears to involve some waving of hands.
>> >> 
>> >> [Qin]: LMA1 and LMA2 exchange to trigger corresponding LMA to setup binding entries
>> >> on the correspoding MAG for localized routing and establish localized
>> >> routing path between MAG1 and MAG2.
>> >> 
>> >> > On a slightly broader point, there are a number of places where the
>> >> > phrase 'localized routing setup' (or similar) is used.  It would, I
>> >> > think, be useful to add a few words indicating what is thought to be
>> >> > involved although actually doing it is clearly out of scope of this
>> >> > document.
>> >> 
>> >> [Qin]: Okay.
>> > 
>> > I am afraid this doesn't really help: You say 'establish localized
>> > routing path between MAG1 and MAG2'. How? Does this imply that the MAG
>> > or some other component will (re-)configure the local packet routing
>> > infrastructure? (Not something I would expect the MAG to be authorized
>> > to do.) Or is this a matter of creating a tunnel?  I think this needs to
>> > be a whole lot more concrete - both ends have to be expecting the
>> > packets and know what to do with them.
>> 
>> [Qin]: Yes, your are right. Tunneling between MAG1 and MAG2 should be configured on both MAGs.
>> As default static behavior,tunnel between MAG1 and MAG2 uses the same encapsulation mechanism
>> as that being used for PMIP tunnel between MAG and LMA. In this case, MAG1 and MAG2
>> can start using the same tunneling mechanism without special configuration (e.g.using other 
>> tunnel mechanism that is uniform in the PMIP domain) on MAGs or dynamic tunneling negotiation between MAGs.
>> but special configuration on MAGs or dynamic tunnel negotiation can overide 
>> the default static behavior mentioned above if they are really needed.
>> 
>> Hope this clarifies.
>> 
>> > Regards,
>> > Elwyn  
>> > 
>> >
>