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@xxxxxxx] >> Sent: Friday, September 25, 2009 5:29 AM >> To: IETF discussion list; mipshop@xxxxxxxx; >> yokota@xxxxxxxxxxx; Chowdhury, Kuntal; Koodli, Rajeev; >> basavaraj.patil@xxxxxxxxx; xiayangsong@xxxxxxxxxx >> 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@xxxxxxxxxxxxxxxxxxx -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you. > > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf