Subject: Re: [DNA] IMPORTANT: Combined DNA Solution draft

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Nov 2005 21:29:18 +0200

I have read the draft (draft-pentland-dna-protocol3-00.txt).
It looks pretty good! I was particularly impressed how well
it describes the overall solution, including address
assignment.

I do have some comments and questions
though. Please see below:

Technical:

>   Frequently, all routers on a link will advertise the same set of
>   prefixes and so this technique will incur no space penalty.  However,
>   on links where routers advertise different sets of prefixes, packets
>   may be larger.  To combat this, two optional mechanisms are defined.
>  
>
 From what I understand, Landmark RAs can actually be
shorter than regular RAs, even if all routers have the
same prefixes. If there's, say, three prefixes, then the
optimized unicast answer can include just the landmark
but not the other options. Or am I missing something?

>   One uses a technique called a "landmark", where the host chooses one
>   of the prefixes as a landmark prefix, and then includes this in the
>   Router Solicitation message in the form of a question "am I still
>   connected to the link which has this prefix?".  The landmark is
>   carried in a new option, called the Landmark Option.
>
>   A second mechanism for reducing packet sizes applies to unsolicited
>   Router Advertisements.  By selecting one prefix on the link to be the
>   "link identifier", and making sure that it is included in every
>   advertisement, it is possible to omit some prefixes.  Such
>   advertisements will not inform a host of all of the prefixes at once,
>   but in general these unsolicited advertisements will not be the first
>   advertisement received on a link.  Inclusion of the link identifier
>   prefix simply ensures that there is overlap between the sets of
>   prefixes advertised by each router on a link and that hosts will thus
>   not incorrectly interpret one of these incomplete RAs as an
>   indication of movement.
>  
>
I have two issues with this. One is that the optionality
should be defined in a stricter way (and as far as I can
see its not done later either, at least not in 6.1.5.1). It
seems obvious to me that if we are touching code in the
routers, we should at the same time make it mandatory
to support the optimized decision mechanism. Then it
can be optional for _hosts to use_. If router support
is optional then we end up in a situation where landmark
request may fail, which consumes time.

Secondly,it is unclear from the above explanations why
we need TWO optional mechanisms instead of just one.
What specifically is the case where one provides better
performance over the other? We don't need either when
complete RAs can be used. We don't need both mechanisms
when doing a solicited RA. What's left? Situations where
the set of prefixes is too long to fit one RA and at the
same time when too many hosts arrive to send unicast
RAs? But wouldn't LinkID be sufficient for that? Or is
this about support of non-DNA hosts? But this might
be fixed by sending landmark prefixes in the usual prefix
list instead of a special option.

>   Yes (Y)
>
>      The Yes (Y) bit, when included in a Landmark Option in a Router
>      Advertisement, indicates that the prefix referred to in the Prefix
>      field of this option is being advertised by one or more routers on
>      the current link.  In a Landmark Option in a Router Solicitation,
>      this bit MUST be set to zero and ignored by receivers.
>  
>
I'm not sure I understand the need for this particular bit.
If the host has sent a Landmark option, wouldn't the router
include this specific prefix in either the regular prefix list
or in the list of other router's prefixes on this link? If so,
the host should be able to determine that it can continue
to have the same prefix as already has.

>   No (N)
>
>      The No (N) bit, when included in a Landmark Option in a Router
>      Advertisement, indicates that the prefix referred to in the Prefix
>      field of this option is not being advertised by any router on the
>      current link.  In a Landmark Option in a Router Solicitation, this
>      bit MUST be set to zero and ignored by receivers.
>  
>
Hmm... maybe I now understand the need for Yes bit.
We need it to distinguish the case between No=1 and
the RA not taking our landmark into consideration at
all.

