[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA-BOF] BoF Last Call on DNA WG Charter.
Hi Bernard,
Bernard Aboba wrote:
>>Whether we need to do work like this in DNA
>>is up for discussion. If we have an 'authoritive hint'
>>from the link-layer, obviously this wouldn't
>>be needed.
>>
>>Personally, I like to rely on the link layer as little
>>as possible.
>
>
> In general, the argument for doing this in the link layer depends on how
> costly it is to do at L3. In the case of IPv4 there is considerable cost
> because we need to do DHCPv4 for address assignment and thus existing
> implementations typically don't use IRDP. So one might make a case that
> there is some value at L2, although most of the current L2 link-Id
> proposals don't seem to adequately take into account the dynamic nature of
> VLAN assignment today. This means that an L2-advertised Link-Id is only a
> "strong" hint if it is advertised after the VLANID has been assigned.
> Prior to that point, it is just a "weak" hint because the assigned VLANID
> could turn out to be different than the one being announced at L2.
Agreed.
> In IPv6, the case for L3 linkIds is much stronger because we need to do
> RS/RA anway, so adding a 'linkId' seems quite natural. Of course there is
> nothing that says that a dual stack implementation can't make use of an
> IPv6 facility as a "hint" for IPv4.
Pekka mentioned that this sort of interaction may be useful
(using IPvX as hint for IPvY). In the IETF57 BoF session
there was some concern about interaction between IPv4 and IPv6.
Given that the context of these is treated in a similar way
to the link-layer hints, this may be a valid and valuable.
We'd have to ensure that the interactions between v4 and v6
carried appropriate weight.
For example, for IPv6 systems using SEND, the indication from an
unsecured IPv4 system that a link has changed may be less
authoritative than a hint going the other way (in this particular
case).
So I think there may be scope for describing the interaction further,
but I'm not sure how far we need to go down that path at this stage.
(We're still trying to ensure that the basic work can be covered).
Greg