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" <[email protected]> > To: "Qin Wu" <[email protected]> > Cc: "General Area Review Team" <[email protected]>; > <[email protected]> > 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" <[email protected]> > >> To: "General Area Review Team" <[email protected]> > >> Cc: <[email protected]> > >> 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 > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