(I'm wondering though if a No Such Prefix option would
be another way of achieving this. You send a landmark RS
and get a response that contains the router's own prefixes,
other router's prefixes, and the set of restricted prefixes
that the router thinks are not on the link. This could
trivially be the set of landmarks that were requested
but are not on the link. But it could also be a union
of those, or the set of ALL prefixes that are known to not
be on the link...)

>6.1.5.1  Space Optimized Advertisements
>
This seems to cover only the Y=1 case.
What about Y=0? (Oh, now I see that it
comes in later. Maybe add a note to 6.1.5.1
about this.)

>      The prefix MUST be one the host is using for one of its non-link-
>      local IPv6 addresses.
>  
>
Using when, and for what? When the host arrives on this
link, it may not have any non-local traffic. And where
there are multiple prefixes, its quite possible that at
time t1 the host is using one prefix but at time t2 its
using another prefix (e.g., due to RFC 3484 rules).
Or do you mean "use in an address that is currently
configured?" Maybe you could say

   The prefix MUST be one of those that the hosts has
   used to assign a non-link-local address to itself.

Does scope matter?

Maybe you could also add something about the possibility
that the Landmark Prefix needs to change. (And it does,
if the prefix lifetime runs completely out.)

>If the previous state of an address was
>   "Preferred", whether or not the host initiates optimistic Duplicate
>   Address Detection depends on the configurable DNASameLinkDADFlag
>   flag.  A host MUST forgo sending an NS to confirm uniqueness if the
>   value of the DNASameLinkDAD flag is False.  If, however, the
>   DNASameLinkDAD flag is True, the host MUST perform optimistic
>   duplicate address detection on its unicast link local and unicast
>   global addresses to determine address uniqueness.
>
Why do we need to do this? I sense a possibility here
for frequent Link Ups caused by radio coverage issues,
leading to frequent DADding.

>6.2.6.4  Packet Delivery During DNA
>
>   The specification of packet delivery before, during, and immediately
>   after DNA when a change in point of attachment occurs is out of scope
>   for this document.  The details of how packets are delivered depends
>   on the mobility management protocols (if any) available to the host's
>   stack.
>  
>
This text is somewhat confusing. Are you talking about
what IP packets you can send on the link? Right after completion
of DNA you can send and receive anything. Or are you
talking about FMIP-like schemes? Or global mobility
protocols like MIPv6?

Suggestion: don't talk about the latter two at all. Change
text to talk about case 1.

>   such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router
>
Deploy or support? Or maybe just say "may use".

Editorial:

>   RFC 2461 is difficult because of the flexibilities offered to routers
>
flexibility, I think

>   achieve fast RA.  In this memo, an integrated solution is presented.
>
Fast RA?

>1.  Contributors
Move at the end.

>2.  Introduction
Needs to be expanded to be useful for readers who are
not familiar with the history.

>The protocol
>   handles this quite well during graceful renumbering (when the valid
>
s/quite well//

>   removed and perhaps reassigned to a different link), however, it can
>   also cope with "flash" renumbering and reassignment but not in an
>   optimized fashion.
>  
>
Already in this section it would be useful to understand
whether the issue is non-optimality or if there's some
incorrectness issues as well (such as making a false
positive decision that we are on the same link).

>4.1  What Identifies a Link?
>
>
>4.2  Link Identification
>
Hmm...

>   DNA (D)
>
>      The DNA (D) bit indicates that the router sending the RA is
>      participating in the DNAv6 protocol.  Other routers should include
>      this router in calculating response delay tokens.
>  
>
If I have understood correctly, wouldn't "Fast RA (F)" be
more appropriate name?

>6.1.9  Scheduling Unsolicited Router Advertisements
>
Funny indentation in this section.

--Jari

---

From: Brett Pentland <[email-masked]>
Date: Wed, 02 Nov 2005 18:53:46 +1100

Hi Jari,

Thanks for your comments and the detailed review.  I'll respond
in-line.

Brett.

> but not the other options. Or am I missing something?

Yes, that's true.  This is one of the techniques offered below that can
reduce the RA size.

