Subject: [DNA] Updates to dna-protocol3

From: Brett Pentland <[email-masked]>
Date: Thu, 16 Feb 2006 21:18:00 +1100

Before submitting the draft to become draft-ietf-dna-protocol-00.txt I
have some updates to reflect the feedback that we've had so far.  The
update can be viewed at:

http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00.txt

And a diff from protocol3 can be seen at:

http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00-from-draft-pentland-dna-protocol3-00.diff.html

Does anyone have any objections to the amendments made so far?  Do they
break anything?  Positive ACKs are ok too. :)

There's a few issues that have come up while making the edits.  They
don't necessarily have to be resolved before submission of the -00, but
some input would be useful.

- Should the explicit linkid always be in the LPO or can it be a flag in
   a PIO (the latter is in the draft)?

- What order do the hosts treat the indications (land mark option,
   prefixes, linkid in the draft at present)

- Given that we now have an explicit linkid, should we get rid of all of
   the flags in the landmark option - the no flag is not really needed
   and since taking that out would leave only one, we can probably get
   rid of that as well - LO in RA = yes (at present the flags are still
   there)

Regards,
Brett.

---

From: Greg Daley <[email-masked]>
Date: Thu, 16 Feb 2006 16:18:36 -0500

Hi Brett,

Thanks for the changes.

>   a PIO (the latter is in the draft)?

It is a significant (16 octet) cost saving to make use of a flag in the
PIO to explicitly mark a link identifier.  The processing is more
complicated in that PIOs and Landmark options have to be checked until
the identifier is found.

This per prefix processing is required if there's no identifier (using
CPL) though, so that's not a major problem.

>   prefixes, linkid in the draft at present)

I'd be interested in finding out what others think.
My personal thought was that the completeRA flag trumps all.

>   rid of that as well - LO in RA = yes (at present the flags are still

it doesn't make the option any smaller to remove. perhaps we can leave
it for future extension?

Greg

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 17 Feb 2006 10:51:34 -0500

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.

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.

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

Comment 4)
Minor changes:

Section 4.1: s/flag bit/bit

I couldn't understand section 5.1.10 (this is not so minor  :-)  )

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

I can do the changes if you ok them.

thanks,
Sathya

---

From: Brett Pentland <[email-masked]>
Date: Sun, 26 Feb 2006 10:28:22 +1100

Hi Sathya,

> received it. Please see below.

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?

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

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

> 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

OK.

I updated the draft where resolved.

Cheers,
Brett.

---

From: Brett Pentland <[email-masked]>
Date: Sun, 26 Feb 2006 10:35:42 +1100

Hi Greg,

> CPL) though, so that's not a major problem.

So leave the draft as is?  I agree.

> I'd be interested in finding out what others think.

Me too.

> it doesn't make the option any smaller to remove. perhaps we can leave

I think it's probably not needed, but don't mind leaving it there.

Cheers,
Brett.

---

From: Brett Pentland <[email-masked]>
Date: Sun, 26 Feb 2006 10:50:48 +1100

The latest changes can be found at:

http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-00.txt

A diff from the pre00 that's been discussed lately can be seen at:

http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-00-from-pre00.diff.html

Cheers,
Brett.