Re: [DNA] Updates to dna-protocol3

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

Hi Sathya,

Sathya Narayanan wrote:
> Brett -
> 
> Sorry for the delay in responding. I was occupied. See my responses inline.

No worries.  I can certainly relate to that. :)

> <snip>
> 
>> The former is what's in draft-pentland-dna-protocol3-00.txt  I don't
>> remember actually having any debate on that point.  :)  The way it's
>> written was an attempt to make the specification simple to follow
>> while integrating the three identification methods: base the solution
>> around completeRA but allow the RA size to be reduced in certain
>> circumstances.
> 
> OK. I felt this was confusing because it MAY sound like there are
> contradictory recommendations. IMHO, the order in which we introduce the
> flow should correspond to implementation logic, something like, if
> landmark present, should do landmark-response, else if XXX, do YYY else
> do completeRA. Does that make sense? If not, I am ok with your proposed
> change below.

Yes, that makes sense.  Would the following rearrangement of 5.1.5 fit
the bill?

From:

5.1.5  Processing Router Solicitations

    All Router Advertisements sent by a DNA router MUST have the "F" flag
    set so that hosts processing them know that they can count on the
    content being interpretable according to this specification.

    The usual response to an RS SHOULD be a unicast RA.  However, to keep
    control of the rate of unicast RAs sent, a token bucket is used.  The
    token bucket is filled at one token every UnicastRAInterval.  A
    maximum of MaxUnicastRABurst tokens are stored.

    In order to respond to a Router Solicitation, the router SHOULD
    generate a Complete RA as specified in Section 5.1.6.  The Router
    Advertisement MUST include the LinkID, as described in Section 5.1.7.

    If a unicast send token is available AND the source address of the
    Router Solicitation is NOT the unspecified address (::), then a token
    is removed and the Router Advertisement is scheduled for transmission
    as specified in Section 5.1.8.

    If no unicast send token is available OR the source address of the
    Router Solicitation is the unspecified address, then if there is no
    multicast RA scheduled for transmission in the next MulticastRADelay
    the RA MUST be sent to the link-scoped all-nodes multicast address at
    the current time plus MulticastRADelay.

    If no unicast send token is available OR the source address of the
    Router Solicitation is the unspecified address but there is a
    multicast RA scheduled for transmission in the next MulticastRADelay,
    then the Router Solicitation MUST be dropped.

5.1.5.1  Space Optimized Advertisements

    If the Router Solicitation contains a Landmark Option whose prefix is
    included in DNARouterPrefixList or AdvPrefixList AND the
    corresponding Router Advertisement will be unicast, the router MAY
    send an abbreviated Router Advertisement.

    The abbreviated advertisement includes only the Landmark Option, with
    the "Y" flag set, plus the base RA header and any SEND options as
    appropriate.  The Complete flag MUST NOT be set.  This is the one
    exception where the LinkID MAY be omitted as the Y flag implies that
    link change has not occurred.

    Some prefixes may also be omitted from unsolicited Router
    Advertisements, as described in Section 5.1.9.

To:

5.1.5  Processing Router Solicitations

    The usual response to a Router Solicitation SHOULD be a unicast RA.
    However, to keep control of the rate of unicast RAs sent, a token
    bucket is used.  The token bucket is filled at one token every
    UnicastRAInterval.  A maximum of MaxUnicastRABurst tokens are stored.

    When a Router Solicitation is received, the router checks if it is
    possible to send a unicast response.  A unicast response requires
    that the following conditions to be met:

    o A unicast send token is available.

    o The source address of the Router Solicitation is NOT the
      unspecified address (::).

    If a unicast response is possible and the Router Solicitation
    contains a Landmark Option whose prefix is included in
    DNARouterPrefixList or AdvPrefixList, the router SHOULD send an
    abbreviated Router Advertisement.

    This abbreviated advertisement includes only the Landmark Option,
    with the "Y" flag set, plus the base RA header and any SEND options
    as appropriate.  The FastRA flag MUST be set.  The Complete flag MUST
    NOT be set.  This is the one exception where the LinkID MAY be
    omitted as the Y flag implies that link change has not occurred and
    that the previously received LinkID is still current.

    If there is no Landmark Option in the received Router Solicitation or
    it contains a Landmark Option whose prefix is not included in
    DNARouterPrefixList or AdvPrefixList or a unicast response is not
    possible, then the router SHOULD generate a Complete RA as specified
    in Section 5.1.6.  The Router Advertisement MUST include the LinkID,
    as described in Section 5.1.7.

    If a unicast response is possible, then a token is removed and the
    Router Advertisement is scheduled for transmission as specified in
    Section 5.1.8.

    If a unicast response is not possible and there is no multicast RA
    already scheduled for transmission in the next MulticastRADelay
    the RA MUST be sent to the link-scoped all-nodes multicast address at
    the current time plus MulticastRADelay.

    If a unicast response is not possible but there is a multicast RA
    already scheduled for transmission in the next MulticastRADelay, then
    the Router Solicitation MUST be dropped.

Does that make it more readable?  What do others think?

Cheers,
Brett.