> request may fail, which consumes time.

You may be right, but I'm not sure.  The intent here is that the base
means for determining link change is the complete RA.  If both
the host and router support landmarks, then the smaller RA
is possible.  I can't think of a good reason why a router would
not want to support landmarks, but I don't think whether it does
or doesn't breaks anything.

   - If the RS has a landmark and the router recognizes it
     a short RA is possible.
   - If the RS has a landmark but the router doesn't
     understand it, the landmark is ignored and a complete RA is sent
     that the host can use to make an immediate decision.
   - If the RS has no landmark, then the router sends a
     complete RA that the host can again make use of immediately.

A reason for a host choosing not to include a landmark, is that
it may not wish to expose where it has been previously.

> list instead of a special option.

If it is unclear then clearly the text needs some tweaking :)
They are not meant to be compared with one another because
they apply in different situations.  Landmarks are useful
for the RS/unicast RA exchange.  LinkID allows unsolicited
RAs to be shortened.

In this draft, hosts have no notion of the LinkID.  They are
looking for RAs that have no prefixes in common with those that
they have already seen as an indication that they have moved to
a new link.  The LinkID is just a way to make sure that there
will always be overlap between the sets of prefixes in RAs that
are advertised on a link.

> the RA not taking our landmark into consideration at

Yes.  That was the idea.

> of those, or the set of ALL prefixes that are known to not

Are you talking about being able to send a multicast RA that
can NACK multiple Landmarks at once?  We did discuss this
idea a bit (multiple no-flagged landmark options) but in the
end thought that it was a bit complex and that for multicast
it was simpler to send a Complete RA that gives the necessary
information regardless of the question.

> comes in later. Maybe add a note to 6.1.5.1

OK.  Will do.

>   used to assign a non-link-local address to itself.

Yes, that sounds a lot clearer.

> Does scope matter?

Well, it must be greater than link-scope.  Beyond that, I guess
that uniqueness is more important than scope.  A ULA prefix,
for example, should be fine even though it has local scope.
Perhaps some explanatory text to this effect?  How about:

    The prefix MUST be one of those that the host has
    used to assign a non-link-local address to itself.
    While any scope greater than link-scope is acceptable,
    the prefix SHOULD be one that is unlikely to be advertised
    on another link.  Globally Aggregatable Unicast Address
    prefixes and Unique Local Address prefixes are examples
    of this.

> if the prefix lifetime runs completely out.)

OK.  How about an addition to the first point in that section?

From:

       The prefix MUST have a non-zero valid lifetime.

To:

       The prefix MUST have a non-zero valid lifetime.  If the
       valid lifetime of a previously selected Landmark Prefix
       expires, a new Landmark Prefix MUST be selected.
> leading to frequent DADding.

Well, when connecting to a network, a host doesn't necessarily know how
long it was disconnected for, and so probably should check that its
address is still unique on the link.  Like you say this could lead a lot
of DADing, so we thought that there should be a knob to allow this
behaviour to be turned off.  Note that the default is for it
to be turned off.

> text to talk about case 1.

I think this was getting at the latter two.  With case 1 were you
referring to the time between sending an RS and receiving an RA?
I don't think we have discussed that at all, so it's a good one to
discuss.  Should packets from upper layers be blocked until
completion of DNA (and possible address reconfiguration)?
I'm not sure about that one.  On one hand we don't want to lose
packets if we have actually moved, but on the other, we probably
don't want to sit around waiting for an RA when we're really still
on the same link (maybe there's only one router and the first RA
got lost).  I'd probably lean towards blocking.  Does anyone have
any suggestions?

> Deploy or support? Or maybe just say "may use".

Probably support, I think.  DNA is suggesting that hosts abandon
existing configuration when movement takes place, so that makes
it a bigger target for faked advertisements.

>>   RFC 2461 is difficult because of the flexibilities offered to routers

OK.

>>   achieve fast RA.  In this memo, an integrated solution is presented.

