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

Russ Housley <housley@vigilsec.com> Mon, 13 February 2012 22:52 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0189F21E8010 for <gen-art@ietfa.amsl.com>; Mon, 13 Feb 2012 14:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.039
X-Spam-Level:
X-Spam-Status: No, score=-100.039 tagged_above=-999 required=5 tests=[AWL=-2.496, BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwK8XNM3Ji+q for <gen-art@ietfa.amsl.com>; Mon, 13 Feb 2012 14:52:47 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7621F84C8 for <gen-art@ietf.org>; Mon, 13 Feb 2012 14:52:46 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id EA01AF24052; Mon, 13 Feb 2012 17:53:07 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id UFyM98zUgp+f; Mon, 13 Feb 2012 17:52:32 -0500 (EST)
Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2DF8BF24024; Mon, 13 Feb 2012 17:53:06 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="GB2312"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA1BED33E9@szxeml523-mbs.china.huawei.com>
Date: Mon, 13 Feb 2012 17:52:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2D5BBF5-654A-4B75-B2FD-0FF0B2B26732@vigilsec.com>
References: <1328187998.4790.2946.camel@mightyatom.folly.org.uk> <BB94D1B3E4CD4E1BA7107AF5A99D19BE@china.huawei.com> <1328698730.4345.364.camel@mightyatom.folly.org.uk> <BF80F6B7104742079DDF846CD4863A4D@china.huawei.com> <1328704106.4345.410.camel@mightyatom.folly.org.uk> <41C110BA-F7A1-4E81-A48D-9114A6286901@vigilsec.com> <B8F9A780D330094D99AF023C5877DABA1BED33E9@szxeml523-mbs.china.huawei.com>
To: Qin Wu <bill.wu@huawei.com>
X-Mailer: Apple Mail (2.1084)
Cc: General Area Review Team <gen-art@ietf.org>, "draft-ietf-dime-pmip6-lr.all@tools.ietf.org" <draft-ietf-dime-pmip6-lr.all@tools.ietf.org>
Subject: Re: [Gen-art] 答复: Gen-art review of draft-ietf-dime-pmip6-lr-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2012 22:52:48 -0000

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 [housley@vigilsec.com]
> 发送时间: 2012年2月13日 5:22
> 到: Qin Wu
> Cc: General Area Review Team; draft-ietf-dime-pmip6-lr.all@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" <elwynd@dial.pipex.com>
>>> To: "Qin Wu" <bill.wu@huawei.com>
>>> Cc: "General Area Review Team" <gen-art@ietf.org>; <draft-ietf-dime-pmip6-lr.all@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" <davieseb@scss.tcd.ie>
>>>>> To: "General Area Review Team" <gen-art@ietf.org>
>>>>> Cc: <draft-ietf-dime-pmip6-lr.all@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