Re: [DNA] Updates to dna-protocol3

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

Hi Sathya,

Sathya Narayanan wrote:
> Brett -
> 
> I sent the following email to you last week (02/08). I don't know if you
> received it. Please see below.
> 
> thanks,
> Sathya
> --------------------------------------------------------------------------------------------------------
> 
> Brett -
> 
> Atlast, I got to look at the DNA soln. draft. I have the following
> questions/comments:
> 
> Comment 1)
> The solicited router advertisement case as is written now seems to me as
> follows as:
> 
> - SHOULD do completeRA (MUST include LindID even if complete RA is not
> possible due to length of the packet).
> - MAY do landmark response if the RS contains landmark question
> {
>               - LinkID is not needed for "Y" response
>               - LinkID MUST be present in "N" response with as many of
> the prefixes as possible (if all prefixes included then set the Complete
> bit).
> }
> 
> Is this the intended recommendation?
> 
> My understanding was,
> 
> If landmark question in RS
> {
>    SHOULD Send landmark response
>              - LinkID is not needed for "Y" response
>              - LinkID MUST be present in "N" response with as many of
> the prefixes as possible (if all prefixes included then set the Complete
> bit).
> }
> else
>    SHOULD do completeRA (MUST include LinkID even if complete RA is not
> possible due to length of the packet).
> 
> Am I missing something? (or starting the debate all over again? - my
> apologies if I am  :-)  ). I can do the changes if necessary.

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.

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?

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

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

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

> Section 5.2.5.1: has few lower case shoulds, may be they MUST be changed
> to SHOULDs.

OK.

I updated the draft where resolved.

Cheers,
Brett.