Subject: Re: [DNA] Updates to dna-protocol3

From: Sathya Narayanan <[email-masked]>
Date: Fri, 17 Mar 2006 14:27:46 -0500

Brett -

Sorry for the delay in responding. I was occupied. See my responses inline.

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

> The landmark yes response can be quite a good saving, so the sense that
> you have described sounds fine.  Would simply changing the
> recommendation for the landmark response from a MAY to a SHOULD suffice?
>
> The draft would still first say that the RA SHOULD be a completeRA,
> but then change 6.1.5.1 from:
>
> 6.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.
>
> to:
>
> 6.1.5.1  Space Optimized Advertisements
>
>    If the right preconditions are met, it is both possible and
>    desirable to reduce the size of the Router Advertisement by
>    omitting certain prefixes.
>
>    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 SHOULD
>    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.
>
> Would that work?
>
ok.

>> Comment 2)
>> I think it makes sense to change the terminology from 'LinkID prefix' to
>> just 'LinkID' in the text to keep it clean in terms of future
>> compatibility as discussed in 5.1.7.1.1.
>> Section 5.1.7 can be LinkID and the text will describe how a prefix
>> should be selected as the LinkID. I think this will reduce any
>> confusions.
>
>
> OK, except for 5.1.10.1 which is specifically referring to the removal
> of a prefix that happens to be the LinkID.
>
ok.

>> Comment 3)
>> For host operations,
>> Section 5.2.5: Processing Router Advertisments
>> The conditions should be classified into two subsets, one if the 'F' bit
>> is set and another if the 'F' bit is not set.
>>
>> The last condition starting "If the received RA is not complete,
>> contains no prefixes ..." should be replaced with just the condition "If
>> the 'F' bit is not set" and the all the other conditions before are
>> under "If the 'F' bit is set".
>
>
> Is this for clarity or is something wrong with the current text
> logically?  In either case would you be able to propose text?
>
Clarity. Yes, I will do that soon.

>> Comment 4)
>> Minor changes:
>>
>> Section 4.1: s/flag bit/bit
>
>
> OK.
>
>> I couldn't understand section 5.1.10 (this is not so minor  :-)  )
>
>
> The intention is that a router removing a prefix early should behave
> (from a DNA point of view) just like the other routers on the link
> that weren't explicitly advertising the prefix.  They will have heard
> the prefix from the router and will have it's expiry time set to 1.5
> hours after they last heard it, or at the last advertised expiry time,
> whichever is earlier.  If the router does this, then for hosts doing
> DNA, the prefix disappears from all of the routers on the link at
> roughly the same time.
>
> Actually, the text says for the expiry time to be 1.5 hours from the
> new RA, but I guess it should really be 1.5 hours from the last time
> the router sent the prefix in a PIO.
>
> Does that make sense?  If so, what does the draft need to say to convey
> that better?

Yes. I don't remember what confusesd me about the text, I will look at
it again and propose new text.

Cheers,
Sathya

---

From: Brett Pentland <[email-masked]>
Date: Sat, 18 Mar 2006 15:36:35 +1100

Hi Sathya,

> Sorry for the delay in responding. I was occupied. See my responses inline.

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

> do completeRA. Does that make sense? If not, I am ok with your proposed

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

    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.

---

From: Greg Daley <[email-masked]>
Date: Sat, 18 Mar 2006 03:10:29 -0500

Hi Brett.

>    the Router Solicitation MUST be dropped.

What do you mean must be dropped?  How about saying

"... then no additional Router Advertisement is generated in response
to the Router Solicitation."

Greg

---

From: Greg Daley <[email-masked]>
Date: Sat, 18 Mar 2006 03:14:53 -0500

Hi Brett,

----- Original Message -----
From: Greg Daley <[email-masked]>
Date: Saturday, March 18, 2006 3:11 am
Subject: Re: [DNA] Updates to dna-protocol3
To: Brett Pentland <[email-masked]>
Cc: Sathya Narayanan <[email-masked]>, Dna
<[email-masked]>

> to the Router Solicitation."

Actually, how about saying?

"... then the Router Solicitation MUST be silently discarded."

I think that's what you were getting at?

Greg

---

From: Brett Pentland <[email-masked]>
Date: Sun, 19 Mar 2006 20:59:01 +1100

> I think that's what you were getting at?

OK.  Fair enough.

Cheers,
Brett.