How about "receive an RA quickly"?

> Move at the end.

There was a mix-up with the authorship details.  I have posted an -01
draft, but it hasn't shown up in the repo yet.

> not familiar with the history.

OK, I'll see what I can come up with.

>>   handles this quite well during graceful renumbering (when the valid

OK.

> positive decision that we are on the same link).

OK, I'll have a think about that.

>> 4.1  What Identifies a Link?

:)  How about 4.1 becoming the first paragraph of 4.2?

> If I have understood correctly, wouldn't "Fast RA (F)" be

Yes.

> Funny indentation in this section.

You're right.  I'll fix it.
> --Jari

Thanks again.
Brett.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Nov 2005 10:40:08 +0200

> Yes, that's true.  This is one of the techniques offered below that can

Right. But the text in the draft seemed to be saying that
these optimizations are only for the situation where different
prefixes are advertised by different routers. Can we get that
fixed?

>     complete RA that the host can again make use of immediately.

Its agreed that if complete RAs can be used then there's
really no issue (other than perhaps loss of a little bit of
bandwidth, but I wouldn't worry about that). However, in
your second case above, what happens if the RS has a landmark,
the router doesn't implement them, and it can't fit all the
prefixes in the complete RA? It seems that the router will
make a "random" decision of what prefixes to include, and
since it doesn't recognize the landmark option, it may not
include the host's prefix. Will this cause a problem?

> it may not wish to expose where it has been previously.

Sure. I'm not arguing that hosts should use landmarks
all the time.

> are advertised on a link.

Your explanation makes sense, but I'm still unsure if
the arrangement has to be the way it is. For instance,
it would seem that if hosts picked landmark the same
way as routers pick linkid, then we would need just
one mechanism. Or if we used just Landmark... not
sure I see a big need to reduce packet sizes in unsolicited
RAs.

These alternatives have probably been explored in depth
already, sorry if I'm repeating questions that you guys have
worked on in the design teams etc. for a long time.

> information regardless of the question.

OK. (Assuming you can fit in a complete RA... not sure how
important the other case is.)

>    prefixes and Unique Local Address prefixes are examples

Your explanation above may be enough, not sure if you
need to add anything to the draft. Is there a prefix type
that is likely to be non-unique (other than link-local)?

>       expires, a new Landmark Prefix MUST be selected.

Ok.

> behaviour to be turned off.  Note that the default is for it

Ok.

> I think this was getting at the latter two.  With case 1 were you

Ok. Some clarification in the text is probably needed.

> got lost).  I'd probably lean towards blocking.  Does anyone have

No, but I'd note that there's both outgoing and incoming
packet issues.

> it a bigger target for faked advertisements.

Ok.

> How about "receive an RA quickly"?

I was simply reacting to the term being lowercase in one place
and upper case in another case.

> draft, but it hasn't shown up in the repo yet.

Ok.

> :)  How about 4.1 becoming the first paragraph of 4.2?

Works for me.

--Jari

---

From: Brett Pentland <[email-masked]>
Date: Thu, 03 Nov 2005 17:24:59 +1100

> prefixes are advertised by different routers. Can we get that

Ah, ok, I get it now.  I'll fix it up.  How about a change from:

to:

    Though frequently all routers on a link will advertise the same set
    of prefixes and thus experience no cost in making the RAs complete,
    there is potential for the RAs to be large when there are many
    prefixes advertised.  Two mechanisms are defined that allow certain
    RAs to be reduced in size.

> include the host's prefix. Will this cause a problem?

I don't think so.  The choice of prefixes to include is not quite
random, because the router is required to include the "LinkID" prefix.
That may not be the prefix that the host picked as a landmark, but
it will have been received by the host in any earlier RAs if movement
has not taken place.  Note that I removed the word optional in the
suggested text for the previous comment because the the language in
section 6 does not make the LinkID inclusion optional.

> one mechanism.

