Re: [DNA] IMPORTANT: Combined DNA Solution draft

[Jari Arkko <jari.arkko@kolumbus.fi>]

Brett Pentland wrote:

>>>   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?
>
>
> Yes, that's true.  This is one of the techniques offered below that can
> reduce the RA size.

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?

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

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?

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

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

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

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.

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

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

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

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

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

Ok.

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

Ok.

>>
>> Suggestion: don't talk about the latter two at all. Change
>> text to talk about case 1.
>
>
> I think this was getting at the latter two.  With case 1 were you

Ok. Some clarification in the text is probably needed.

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

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

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

Ok.

>
>>>   achieve fast RA.  In this memo, an integrated solution is presented.
>>>
>> Fast RA?
>
>
> How about "receive an RA quickly"?

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

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

Ok.

>
>>> 4.1  What Identifies a Link?
>>>
>>>
>>> 4.2  Link Identification
>>>
>> Hmm...
>
>
> :)  How about 4.1 becoming the first paragraph of 4.2?

Works for me.

--Jari