Thank you for your review. I am one of the co-authors.
Please some below:
From: Joe Touch [mailto:touch(_at_)ISI(_dot_)EDU]
Sent: Friday, September 25, 2009 5:29 AM
To: IETF discussion list; mipshop(_at_)ietf(_dot_)org;
yokota(_at_)kddilabs(_dot_)jp; Chowdhury, Kuntal; Koodli, Rajeev;
Cc: TSV Dir
Subject: TSVDIR review of draft-ietf-mipshop-pfmipv6-09.txt
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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
-----END PGP SIGNATURE-----
Ietf mailing list