[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [DNA] IMPORTANT: Combined DNA Solution draft
Brett,
A few comments below..
>> It is not clear as to why you would need both Complete RA
>and link-ID ?
>> Link-ID is present in multicast RA (6.1.9) and also in unicast RA
>> (6.1.5).
>>
>> - Section 6.1.9 says "MAY" for complete RA when scheduling
>> unsolicited RA. So, one can avoid implementing complete RA if
>> not for unicast part ? (which also means that you don't need
>> LPO because LPO itself is used only by routers (hosts don't
>> care where the prefixes appear i guess) to form a complete RA.
>
>Hosts need to understand the LPO in order to extract the
>prefixes from it. Regarding "if not for the unicast part", I
>think the unicast part is the most important part. Multicast
>RAs need to be separated by MIN_DELAY_BETWEEN_RAS, so if a
>router has just sent an RA, it is then unable to respond
>immediately to RSes for some time.
>
>"LinkID" is perhaps a poor term for this draft since it is
>unused by hosts and so may be misleading. In a side
>conversation, Syam suggested perhaps "Common Prefix".
>>
>> - Section 6.1.5 says SHOULD for generating a complete RA. We
>> have Landmark option and link-ID. Why is this a SHOULD here ?
>
>Sending a complete RA means that the host immediately has the
>complete set of prefixes in use on the link. This means that
>if the host then subsequently moves to a link that has no DNA
>routers, it is prepared to use CPL logic to make a correct
>movement decision based on the first RA it receives.
>
It might be useful to put this in the document. Perhaps, it is
there and i did not notice it. If there were only DNA routers,
then i don't need complete RA. Is that right ?
>
>> 6.1.1 Data structures
>>
>> The list will be referred to in this
>> document as "DNARouterPrefixList". Prefixes are
>learned by their
>> reception within Prefix Information Options [3] in Router
>> Advertisements. Prefixes in Learned Prefix Options (see Section
>> 5.3)
>> MUST NOT update the contents of DNARouterPrefixList
>>
>> Why is there a "MUST NOT" ? I understand that the LPO itself may
>> contain the prefixes of the router processing the RA from
>a different
>> router. But so does the PIO. As DNARouterPrefixList contains just
>> the prefixes not configured on this router, you need to filter both
>> from PIO and LPO, right ?
>
>This is to make sure that when an administrator pulls a prefix
>out, that it will in fact go away, and not just kept being
>readvertised by the other routers on the link. Basically we
>only want prefixes to be learned by routers from routers where
>the prefix has been explicitly configured.
>
I don't understand. Complete RA has both the configured and learned
prefixes. If an admin pulls a prefix out, it will stop appearing
in the RA from other routers, and eventually all routers will
converge with the prefixes that are configured across all routers.
Routers that learnt the prefix would stop putting it in the LPO
eventually. Are you concerned that it might take longer for this
to happen ? The motivation for "MUST NOT" is not obvious.
-mohan