Hmm.  So the host selects the landmark the same way as the routers
pick the linkid and then rather than including a landmark
option in the RA the router just prepares to send its usual RA (which
must include the linkid) but if the landmark and linkid
match, then the router can omit everything except the linkid?
That might work.  Is it what you had in mind?

> Or if we used just Landmark... not

There's also the assurance of prefix overlap even when it is not
possible to fit all of the prefixes in a single RA.
> worked on in the design teams etc. for a long time.

No that's fine.  This partly comes up because of the attempt to
merge ideas from two previous proposals, and so is fairly recent.

> that is likely to be non-unique (other than link-local)?

None that leap to mind.  I guess I was just allowing for the
possibility.

> No, but I'd note that there's both outgoing and incoming

So you don't think the draft should say one way or another, but should
note the issue, or it needs to discuss the issue and note that it
affects both outgoing and incoming packets?

Thanks again for your help.
Brett.

---

From: Subba Reddy <[email-masked]>
Date: Sat, 05 Nov 2005 13:08:15 +0530

Hi Brett,

        It is good to see combined solution.
Overall draft is good.

Here are few comments/questions.

1. Is the fast RA mechanism is applicable for all the RS's (not only
for DNA RS's) that a router receives
(with source address as unicast link local address)?

2. Consider the following case.
Router R1 (of Link1) is sending Prefix P1 whose life time is 15 seconds.
A host H came to Link1 and included P1 in DNAHostPrefixList.
P1 expired gracefully and assigned to Link2. If H moves to Link2 and
receives complete RA, it will find the match in DNAHostPrefixList and
will assume same link. Host will not delete P1 since expiry time for entries
in DNAHostPrefixList is 1.5 hours.

3. It may be better to mention, how to populate DNAHostPrefixList.
Only reference to this is, last paragraph of section 6.2.5

4. This comment is regarding "whether a host needs to know whether
a particulat prefix is common prefix (LinkID) or not?"
If a host stores all the prefixes of a link, it does not matter whether RA
has included LinkID or not. If a host cannot store all the prefixes
( may be because of maximum bound), there is a probability that host
may not store LinkID. In that case there may not be any use in including
LinkID without mentioning it as LinkID.  If the prefix is mentioned as
LinkID and if we mandate a host to store that common prefix,
this problem may not come.

Am I missing something?

5. From Section 2, Section 4.2 LinkID and Landmark are optional

Section 2,
" ... Aspects of prefix-based LinkID and
   Requested Landmark are optionally included to allow for a decrease in
   the packet sizes associated with Complete RA."

Section 4.2,
"   Frequently, all routers on a link will advertise the same set of
   prefixes and so this technique will incur no space penalty.  However,
   on links where routers advertise different sets of prefixes, packets
   may be larger.  To combat this, two optional mechanisms are defined."

But in some places, LinkID and Landmark are mentioned as MUST.

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

Section 6.1.6
"   Note that although it may not be possible to fit all of the prefixes
   into an RA, the LinkID prefix MUST be included."

Section 6.1.9
"      They MAY be Complete RAs or MAY include only a subset of the
      configured prefixes, but MUST include the LinkID prefix."

Section 6.2.1
"   Hosts MUST also maintain a "Landmark Prefix" as described in
   Section 6.2.3."

6. LinkID is sent in unsolicited RAs as per section 4.2  We may need to send
LinkID in solicited RAs also in case of incomplete RAs.

From Section 4.2
"  A second mechanism for reducing packet sizes applies to unsolicited
   Router Advertisements. By selecting one prefix on the link to be the
   "link identifier", and making sure that it is included in every
   advertisement, it is possible to omit some prefixes. "

LinkID is sent is solicited RAs as per section 6.1.5
From Section 6.1.5
"  In order to respond to a Router Solicitation, the router SHOULD
   generate a Complete RA as specified in Section 6.1.6.  The Router
   Advertisement MUST include the LinkID, as described in Section 6.1.7."

