[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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