Re: [DNA] IMPORTANT: Combined DNA Solution draft

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

Mohan.Parthasarathy@nokia.com wrote:
 >
 > 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 ?

Yes for the immediate decision, but the host doesn't know where
it will move to next.  If the host receives a Complete RA, then
it is ready to make an immediate decision even if it moves to a
new link and receives an RA from a non-DNA router.

 >>>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.

Say a prefix is explicitly configured on only one out of three routers
on a link.  That prefix will be learned by both of the other routers
on the link and included in LPOs in RAs from those routers.  If the
administrator withdraws the prefix from the router on which it was
configured, the other two routers would continue to see the prefix in
each other's LPOs and in fact the original router would "learn" of the
prefix from the LPOs, and the prefix would never go away.  Does that
explain it adequately?

Brett.