7. This is comment is raised by others also.
Do we need two bits Y and N in Landmark Option?
I think, one bit may serve the purpose.

8. From Section 6.1.5
"   In order to respond to a Router Solicitation, the router SHOULD
   generate a Complete RA as specified in Section 6.1.6.  The Router
   Advertisement MUST include the LinkID, as described in Section 6.1.7."

For RAs with Landmark option with "Y" bit set, we may not include
LinkId.

9. Since LinkID and Landmark are optional (Section 2),
different implementations are possible.
Router side:-
    a) Complete RA
    b) Complete RA + Landmark
    c) Complete RA + LinkID
    d) Complete RA + Landmark + LinkID

Host side:-
    a) Complete RA
    b) Complete RA + Landmark

As per my understanding all the combinations of router and host
implementations will co-work fine.
If Landmark & LinkID are also part of the solution
(instead of optional), these many possibilities may not be there. It may
be easy to understand and implement.  If this is already discussed by
design team, please ignore this comment.

Editorial:

1. From Section 6.1.5,
"   If this is not the case AND there is no multicast RA scheduled for
   transmission in the next MulticastRADelay, then the RA MUST be sent
   to the link-scoped *all-hosts multicast address* at the current time
   plus MulticastRADelay."

I think, generally we use the term "all-nodes multicast address" instead
of "all-hosts multicast address"

2. From Section 6.1.4
"   Regardless of the state of the DNA flag, each PIO in the RA is
   examined.  If the prefix is not in the router's DNARouterPrefixList
   *or* AdvPrefixList [3], it is added to the DNARouterPrefixList, and its
   expiry time is set."

From Section 6.1.6

"   If it is not possible to generate a Complete RA but the Router
   Solicitation that this Router Advertisement is in response to, if
   any, includes a Landmark Option containing a prefix that is not in
   DNARouterPrefixList *or* AdvPrefixList then the router SHOULD include a
   Landmark Option with the "N" flag set."

I think, "or" may need to be replaced with *and"

3. From Section 6.2.4
"   Hosts SHOULD include a Landmark Option (LO) in the RS message with
   the landmark prefix chosen based on the rules in *section*
   *Section* 6.2.3."

"section" is repeated.

Thanks & Regards,
Subba Reddy

---

From: Christian Vogt <[email-masked]>
Date: Sun, 06 Nov 2005 15:46:18 +0100

>>> [...]

I thought you agreed earlier during your discussion that Landmark and
LinkID are optional for hosts only, but both mandatory for routers.

If you change the draft in this regard, a router not understanding the
Landmark option would consequently not support the DNA Protocol 3 at
all.  But such a router would not support LinkID either, and the host
would end up having to apply CPL logic anyway to arrive at a movement
decision.

The host recognizes that it must use CPL because it sent a Landmark
option with the RS, but the solicited RA neither includes a Landmark
option nor has the C flag set.

This said, I don't see a reason why "case 2" (i.e., the RS has a
landmark but the router doesn't understand it) need to be considered for
this protocol at all.

Am I missing something?

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

---

From: Syam Madanapalli <[email-masked]>
Date: Sun, 06 Nov 2005 20:35:09 +0530

> landmark but the router doesn't understand it) need to be considered for

I think it is good to mandate the routers to support Landmark option and it is
optional for hosts to use it. This will ease the implemention on host side.

Regards,
Syam

---

From: Christian Vogt <[email-masked]>
Date: Sun, 06 Nov 2005 16:12:45 +0100

Hi Syam.

> I think it is good to mandate the routers to support Landmark option 
> and it is optional for hosts to use it. This will ease the 
> implemention on host side.

Yes, compliance to DNA should require routers to support both.  Then
hosts can choose what to use.  Jari brought this up initially.

Besides, support of LinkID on routers will help CPL-only nodes, because
false positives will no longer occur.  (If routers do not use Link ID,
CPL may give you false positives.)  Note that CPL-only nodes will not
know about the use of LinkID, but that doesn't matter.

