Hi Allison, Thanks for the review. Appreciate it. Please see inline. On Wed, 20 Feb 2008, Allison Mankin wrote: > > 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 tsv-dir@xxxxxxxx if you reply to or forward > this review. > > Overview - > The specification is written clearly and the elements of the proxy IPv6 > mobility design strike me as pretty coherent at this point. > > The design raises a number of issues for transport sessions on the > mobile node. These need to be addressed in some way. As suggested > above, correspondence with the transport directorate (tsv-dir) and me is > welcome for clarification or to discuss these points. > > 1. MTU - the mobile node (MN) receives its traffic through a tunnel. > The local mobile anchor to mobile access gateway encapsulations are > varied (Section 6.10.2: v6-in-v6, v6-in-v4, v6-in-v4-udp). While > tunnels lead to a generic problem for MTUs (RFC 4459), the problems > are intensified in this design because the MN's moves may result in > successive differently encapsulated tunnels, at short enough > intervals that transport sessions survive across them and end up > transmitting data with problematic MTUs. > > Please discuss the MTU issue. Suggestion - recommend the state of > the art initial MTU detection, PLMTUD (RFC 4821), which also allows > connections that can't start new probes to learn of MTU changes from > other connections with more recent probe information. > One clarification w.r.t the encapsulation modes. The supported encapsulation modes for the tunnel between the LMA and the MAG, as per this specification, is IPv6-in-IPv6 [RFC-2473]. The other modes of IPv6 over IPv4 transport (IPv6 over IPv4 or IPv6 over IPv4-UDP) are enabled in the companion document which is still under WG review. http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-02.txt The document briefly talked about the other two modes for the sake of completeness in the context of Proxy Mobile IPv6 protocol scope and the supported transports. This essentially leaves just one mode, IPv6-in-IPv6. All though, the comment on PMTU changes due to various encap modes in the access networks is a very good comment and needs more attention in the IPv4 support document, as that is the enabler for varying encap modes. However, as per this document, we have a fixed encap type in a given Proxy Mobile IPv6 domain, if this makes it bit better. As a side note, not trying to argue about this issue at all. In Mobile IPv4, per 3344 and in combination with the NAT traversal spec [RFC-3519], when a mobile node operating in FA-CoA mode registers to the home agent, the encap mode for the tunnel between the FA and HA could be either, IP-in-IP, IP-GRE-IP or IP-UDP-MIPHDR-IP. The MTU issues in both the cases (when IPv4 support is enabled for PMIP6) are just identical. Trying to draw a relation to understand the issue and see what solution that spec adopted. In a scenario, when a mobile moves from MAG1 to MAG2 and if the PMTU on the path between MAG2 and the LMA is lower than the PMTU between MAG1 and LMA, the RA advertising the mobile node's home network prefix can contain a MTU option with a lower MTU value reflecting the PMTU between the MAG and the LMA. In any case, the MAG is required to complete the signaling with the LMA before it can send the RA on the access link. If the mobile after an handoff, receives a RA with a lower MTU, the TCP streams originating from the host should adopt to this change. This is one way to address the PMTU change issue after an handoff. We can suggest on the need to add the MTU option in the RA's sent by the MAG, generally reflecting the pre-configured PMTU between the MAG and LMA. > 2. Tunnel and Explicit Congestion Notification (ECN) - with transport traffic > that uses ECN (RFC 3168) - most transports - provision is made for tunnels > by transferring ECN information between the outer and inner IP(v#) headers > at the tunnel endpoints. Something like this procedure is also provided for > maintaining the ECN signal through an MPLS network. I suggest that this > document should call for applying the ECN for tunnels procedure from RFC 3168 > on behalf of the MN and its correspondent nodes. More motivation: far from > having no congestion in the highly engineered wireless/wireline deployments, > measurements often find serious pressure on resources such as the wireline > backhaul. Good to make sure the congestion avoidance system is well in place. > > Please get ECN into the local mobility anchor to mobility access > gateway tunnel if possible Question: it's clear that forming a new tunnel > requires ECN to zero out and start over and only the local mobility anchor > knows this. Doable? > The LMA-MAG tunnel is a layer-3 ( IPv6-in-IPv6) tunnel, per RFC-2473. We are bound by that spec w.r.t ECN management. I assume 2473 based tunnel implementation must support Limited-funcitonality ECN option and not sure if this spec can say any thing beyond that and specially in the absence of negotiation protocol in 2473, w.r.t ECN capability exchange. We can certainly suggest copying the ECN codepoint from the outer header to the inner header, prior depcap. But, not sure if that is in scope of this document which leverages standard tunneling modes. > 3. Data during Binding Changes - > > Section 5.3.4 describes the action at the local mobile anchor when a new mobile > anchor gateway has sent a binding update for the MN, in other words, when there > has been a handoff. Section 5.3.5 describes the signaling action at the local > mobile anchor before the handoff, when a mobile anchor gateway has sent a > the binding de-registration. A binding de-registration might not be followed > by a handoff. > These are separate considerations. The processing flow in 5.3.1, bullet 13, determines the flow. > From a data transport point of view, it is unclear why the working group chose > to flush any pending data in the binding de-registration: > > During this wait period, the local mobility anchor SHOULD drop the mobile > node's data traffic > We had some discussions on this. The LMA has received a dereg from the prev MAG, LMA accepts the dereg, but keeps the BCE for transient amount of time, to allow the MN to handoff to a new MAG and let that MAG update the binding before the binding is deleted. Earlier versions of the document did recommend that the LMA should continue to forward the traffic to the prev MAG. But, the comment from the WG was that, the party is no longer interested and hence we should not forward the traffic during that wait time. > The mobile anchor gateway has a timer prior to deleting the binding state. Isn't > the transparency of mobility and of handoffs best served by holding the pending data > and then providing it as early as possible during handoff? I'd like to understand > the reasoning. A technical counter is that a large data loss is a signal for > all IETF data transports to enter major congestion avoidance. Non-response > will lead to other problems with transports' performance. > > Please consider holding the pending data - the parameter MinDelayBeforeBCEDelete > is a small amount of time, but perhaps the data hold could be recommended to be > for half of it as a buffer implementation consideration. > > If the pending data is held, then Section 5.3.4 needs to discuss the pending data > too. > Typically, LMAs can serve potentially 3 to 5 million bindings. Buffering requirements might be too high, also SDO architectures do handle this in the manner that suits that architecture, resources ..etc. So, buffering was considered out of scope for this work. Thanks for the detailed review. Appreciate it. Regards Sri > > Allison Mankin / Transport Directorate > > Allison Mankin > Division of Computer and Network Systems > National Science Foundation (US) > > > > > > ------- End of Forwarded Message > > _______________________________________________ > netlmm mailing list > netlmm@xxxxxxxx > http://www.ietf.org/mailman/listinfo/netlmm > _______________________________________________ IETF mailing list IETF@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf