[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Quick review of draft-jinchoi-dna-cpl-00.txt
Dear Greg
Thanks for your prompt and detailed feedback.
[omitted]
> > But if that makes you still uncomfortable, I will change the above with
> > 'every router ... would receive the RS and USUALLY reply with all the
> > prefixes'. I wish you think that this is rigorous enough. (You don't seem
> > like a person who is not afraid to be less rigourous. :-))
>
> I think this is rigourous enough.
>
> You're right, I think in some cases it's OK
> to be less rigourous ...
Glad to hear that.
[omitted]
> > Sorry I found typo errors. What I tried to say is
> >
> > Without a link-up hint, it's difficult for a host to keep its prefix list
> > from including a false prefix list with certainty.
> >
> > Do you disagree with that?
>
> Indeed I do.
>
> I think that the same mechanism which is used to provide a
> complete prefix list (namely RS) can be used to gather the list.
>
> If we have RAs arriving in response to the RS, we know
> that the probability of not hearing from a router which is
> on-link (assuming independent losses in this case) is about:
>
> p_loss ^ (N_goodrs).
>
> The good rs in this case is an RS which is known to have
> been received by at least one router.
>
> If we solicit when we receive an RA from an unknown router,
> but do not merge the unknown routers prefixes into the existing
> prefix list, we can generate a new prefix list which contains
> (potentially) a separate set of prefixes.
> If there were multiple routers providing the prefix list,
> then they will respond within the RS retransmission period if
> they hear RSs.
>
> For M routers forming the contributing to the existing prefix
> list, the chance that we will not hear their RA responses
> is:
>
> p_loss ^ (M*N_goodrs).
>
> Which should be a fairly low number for M>1.
> (so the chance that we'll leave out someone who belongs in
> the set is low).
>
> If any of the routers advertise a prefix from the list, then
> we know that they are present from the link and are added
> into the new set.
> Set mergers will have to be done only with caution,
> since otherwise, we'll get incorrect old routers popping into
> the sets if we just merge blindly.
>
> If we start this operation each time there is a new prefix
> on the link, then we'll only keep the old prefix list entries
> when they respond to the router advertisements.
>
> If we have new prefixes coming in, we can actually keep
> them in new lists (separate) each time, until we've had
> a time overlap between RA reception of one prefix and an
> older prefix. Then we add them into the sets.
>
> for example (and sorry about the ascii art):
> Time
> ----------->
>
> ----P1---------------------P1-------------------------------------->
> (P1 in set1)
> -------------P2------------|--P2----------------------------------->
> (P2 in set2) (P1,P2 in set2)
>
> --------------------------------P3------P3-------------P3--------->
> (P3 in set3)
>
> ---------------------------------------------P4---------|---P4----->
> (P4 in set4) (P3,P4 in set4)
>
I will also use ascii art to present an example of the superfluous
prefix list.
Assume P1 and P2 are assigned to two different links L1 and L2.
Also assume H is a host and there is no link-up indication.
If H ping-pong between L1 and L2, that may result in the superfluous
prefix list as follows.
Time
----------->
(H is at L1) (H moves to L2) (H moves back to L1)
----|--------P1---------|------------------|------------P1---------------
(P1 in set1) (P1, P2 in set2)
----|--------------------|-------P2-------|-------------------------------
(P2 in set2)
set 2 becomes the prefix list containing both P1 and P2, the superfluous
prefix list. This is the case we are worried about.
[omitted]
> >>I'm loathe to mandate requiring Link-layer hints to provide
> >>basic DNA function.
> >
> > What do you mean by basic DNA function? BCP or Solution/ Extension
> > or others?
> >
> > For me, it's ok to recommend link-layer hints to provide efficient
> > DNA schemes.
>
> BCP is what I'm aiming at: no new bits on wire, widely accepted to
> be applicable and useful.
ok.
[omitted]
> >>The draft should say so explicitly.
> >
> > Actually it does. Kindly look at the end of Sec 3.
> >
> > In summary, first a host makes the complete prefix list. When a hint
> > occurs, if the host decides that the prefix list is complete, it will
> > check for link change with just one RA (with a prefix). Otherwise,
> > in case that the host can't be so sure, it will perform additional
> > RS/ RA exchanges to corroborate the decision.
> >
> > [omitted]
> >
> > In this way, we may provide a fast and robust solution. If a host
> > can make the complete prefix list with certainty, it can check for
> > link change fast. Otherwise, it can fall back on a slow but robust
> > scheme. It is up to the host to decide which scheme to use.
>
> The problem is that the hint is required.
The hint in the phrase doesn't mean Link-layer hint. It is the occurrence
of an event that triggers DNA procedure, for example a new RA.
> >>>Renumbering is a problem when a router starts advertising a new prefix
> >>>that may cause hosts to falsely assume a link change. The paragraphs are
> >>>about this problem.
> >>
> >>Renumbering isn't a problem, since the old prefix will be advertised for
> >>a period with 0 lifetime.
> >>
> >>These prefixes can't be assigned to another link in the mean time,
> >>and so don't cause any harm.
> >>
> >>It is simple enough to change the CPL when the prefixes are
> >>retracted.
> >
> > Renumbering is a problem when a router starts advertising a new prefix,
> > not when the old prefixes are retracted.
>
> It's not a problem, since it should be merged into the prefix list.
> Routers going up and down is more likely than renumbering. They
> should be merged (at an appropriate time) into the prefix list too.
The new prefix should be merged into the prefix list. But instead
the new prefix may make a host to falsely assume a link change.
> Perhaps we are talking at cross purposes again.
>
> We may need to chat about it in SanDiego, to get at the reasons
> for this.
Gladly.
[omitted]
> > Thanks for your detailed comments that make the draft more clear.
>
> That's OK.
>
> I'm really interested in the draft.
Thanks for your kind words and good judgements. :-)
It seems that much of our differnces are resolved. Glad and relieved.
Best Regards
JinHyeock