The -07 version of this document is on the IESG telechat this week. How will the agreed changes be made?
Russ On Feb 8, 2012, at 7:28 AM, Elwyn Davies wrote: > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
