On 06/10/10 11:09 AM, Geoff Mulligan wrote:
I still do not agree that we need this error code in ND. It is an error on the 6LBR and the 6LBR should communicate the error to the operator and since it is "well connected" it has a much better chance to getting the message to someone that can do something.
I agree it would be much easier for the operator to get the error out of a log or SNMP trap from the 6LBR, then it would be to get the error from the hosts.
Lets not add complexity to this draft.
Works for me. Erik
geoff On Thu, 2010-06-10 at 11:00 -0700, Erik Nordmark wrote:On 06/ 9/10 01:33 AM, Daniel Gavelle wrote:Erik, I agree that a host that gets a DAD full error won't be able to retry another 6LBR. Administrative action is required on the 6LBR to solve this problem. However, a DAD table full error code is still useful in communicating the error to the human who needs to take action. If the host has a GUI (or LED that can flash a fault code), it would be better for it to indicate a "DAD table full" error than a "failure to register address". Even without such help from the host, an installer working on a large commissioned network with a packet sniffer would be able to home in on the problem more quickly with the additional error code.OK, as long as the blinking in morse code of the LED is well-understood ;-) Seriously, I don't see a problem adding such an error code. We just need to make sure we describe that, unlike the error from the 6LR, there isn't a useful fallback. ErikDaniel. Erik Nordmark wrote:On 06/ 8/10 03:21 AM, Daniel Gavelle wrote:I think there are two separate cases where more than one 6LBR may be visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they don't have the concept of a PAN ID. (1) 6LBRs are acting together to provide redundancy. Their context and prefix information is synchronised by an "out of scope method". In this case, wouldn't it be better if all the 6LBRs all advertise using the same identifier (i.e. the current 6LBR Address identifies the network rather than an individual 6LBR).As long as they also synchronize the sequence numbers used in the ABRO they can do that. In essence this might look like one master 6BLR which owns the sequence number space, and the others are slaves that have their configuration kept in synch with the master.(2) Two networks that were intended to be kept separate but use the same PAN and channel have grown out and come into range of each other. In this case, the 6LR and hosts of one network are not interested in the context and prefix information from the other network. Using the context / prefix from the other network would only result in confusion."confusion" is a fairly mild statement, since the compression contexts would now be different hence packets that are compressed would not decompress correctly.I think both cases would be better covered by the 6LR selecting a 6LBR (or set of redundant 6LBRs) and only forwarding the ABRO messages from the network that it is participating in.Not only would the 6LRs need to be configured with the ABRO to accept, but all the hosts would need the same configuration. Using ABRO for this really sounds like solving the problem at the wrong level. Wouldn't there be potential security issues since a router in one lowpan could fake an ABRO pretending to be part of the other lowpan? Wouldn't one want to use some L2 security mechanisms to keep the two networks apart?I agree that we need an error code for when the 6LR has reached capacity and rules for retry. I think the host should send multicast RS rather than poking that particular 6LR as another router may come into range before the one that is full drops a child. Do we also need a separate code for when the DAD table on the 6LBR becomes full?What would a 6LR do to recover from such an error? The assumption is there there is some external out-of-scope mechanism to keep the DAD tables on multiple 6LBRs in synch, thus doing multihop DAD against another 6LBR would still get back to the overloaded 6LBR. ErikDaniel. Erik Nordmark wrote:On 06/ 7/10 10:12 PM, Reddy, Joseph wrote:Some more miscellaneous comments/questions on the ND draft ( I originally sent this email over the weekend but it bounced ) 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a router solicitation from a host? Should it send multiple router advertisement messages in response ?Since we allow 6LRs to send RS messages as part of prefix and context dissemination, a 6LR can't tell whether the RS was from a host or a router. Hence, if RA is used for prefix and context dissemination, then there would be one RA for each ABRO. If RA is not used for prefix and context dissemination from the 6LBRs to the 6LRs, then AFAIK there wouldn't be any ABRO options hence everything could put in one RA. That is what the first paragraph in section 6.3 tries to say. Suggestions on how to make this more clear?2. If a context with valid lifetime = 0 is received from another 6LR or 6LBR, does a 6LR have to delete the context only after completing the dissemination of the context? How long should this time be ( considering that sleeping devices can sleep for very long times.. ). In general updating of context information seems unreliable in presence of sleeping nodesThe 'C' bit is used to robustly be able to remove the context; it needs to be advertised with C=0 to make all nodes stop using it for compression. Section 7.2 specifies this and has a min time of 60 seconds. That is too short to handle hosts that might sleep for an abitrarily long time. To handle that it would make more sense to rely on not having the "expiration time" move backwards. For instance, if a context was advertised at time T0 with valid lifetime V0, at time T1 with valid lifetime V1, etc, then the latest expiration time any node could have is the max(Ti+Vi). Hence even if hosts can sleep for an unbounded time the context would expire no later than that time. This can be used to robustly remove contexts.3. If a host completes DaD on a global address where the IID is derived from its link layer address, can it safely assume that a link local address derived from the same IID is also unique ? That is, can it automatically configure a LL address based on that IID without going through the registration process again for that address ?The answer is completely different if "link layer address" is EUI-64 or a short address. For an EUI-64 we do not do any DAD; we merely do registrations. If applications (running on the neighboring 6LR) might use the host's link-local address, then the host should register that address with the 6LRs so that the routers have the IPv6->link-layer address mapping in their Neighbor Cache. But I don't know a case when application usage of link-locals make any sense since those addresses will be useless should the topology change. For IPv6 addresses based on short addresses (or anything but EUI-64) we need to do DAD across a scope that is consistent with the address scope. Thus for the global address it is across the 6lowpan, and for the link-local it is just with the neighboring 6LRs. (I guess the draft should make it clear that a 6LR doesn't send a ARO towards the 6LBRs for a link-local address.) The fact that the interface ID is the same doesn't help since we want to be consistent with the IPv6 standards. (IPv6 originally did duplicate IID detection which was later clarified to be duplicate address detection.)4. Add a new failure status code for the NA ( "neighbor cache at capacity" ). This will be used if the 6LR has a full neighbor table and cannot allow another host to register through it. The host can then attempt registration through another 6LROK Presumably if there is no other reachable 6LR the host should also continue to keep poking that 6LR, and/or multicast RS messages to try to find an available 6LR that has capacity. I wonder if we should recommend some retransmission behaviors for those cases. Erik _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
