Hi Joe,
Thanks from my side as well. I would just like to add some supplementary
explanation below...
Koodli, Rajeev wrote:
Hi Joe,
Thank you for your review. I am one of the co-authors.
Please some below:
-----Original Message-----
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;
basavaraj(_dot_)patil(_at_)nokia(_dot_)com; xiayangsong(_at_)huawei(_dot_)com
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.
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.
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.
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
Regards,
-Rajeev
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkq8t3gACgkQE5f5cImnZruPuwCgw63TMC+u4ux4S2gfWak/Ig9K
ZycAn1ukPEmGRq6PNlW/M7EWpKov0Szs
=wHy1
-----END PGP SIGNATURE-----
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
postmaster(_at_)starentnetworks(_dot_)com -- and destroy all copies of this
message and any attachments without reading or disclosing their contents.
Thank you.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf