Hi Samita, A few comments and questions about your new version. - page 4, chapter 3 point 2 you state Neighbor Solicitation but it should be a Router Solicitation, right?
- page 6, chapter 4: you state "The IPv6 router which sits in the boundary of the LowPan is a PAN co-ordinator." Since only one PAN co-ordinator is allowed per LowPan this implies that the LowPan is only connected by one IPv6 router to the outside world. I think it is beneficial and applicable to have more than one IPv6 router (gateway) that connects the LowPan to external networks (e.g. for redundancy, loadsharing, reaching differnet offlink networks, etc.). If you agree you could reword the sentence and state: "One of the IPv6 router which sits in the boundary of the LowPan is the PAN co-ordinator." A second gateway (IPv6 router) may overtake the role of the PAN coordinator in case that one is failing (alternate PAN coordinator) or the PAN coordinator may redirect offlink traffic to a second gateway due to being overloaded. - page 8, section 5.1: For your statement "[TBD: how can it also find out about the other addresses? Guess based on the advertised prefixes?]" I would recommend that for each address a node configures it sends a Neighbor Solicitation to the PAN coordinator. This way, the PAN coordinator would get a complete L2-L3 association table of on-link nodes. This would also answer your last bullet point in section 9 and removes the need for your section 6.1. - page 8, section 5.2: I would not introduce an additional signalling protocol, e.g. among coordinators, to enhance RA processing but would keep periodic RAS and go for your option 2 (use L2 unicast to send RAs). The resulting overhead should be acceptable (setting an appropriate interval is a network designer issue). An additional signalling protocol has also an overhead and complexity, and requires additional processing in coordinators, which are likely to be battery powered as well. Maybe we could think of a signalling protocol between PAN coordinator and alternate PAN coordinators (e.g. IPv6 routers that provide external connectivity) so that an alternate PAN coordinator can quickly establishes itself as PAN coordinator in case the primary one fails. Best regards, Karl >-----Ursprüngliche Nachricht----- >Von: Samita Chakrabarti [mailto:[EMAIL PROTECTED] >Gesendet: Sonntag, 25. Juni 2006 01:30 >An: [email protected] >Betreff: [6lowpan] 6lowpan-nd version 2 > >Erik and I have updated >draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for >publication. The new update includes a section on generic >application of this draft for non-multicast, non-broadcast >network. At the last wg meeting, the request was made for such >an update for the Wimax effort on IPv6. > >Two questions to the working group and the chairs: > > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG >document ? > 2) Are we OK with publishing the draft as "IPv6 Neighbor >Discovery Optimization > for IEEE 802.15.4 and other non-multicast networks" so >that it contains > specifics on 6lowpan and a generic guideline for other >relevant networks? > >Comments are welcome. > > >- Samita > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
