Re: [DNA] Updates to dna-protocol3

[Sathya Narayanan <sathya@research.panasonic.com>]

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