Hi Ryuji, Thanks for the comments. > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 15, 2007 11:34 AM > To: Narayanan, Vidya > Cc: Internet Area > Subject: Re: [Int-area] > draft-vidya-ip-mobility-multihoming-interactions-00 - Request > for review and comments > > Hi Vidya, > > Thanks for this draft. It must be hard work to puzzle out > this complicated problem:) >
We've written too many protocols here at the IETF :) > I have a few comments. > > - There are well summarized protocol descriptions in section4.1. I > wonder if you can list the mobility and multihoming > characteristics of each protocol maybe with some tables. > Sounds like a good idea. We'll keep this in mind for the next revision. > For example, MIP6 provides permanent addresses (i.e. HoA) > reachability, but not always guarantee the path reachability like > SHIM6 does. An IPv6 node may not be aware of > unreachability of a MN > unless it explicitly exchanges a binding with the MN (RO). > > The comparison of protocols is useful to see the common functions. > In future, some of the functions may be taken by each > protocol and can be > standardized as a universal spec. for all the protocols. > The policy exchange issue raised by Jari on this ML is > just one example. > Alternatively, if two protocols do a same operation (ex. > keep- alive beacon), > one of protocol can skip the operation as an optimization. > Yes, that is the intention and I agree a table improves readability. > - MIP has special meaning to the "home" network. The consideration of > returning home is somehow missing in this document. > For example, MN has two interfaces attached to home network and > foreign network simultaneously. This configuration has been > discussed in Monami6 and not solved yet. > Thanks for pointing this out. We will give some thought to the implications of that. > - We will have presentation about effectiveness of MCoA for MIP6 > handover at MIPSHOP and MOBOPTS meeting. You may be interested in > our presentation. In our experimentation, a MN registerd two CoA > assigned to EvDo and another wireless system called iburst. No > packet drop was observed during the L3 handover (vertical > handoff). We used L2 indication implemented as 802.21. > MCoA is not > originally designed for handover, but it provides good performance > in some scenarios (not horizontal,but only vertical). > I can definitely see the benefit of MCoA for vertical handoffs. I will try and attend the presentation. I may have a conflict for MOBOPTS, in which case, I'll talk to you offline. > - In section 6.2, you conclude that the netlmm cannot support > multihoming. However, even if a MN obtains different IP addresses > (let's say HoA1, HoA2) from relative MAG (MAG1 and MAG2), > the prefix > received from MAGs must be same. Thus, the traffic sent with HoA1 > can be routed to the default router (MAG2), because MAG1 and MAG2 > are reachable default router for the home prefix. MAG is always > able to filter out such traffic, but I believe IPv6 conceptually > allows this operation. > NetLMM is going with the prefix-per-MN model. Also, if the MN has configured an address each on each interface, it would expect packets coming in at each interface to have the address corresponding to that interface. So, I'm not sure how we could send packets destined to one interface to a MAG that would forward the packets to another interface of the MN. Perhaps we can discuss this further this week. > - SCTP is a transport protocol and is out of scope in this document, > but it does support multihoming. > I tested SCTP and MIP6 integration on real implementation > last year. > As a result, if a MN has multiple interfaces and has active CoAs on > each interface, SCTP can optimize the handover latency of MIP6. > In addition to this, one of good feature is that SCTP is capable of > changing association end-points regardless of IPv4 and IPv6. > You can change end point address from IPv4 to IPv6 and vice versa. > This is very good future for mobility, though DSMIP is > being stardized in MIP6 WG. > That is an interesting point. We need to define what the scope is for this work and that's really the problem. To take on SCTP and more protocols might mean that this document becomes too big to be useful and that is a concern. We'll think about it some more to see how we can handle this problem. Thanks, Vidya > regards, > ryuji > > On 2007/03/15, at 17:40, Narayanan, Vidya wrote: > > > All, > > We have submitted a draft describing the interactions and > > architectural usage models involving various IP mobility and > > multihoming protocols that have/are being specified here at > the IETF. > > We'd appreciate review and comments from the community. > > > > Thanks, > > Vidya > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/int-area > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
