Subject: TSVDIR review of draft-ietf-mipshop-pfmipv6-09.txt

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2009 05:28:40 -0700

Hi, all,

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they
receive. Please always CC [email-masked] if you reply to or forward
this review.

The primary purpose of the document is to extend fast handover (FMIPv6)
[RFC5568] for Mobile IPv6 (MIPv6) [RFC3775] to support proxy Mobile IPv6
(PMIPv6) [RFC5213], resulting in fast proxy Mobile IPv6 (FPMIPv6). This
review does not consider the transport implications or effects of these
previous protocols, but focuses only on any differences introduced by
the fast proxy variant (FPMIPv6).

FM [RFC5568] has a transition diagram involving three nodes: MN, PAR,
and NAR. PM [RFC5213] has a transition diagram involving four nodes: MN,
p-MAG, LMA, and n-MAG. The proposed FMP solution uses six nodes - MN,
P-AN, N-AN, PMAG/PAR, NMAG/NAR, and LMA. It's difficult to understand
how the additional cascading transactions between these nodes can occur
without substantial impact to handover delay of some sort, but because
the transitions are intended to occur in advance of an imminent handover
these delays should not cause a substantial problem.

Overall, I don't see a reason to doubt that this protocol impacts
transport protocols less than PMIPv6. Issues of tunneling, e.g., impact
to MTU, path MTU discovery, fragmentation or reassembly issues, would be
the same as in PMIPv6. The same is true to impacts of path properties
that affect transports, such as RTT, MTU size, or bandwidth.

One other comment:

Section 4 begins as if in the middle of a discussion. It would be useful
to revise this to provide some context before just jumping in.

Joe

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 25 Sep 2009 18:37:52 -0400

Hi Joe,

Thank you for your review. I am one of the co-authors.
Please some below:

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Friday, September 25, 2009 5:29 AM
> To: IETF discussion list; [email-masked]; 
> [email-masked]; Chowdhury, Kuntal; Koodli, Rajeev; 
> [email-masked]; [email-masked]
> Cc: TSV Dir
> Subject: TSVDIR review of draft-ietf-mipshop-pfmipv6-09.txt
[snip]
> 
> FM [RFC5568] has a transition diagram involving three nodes: 
> MN, PAR, and NAR. PM [RFC5213] has a transition diagram 
> involving four nodes: MN, p-MAG, LMA, and n-MAG. The proposed 
> FMP solution uses six nodes - MN, P-AN, N-AN, PMAG/PAR, 
> NMAG/NAR, and LMA. It's difficult to understand how the 
> additional cascading transactions between these nodes can 
> occur without substantial impact to handover delay of some 
> sort, but because the transitions are intended to occur in 
> advance of an imminent handover these delays should not cause 
> a substantial problem.
> 

P-AN (Previous Access Node), N-AN (New Access Node) are the L2 devices
such as Base Stations or Access Points.
These are assumed in RFC 5213 for wireless handovers. In this ID, they
are included to illustrate the steps better.
That's all.

> Overall, I don't see a reason to doubt that this protocol 
> impacts transport protocols less than PMIPv6. Issues of 
> tunneling, e.g., impact to MTU, path MTU discovery, 
> fragmentation or reassembly issues, would be the same as in 
> PMIPv6. The same is true to impacts of path properties that 
> affect transports, such as RTT, MTU size, or bandwidth.
> 
> One other comment:
> 
> Section 4 begins as if in the middle of a discussion. It 
> would be useful to revise this to provide some context before 
> just jumping in.

Ok. We will take a look.

Regards,

-Rajeev

> 
> Joe
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAkq8t3gACgkQE5f5cImnZruPuwCgw63TMC+u4ux4S2gfWak/Ig9K
> ZycAn1ukPEmGRq6PNlW/M7EWpKov0Szs
> =wHy1
> -----END PGP SIGNATURE-----
>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 29 Sep 2009 11:49:40 +0900

Hi Joe,

Thanks from my side as well. I would just like to add some supplementary
explanation below...

> are included to illustrate the steps better.

These nodes are explicitly shown for explanatory reason and not special
ones. It can be safely said that any host will connect to the network
through L2 devices such as access points. Incidentally, AN stands for
"Access Network" and any kind of L2 device can be included.

>> would be useful to revise this to provide some context before 

Thanks for your comment. The document started as an extension to
RFC5568, but as an independent document, a more self-contained structure
would be preferable. We'll update that section according to your suggestion.

Regards,
-- 
Hidetoshi

> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
> 
> 
>