Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote:
>> 3) please give the Timer Param Sync protocol a clear name. Not crazy
>> about that name.
> It is a protocol to synchronize the value of timers. I suppose we could
> call it "Timer value synchronization protocol". Note it synchronizes
> the value of the timer so that a common timeout is used across the
> network rather than synchronizing the protocols. Would the WG prefer
> coordination to synchronization?
I have particular opinion, but coordination does seem like a better term.
>> Followup comments:
>>
>> * While the document tried to describe the Timer Parameter
>> functionality seperate from the first use of the parameter
>> (fast-reroute), it failed to tell me anything about the new protocol
>> other than bits on the wire. I would like the ISIS/OSPF diagrams to
>> more cleary refer subtype to the new "Routing Timer Parameter
>> Synchronization Registry".
> I am not sure I understand your concern here. Are you concerned with
> the general definition (which follows the tradition in the LS WGs) or
> with the application?
I am concerned with the general definition. I found it abruptly short.
>> I'm unclear what a router does when it sees one of these parameters in
>> the flood. Does it flood the same value? How does it's preference
>> value interact with the value presented?
> This is link-state routing. Routers MUST flood link-state packets
> unchanged, so they are unchanged. To change a value would break a
> protocol invariant of these routing protocols. At the end of flooding
> all routers can see the preference of all other routers and use this to
> pick min/max/something else as specified by the application from the
> set of values provided by the set of routers.
okay, but it's unclear in the document if a router that spoke ISIS on one
interface and OSPF on another would do something magic. I think not, but
there is also discussion about devices flooding different values on different
interfaces... so maybe that's where I began to be confused.
>> I would feel happier with two documents as well because then for each
>> parameter being synchronized, the security considerations could more
>> reasonably explain what unreasonable values are, and how to recognize
>> silly values. Security does not just defend against malicious actors,
>> but also just mis-configured (fat-fingered) ones.
> Again, up to the Chairs, I can easily split if that is what the WG
> wants, but would hope we do not have to go all the way back to
> individual submission.
Perhaps if there were seperate security considerations sections for the base
protocol, and then for the specific application which being proposed.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature