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

From: Qin Wu <[email-masked]>
Date: Fri, 03 Feb 2012 12:53:02 +0800

Hi,Elwyn:
Thank for your valuable review. please see our replies below.
----- Original Message ----- 
From: "Elwyn Davies" <[email-masked]>
To: "General Area Review Team" <[email-masked]>
Cc: <[email-masked]>
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.

> 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.

> Nits/editorial comments:
> 
> s1, first sentence:
>> Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobility Access
>>    Gateway to optimize media delivery by locally routing packets *within
>>    itself*, 
> Do you mean this? Shouldn't this be within the local network of the MAG?
> I have to admit that s9.2 of RFC 5213 is a bit ambiguous here as it is
> unclear whether 'locally connected' means a direct point-to-point
> connection or just locally routed.  Presumabnly a static node could be
> in the local net rather than actually directly connected.  Perhaps it
> might be worth copying a bit of the text from RFC 5213 here.

[Qin]: Yes,locally routing packets within itself means when MN1 and MN2 are attached 
to the same MAG, the packet sent from MN1 and destined for MN2 should not be forwarded from
MAG through tunnel (MAG->LMA) to LMA and then tunneled back to MAG and finally sent to the MN2
through the same MAG. Instead, the packet destined for MN2 should be intercepted by the MAG attached 
by both MN1 and MN2 and sent to the MN2 directly through this MAG.

> s4.2: Expand IPv4-MN-HoA.

[Qin]: Okay.

> s4.3: Expand MN-HNP and HAAA. 

[Qin]: Okay.
> 
> s5.1, para 3: Extraneous space in MIP6- Feature-Vector (MFV). (Might be
> good to use non-breaking hyphens in the various AVP titles to avoid
> splits across lines).

[Qin]: Okay.

> s5.1, para 3: s/indicating Direct routing/indicating direct routing/

[Qin]: Okay.

> 55.1, para 6 (bottom of page 9): s/anchored to different MAGs is
>   supported. .  LMA1/anchored to different MAGs is
>   supported. LMA1/

[Qin]: Okay.

> 
> Fig 5: Would improve readability to offset the 'Option 1' and 'Option 2'
> labels one space rightwards as the '1' blends into the vertical line at
> the moment.

[Qin]: Okay.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 08 Feb 2012 10:58:50 +0000

Hi, Qin.

Thanks for your quick reponse.. some comments in line (I have deleted
the bits agreed),

/Elwyn

> [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.

> > involved although actually doing it is clearly out of scope of this

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.

Regards,
Elwyn

---

From: Qin Wu <[email-masked]>
Date: Wed, 08 Feb 2012 19:47:26 +0800

Hi, Elwyn:
Thank for your followup comments, please see my replies inline.

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

> second case is reached in the text.

[Qin]: Good suggestion and will follow this.
> 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.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 08 Feb 2012 12:28:26 +0000

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

---

From: Qin Wu <[email-masked]>
Date: Wed, 08 Feb 2012 20:58:14 +0800

Okay, many thanks to your valuable review.

Regards!
-Qin

---

From: Russ Housley <[email-masked]>
Date: Sun, 12 Feb 2012 16:22:14 -0500

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:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Qin Wu <[email-masked]>
Date: Sun, 12 Feb 2012 22:32:51 +0000

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 [[email-masked]]
发送时间: 2012年2月13日 5:22
到: Qin Wu
Cc: General Area Review Team; [email-masked]; Elwyn Davies
主题: Re: [Gen-art] Gen-art review of draft-ietf-dime-pmip6-lr-07

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Feb 2012 17:52:43 -0500

You should make them when the sponsoring AD indicates.  I do not know if other changes are expected based on other reviews.

Russ