[DNA] Re: Comments on draft-daley-dna-det-fastra-00.txt

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Hi Jari, 

----- Original Message -----
From: Jari Arkko <jari.arkko@kolumbus.fi>
Date: Monday, August 2, 2004 1:18 am
Subject: Comments on draft-daley-dna-det-fastra-00.txt

> I have read the draft draft-daley-dna-det-fastra-00.txt and
> have the following comments and questions:
> 
> Overall:
> 
> I think the protocol is valid, and necessary. I wish
> it could be simpler, but it was not immediately obvious
> to me how it could be simplified :-)
> 
> Technical:
> 
> > 11.4  Presence of Incompatible Fast Routers
> > 
> >    When routers wishing to undertake FastRA exist on the link but 
> are>    not trusted for inclusion in the Fast Routers List, two 
> distinct sets
> >    of routers may appear.
> > 
> >    Each set may not trust another, and may instead have its own 
> router>    at each Rank.  In this case, the IncompatibleFastRouters 
> flag SHOULD
> >    be set on the interface until the untrusted routers become 
> trusted,>    or cease being Fast Routers.
> 
> Can you talk more about the details regarding incompatible
> fast routers? When would another router be incompatible?
> Perhaps you are thinking of that if it doesn't have a SEND
> certificate to a suitable trust anchor, then its not
> compatible? But if there are incompatible sets, won't their
> FastRAs collide?

Yes, indeed that's what I was thinking.

And Yes, they'll collide.

Previously there was a complicated mechanism
which allowed devices to jitter if there were
incompatible/colliding routers.

we thought that that would be too heavy for the
draft now, but if we need to explicitly handle 
this case (other than to send traps or other logs)
then we may go back into it.

What's your take on this? 

> > 12.4  Host Reception of DetFRAOs
> 
> Is it really necessary have this as a part of the protocol?
> It complicates the protocol, and I'm not sure I see the
> reason why hosts should know what the rank and other parameters
> of the routers are. The host might have a need to know how
> fast it should get the first/last RA on this link -- but this could
> be told to the host without exposing it to the ranks and other
> details of the router-to-router functionality.

No it's not necessary.

Should it be removed or put in a separate draft?

The only reason to have it is to quickly
indicate that link change may have occurred if
we receive an RA in the first slot (where we
already had a router in the first slot) when a 
link change has occurred.

THe performance benefit is limited if we have some
other reason to believe the link has changed in
the RA (CPL/Linkid?)



> > When using SEND,
> 
> Can you clarify whether the use of SEND is mandatory or
> optional in the context of your protocol? I think it should
> be optional, but your text is not clear on this point.

I think it should be mandatory, but that's
a personal preference :)

Realistically, I think the router ordering
has problems if there are send and non-send
routers.

If there's only one domain (Send xor non-send),
then that's OK, but still I think that a key
advantage is that there is some way of securing
things.

If there was a hsrp/vrrp instance instead, then 
we'd only have one hsrp router, and the election
mechanism used for that would work.  This 
currently doesn't have a generic security 
mechanism though, and may be undesirable for
other reasons....

> >    routers MUST check that the
> >    router from which they receive a DetFRAO is an authorized 
> router from
> >    that link, and that the router trusts the delegation service 
> used to
> >    sign this authorization [5].
> 
> I think we need more detail on how this check is to be
> performed. I think it should be enough that the other
> router has the same trusted anchor as you do, but perhaps
> are want a more specific check that the router is also
> a router for this link. How would you check that?

OK. 

Originally, I was thinking that the same 
mechanisms used in SEND would be used, but those
may have changed in -06.

> Editorial:
> 
> o Section 2: I would suggest a newline between the term and
>   its explanation, use <vspace blankLines='1' /> in XML2RFC.

THanks. 
> >       Deterministic Fast Router Advertisement
> >                      The configuration status for FastRA, as 
> defined in
> > 
> >    Section 4.2
> >     of this document.
> 
> Extra newlines.

Thanks for your review.

Greg