You should make them when the sponsoring AD indicates. I do not know if other changes are expected based on other reviews.
Russ On Feb 12, 2012, at 5:32 PM, Qin Wu wrote: > Hi, Russ: > Should I address these comments before IESG telechat? > My response may be limited due to business trip in my next week. Here is my > proposed changes to version 07. > > 1.Section 5.1, 3rd paragraph, last sentence. > OLD text: > " > MAG1 can verify > whether both MAGs are under the same LMA by comparing the addressese > of LMA1 and LMA2. MAG1 then requests the address of MAG2 from LMA2 > and uses that address to setup the localized routing path between > itself and MAG2 via a Proxy Binding Update (PBU)/Proxy Binding > Acknowledgement (PBA) message exchange [RFC5213]. > " > NEW text: > " > If MAG1 knows that MN1 and MN2 belong to the same LMA, it requests the > address of MAG2 from LMA2 > and uses that address to setup the localized routing path between > itself and MAG2 via a Proxy Binding Update (PBU)/Proxy Binding > Acknowledgement (PBA) message exchange [RFC5213], Note that whether MN1 > and MN2 belong to the same LMA can be verified by looking up the binding > cache entries corresponding to > MN1 and MN2 and comparing the addresses of LMA1 and LMA2. > " > 2. Section 5.2, Last Paragraph, 1st sentence > OLD text: > " > 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. > " > New text: > " > 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 the same LMA in accordance with the verification principle specified in > the section 5.1. > " > 3. Section 5.1, Last Paragraph > OLD text: > " > .....instead setting up a localized routing path > directly between itself and LMA2 via localized routing signaling. > " > New Text: > " > ... instead initiating LMA1 and LMA2 exchange to trigger corresponding LMA to > setup binding entries > on the corresponding MAG for localized routing and configuring MAG1 and MAG2 > to use the same encapsulation mechanism as that > being used for PMIP tunnel between MAG and LMA without special configuration > or dynamic tunneling negotiation between MAGs. > Alternatively special configuration for other encapsulation mechanism or > dynamic tunneling negotiation may be used to override > the default tunneling. > > " > > Regards! > -Qin > ________________________________________ > 发件人: Russ Housley [hous...@vigilsec.com] > 发送时间: 2012年2月13日 5:22 > 到: Qin Wu > Cc: General Area Review Team; draft-ietf-dime-pmip6-lr....@tools.ietf.org; > Elwyn Davies > 主题: Re: [Gen-art] Gen-art review of draft-ietf-dime-pmip6-lr-07 > > 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" <elw...@dial.pipex.com> >>> To: "Qin Wu" <bill...@huawei.com> >>> Cc: "General Area Review Team" <gen-art@ietf.org>; >>> <draft-ietf-dime-pmip6-lr....@tools.ietf.org> >>> 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" <davie...@scss.tcd.ie> >>>>> To: "General Area Review Team" <gen-art@ietf.org> >>>>> Cc: <draft-ietf-dime-pmip6-lr....@tools.ietf.org> >>>>> 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 >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
