[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA-BOF] Detecting Network Attachment BoF description (rev 2)
Hi Alper.
Alper Yegin wrote:
[part cut]
>>Is this what you meant?
>>If so, should we be thinking about multi-link subnets?
>
>
> Yes, why not? Unless IETF decided to not adopt
> draft-ietf-ipv6-multilink-subnets-01.txt... This is an expired draft, that
> was once an official IPv6 WG item. Later it was decided to tackle this
> elsewhere, and I don't know its latest status...
>
I know that Dave Thaler's got a new draft on this:
http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-00.txt
also some NEMO folks like the idea too...
http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-00.txt
That said, it's not my favourite technology,
so I may come across as biased against it.
Does anyone have an official view of what's
happened with this idea?
[part cut]
>>"For these nodes, it is also important detect if an acquired
>>link is new, or has already been visited"
>>
>>I've changed link to subnet. Does this help?
>
> Not really. Because even if the subnet is the same (if we are defining the
> subnet based on the prefixes) there might need to be changes (see earlier
> discussion on multi-links).
OK. Multilinks certainly do complicate
the discussion of this issue.
We'll have to work out what to say here and
in a terminology document to ensure that
there's no major ambiguity.
How about this text for the moment?
"For these nodes, it is also important detect if an acquired
subnet or link is new, or has already been visited"
This allows for either the change of subnet or
link to be important.
> I also think that talking about re-visiting same links/subnets is about some
> (risky/not_so_trivial) optimizations.
>
> This information may be used to distinguish between
> events where configuration must be initiated, or a
> host already has valid configuration.
>
> Nothing guarantees the validity of the previous configs once the host moves
> off-link. There still needs to be some protocol exchange between the host
> and the network elements to ensure validity of the parameters.
I guess you are right for the general case, although
the concept is not that "we're safe" no signalling,
but the distinction between already configured (maybe
needs update later) and needs update now.
The critical path is important in this.
In these cases, we certainly don't want to initiate
MIPv6 binding signalling when the node detaches from an
AP, and then reattaches immediately afterward, for example.
Similarly, it may be worthwhile to initiate Optimistic
DAD rather than full DAD, if a node re-attaches to the
same link (regardless of how the IID was chosen) if the
detachment was under RetransTimer (since no-one can claim
the address in this time). This would allow reception of
packets while maintaining some of the safety.
Of course these are just illustrative ideas.
I still think that the statement is useful, though.
Greg