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

[Elwyn Davies <[e-mail]>]

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

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.

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.

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.

s4.2: Expand IPv4-MN-HoA.
s4.3: Expand MN-HNP and HAAA. 

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).
s5.1, para 3: s/indicating Direct routing/indicating direct routing/
55.1, para 6 (bottom of page 9): s/anchored to different MAGs is
   supported. .  LMA1/anchored to different MAGs is
   supported. LMA1/

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.