- Christian

Syam Madanapalli wrote:
>>>>> - If the RS has a landmark and the router recognizes it a 
>>>>> short RA is possible. - If the RS has a landmark but the 
>>>>> router doesn't understand it, the landmark is ignored and a 
>>>>> complete RA is sent that the host can use to make an 
>>>>> immediate decision. - If the RS has no landmark, then the 
>>>>> router sends a complete RA that the host can again make use 
>>>>> of immediately.
>>>> 
>>>> 
>>>> Its agreed that if complete RAs can be used then there's really
>>>>  no issue (other than perhaps loss of a little bit of
>>>> bandwidth, but I wouldn't worry about that). However, in your
>>>> second case above, what happens if the RS has a landmark, the
>>>> router doesn't implement them, and it can't fit all the
>>>> prefixes in the complete RA? It seems that the router will make
>>>> a "random" decision of what prefixes to include, and since it
>>>> doesn't recognize the landmark option, it may not include the
>>>> host's prefix. Will this cause a problem?
>>> 
>>> 
>>>  random, because the router is required to include the "LinkID" 
>>> prefix. That may not be the prefix that the host picked as a 
>>> landmark, but it will have been received by the host in any 
>>> earlier RAs if movement has not taken place.  Note that I removed
>>>  the word optional in the suggested text for the previous comment
>>>  because the the language in section 6 does not make the LinkID 
>>> inclusion optional.
>> 
>> 
>> I thought you agreed earlier during your discussion that Landmark 
>> and LinkID are optional for hosts only, but both mandatory for 
>> routers.
>> 
>> If you change the draft in this regard, a router not understanding 
>> the Landmark option would consequently not support the DNA Protocol
>>  3 at all.  But such a router would not support LinkID either, and 
>> the host would end up having to apply CPL logic anyway to arrive at
>>  a movement decision.
>> 
>>  option with the RS, but the solicited RA neither includes a 
>> Landmark option nor has the C flag set.
>> 
>> landmark but the router doesn't understand it) need to be 
>> considered for this protocol at all.
>> 
> 
> 
> I think it is good to mandate the routers to support Landmark option 
> and it is optional for hosts to use it. This will ease the 
> implemention on host side.
> 
> Regards, Syam

---

From: Syam Madanapalli <[email-masked]>
Date: Sun, 06 Nov 2005 20:57:55 +0530

Hi Christian,

> know about the use of LinkID, but that doesn't matter.

The notion of "LinkID" in the current draft is for Routers only and it is just
a common prefix in RAs. The LinkID is not explicitly notified to hosts so
there is no optional behavior for hosts based on the linkID. But as you said
the common prefix is good for CPL for both DNA and non-DNA hosts.

Regards,
Syam

---

From: Brett Pentland <[email-masked]>
Date: Mon, 07 Nov 2005 07:49:41 +1100

Hi Christian,

> LinkID are optional for hosts only, but both mandatory for routers.

I think we agreed that LinkID was mandatory for routers.
> option nor has the C flag set.

Yes, but the response for a DNA router that does not (for reasons of its
own) wish to send a landmark response, *is* to send a complete RA, which
will allow the host to correctly make a decision.
> landmark but the router doesn't understand it) need to be considered for

The point was that not including a landmark response does not actaully
break anything.  We can make its support a MUST if that's what people
prefer, but I didn't make a MUST so far because I thought MUSTs were
only supposed to be included where failing to take the recommended
action would break the protocol.

Cheers,
Brett.

---

From: Brett Pentland <[email-masked]>
Date: Mon, 07 Nov 2005 08:28:04 +1100

Hi Subba,

>         It is good to see combined solution.

Thankyou.

> (with source address as unicast link local address)?

All, including those with the unspecified address as the source - those
ones will all get their responses from routers in the same order.

> in DNAHostPrefixList is 1.5 hours.

No, the host will expire P1 at its expiry time as indicated by the
liftime it learned in the RA it received on Link1.  (see 6.2.1, para 3)
> Only reference to this is, last paragraph of section 6.2.5

Yes, good point.  6.2.5 needs a paragraph that says when to add prefixes
to DNAHostPrefixList.

> this problem may not come.

What's a reasonable number of prefixes for a link?  Even if it's a few
tens, do we need to worry that hosts won't be able to store that many?
If so, I guess hosts could use the same logic as routers to pick the
LinkID prefix out of the advertised list.  I'm not sure that this is
necessary.  What do others think?

> But in some places, LinkID and Landmark are mentioned as MUST.

Yes, in an earlier thread with Jari, I think we agreed that LinkID is
a MUST for routers.  I forgot about section 2.  I think I should just
remove the work "optionally" from there.  The only MUST I can see
related to Landmarks is that 6.2.1 says that hosts MUST maintain
a Landmark prefix.  Perhaps this should be a SHOULD since hosts aren't
REQUIRED to send a Landmark option.

> I think, one bit may serve the purpose.

See my response to Mohan.

> For RAs with Landmark option with "Y" bit set, we may not include

Yes, this exception should be noted.

> design team, please ignore this comment.

As mentioned earlier, LinkID is not optional for routers (I'll fix that
text) so there are not so many combinations.  There does seem to be
interest in making Landmark support manditory.

OK.

> I think, "or" may need to be replaced with *and"

I think that "or" is correct as it's written, but I see what you mean.
Maybe it would be clearer if it said:

"If the prefix is not in the router's DNARouterPrefixList and not in the
router's AdvPrefixList"...

How's that?

>    the landmark prefix chosen based on the rules in *section*

OK, I'll fix it.

Thanks for your review.
Brett.

---

From: Subba Reddy <[email-masked]>
Date: Mon, 07 Nov 2005 10:11:57 +0530

Hi Brett,

> ones will all get their responses from routers in the same order.

ok

> liftime it learned in the RA it received on Link1.  (see 6.2.1, para 3)

If the prefix P1 is learned prefix for R1, then it will advertise P1 in LPO.
Host (H) will not be receiving life time in the RA sent by R1. If H has not
received
any RA with P1 in PIO within 15 seconds, it will not delete P1 from
DNAHostPrefixList for the next 1.5 hours.

> Yes, good point.  6.2.5 needs a paragraph that says when to add prefixes

ok

> necessary.  What do others think?

ok.

> REQUIRED to send a Landmark option.

ok.

> Yes, this exception should be noted.

ok

> interest in making Landmark support manditory.

ok

> router's AdvPrefixList"...

This is fine.

Thanks & Regards,
Subba Reddy

---

From: Brett Pentland <[email-masked]>
Date: Mon, 07 Nov 2005 17:36:11 +1100

>>>will assume same link. Host will not delete P1 since expiry time for
> 
> entries
> 

Ah, ok in that case that case you have a point.  Usually, the host
would receive an RA from each of the routers on the link within 3
seconds but I guess one or more of those could be lost.  I'm not
sure how realistic such a short prefix lifetime is, but if folks think
this is an issue, we could recommend that if hosts have an entry
in their DNAHostPrefixList for which there has been no PIO received
after X seconds, that they send another RS.

My gut feeling is that this isn't worth worrying about.
Brett.

---

From: Subba Reddy <[email-masked]>
Date: Mon, 07 Nov 2005 14:19:14 +0530

Hi Brett,

> My gut feeling is that this isn't worth worrying about.

In the following cases the above scenario may occur
When a prefix is expiring (valid life time is about to become 0)
    1. A host coming up in that link
        or
    2. A host coming from other link to that link
and then moved to a new link where this prefix is being assigned.

But, as you mentioned the probability is very less.
I am also not sure, whether to worry about this.

Thanks & Regards,
Subba Reddy