Re: [DNA] Feedback on draft-ietf-dna-cpl-00.txt

[Christian Vogt <chvogt@tm.uka.de>]

Hi JinHyeock.

> I think it is ok for a host to send 1 RS and waits for 4 secs to
> collect (solicited) RAs and declare its prefix list (CCL) complete.

I agree.

Besides, has there been a discussion in DNA or elsewhere as to what a
reasonable upper bound on the handover frequency could be?  If there
was, it might be good to put a link into your document.

[...]

>> I do understand that CPL is 100% reliable, even in high-speed
>> scenarios, when the prefix sets in RAs from the same link are
>> guaranteed to overlap.
> 
> This is a very good point, really an acute observation. Thanks. Yes,
> there will no mistakenly assuming a link change because of common
> element (prefix) in (any two) RAs.

Right, and it would be easy for network administrators to set IP links
up this way.

The only issue I see at this moment is IP links which have so many
prefixes that all of them do not fit within a single RA.  In this
situation, the prefix sub-set advertised in one RA might not overlap
with the prefix sub-set advertised in another RA, even though the
complete prefix lists of any two routers on the same IP link do overlap.

Of course, a RA daemon can be configured (or patched) such that any two
successive RAs have overlapping prefix sub-sets.  A RA damon can also be
configured/patched such that the prefix sub-sets of all of its RAs
overlap (for instance, by choosing one common prefix).

However, while this approach helps, it still cannot prevent the MN from
seeing two successive RAs (from the same IP link) with disjunct prefix
sub-sets:  One reason is RA loss, another is multiple routers on the
same IP link.

To coordinate multiple routers on the same IP link, one would end up
having to choose one common prefix which all of the routers put in all
of their RAs.  And that would effectively be the Link ID proposal. ;)

- Christian

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



JinHyeock Choi wrote:
> Dear Christian
> 
> Thanks for your kind and insightful feedback.
> 
> 
>> I took a look at the Complete Prefix List proposal.
>> 
>> First of all, I like the idea of not having to change any entities
>> in the network but only the MN's stack.  This is a significant
>> advantage in terms of applicability until more radical DNA
>> techniques establish themselves.
> 
> 
> ok. glad to hear that.
> 
> 
>> On thing concerning reliance on unsolicited RAs.  Section 3.1 says:
>> 
>> 
>> ++++ The host forms the prefix list at any attachment point, that
>> is, this process starts independently of any movement.  Though the
>> procedure may take some time, that doesn't matter unless the host
>> moves very fast.  A host can generate the complete prefix list with
>> reasonable certainty if it remains attached to a link sufficiently
>> long.  It will take approximately 12 seconds, when it actively
>> perform 3 RS/ RA exchanges.  If it passively relies on unsolicited
>> RA messages instead, it may take much more time. ++++
>> 
>> I see that one cannot really do much analysis for routers that send
>>  unsolicited RAs every 30ms to 70ms as proposed by RFC 3775
>> (because such RA might not have all of the prefixes included).  But
>> since this high frequency would obviously improve the situation for
>> CPL, it might be worthwhile to put a note into the draft.
> 
> 
> ok.
> 
> I think it is ok for a host to send 1 RS and waits for 4 secs to
> collect (solicited) RAs and declare its prefix list (CCL) complete.
> 
> Without a packet loss, the host will generate the complete prefix
> list.
> 
> Even some packet loss may cause an incomplete prefix list, there is a
> further chance for the host to get the missing prefixes before it
> receives link UP notification, i.e. moves to another AP.
> 
> Even the host moves to another AP with incomplete prefix list, the
> first RA may contain the prefix in its prefix list.
> 
> Considering all those above, even if the host performs only one RS/
> RA exchange, it will be very rare for the host to falsely assume a
> link change. Even in case of such a false assumption, there will not
> be a communication disruption but only unnecessary signaling.
> 
> So I think such an occasional unnecessary signaling is acceptable and
> 1 RS/ RA exchange is enough for the complete prefix list generation.
> 
> How do you think of it?
> 
> 
>> I presume you are planning to do, or have already done, some 
>> experimental tests to find out how well CPL works when MNs move
>> really fast.  Well, maybe this can be done on a theoretic basis
>> like the Performance Analysis in section 9.
> 
> 
> We have an implementation plan but didn't think much about the fast
> moving MN case yet.
> 
> 
>> I do understand that CPL is 100% reliable, even in high-speed
>> scenarios, when the prefix sets in RAs from the same link are
>> guaranteed to overlap.
> 
> 
> This is a very good point, really an acute observation. Thanks. Yes,
> there will no mistakenly assuming a link change because of common
> element (prefix) in (any two) RAs.
> 
> 
>> The draft is on its way to Proposed Standard, right?
> 
> 
> We didn't decide it yet.
> 
> Thanks for your kind consideration.
> 
> Best Regards
> 
> JinHyeock