Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Juliusz,

Please see below.

> On 14. Aug 2019, at 18:51, Juliusz Chroboczek <[e-mail]> wrote:
> 
>> I really don’t want to request to enforce a 3 second limit. However,
>> I would like this draft to specify a limit or at minimum discuss
>> suitable values for specific scenario.
> 
> Appendix B specifies values that were found to be useful in etwo kinds of
> realistic scenarios.
> 
> The protocol structurally enforces minimum values of 10ms (time intervals
> are carried on the wire in units of 10ms).  Values that small are not
> unrealistic over gigabit Ethernet (a full-size frame over GBE is sent in 12µs).

I would like to propose the following:

1) Let's move appendix B into the body of the document. I think these are important information for an implementer and therefore it needs more attention.

2) Maybe you can add something like: The protocol structurally would allow for a minimum value of 10ms for the update interval, however, the update interval must be chosen carefully as such a low value could cause significant network load for slow links but may be a suitable for high speed link. 

I’m sure you have a better wording. My intention is simply to add another warning, to think carefully instead of just pick some default.


> 
>>>> More concretely I think there are these cases that need more guidance:
>>> 
>>> I agree.  I've added a short discussion of packet pacing at the end of
>>> 3.1, and I refer to it at suitable places.
> 
>> Thanks. I was also hoping that you could make any recommendation on how
>> to implement that e.g. a fixed delay of a certain (default) value or
>> based on some other knowledge. If that is a SHOULD and no further
>> implementation example is given, I would be afraid that the risk is high
>> that people simple don’t implement this part.
> 
> You do realise it's a very high bar you're setting?
> 
> There exist standard techniques for packet pacing (static delay, dynamic
> delay, deadline-first scheduling, etc.).  I hope you're not requesting
> that I transform this document in a tutorial about packet scheduling.
> 
> I'll point out that RFC 5340 does not explain how to pace Dijkstra
> recomputation.  There's a good discussion of the issue in Gredler's book
> about IS-IS.  I have no idea whether Gredler's book reflects the behaviour
> of modern implementations.

I wasn’t looking for a tutorial for pacing but rather a reference to add. E.g. just naming different approaches for how to implement pacing and provide a reference would be a good thing I think. However, I will not block on this one thing. Your choice. 

> 
>>>> - Section 3.7.2. (Triggered Updates) advises to send a message multiple
>>>> times for redundancy in case of loss. 5 and 2 are mentioned as example
>>>> values. Please provide a normative default value and a normative maximum
>>>> value here.
> 
>>> Done for the normative max and recommendation to avoid tail loss.
>>> I haven't made the default values normative.
> 
>> Why not? 
> 
> What exact problem are we trying to solve here?  Do you expect that the
> current non-normative language will cause issues?

Thanks for having a max value normatively there! I think that is the important part. And this is also not blocking for me anymore. I just wondering why you don’t call them default value rather then examples. I think specifying default value normatively would be more clear and is what we usually do in specs. However, I think in this case it will not make a huge practical difference.

> 
>>>> - In section 4.1.1 the update interval needs a lower limit (e.g. 3 seconds)
>>> 
>>> I strongly disagree.  Sub-second convergence after a mobility event is
>>> required in some networks.
> 
>> (See above) Maybe then 0.1 seconds is a suitable minimum value…?
> 
> As mentioned above, the protocol structurally imposes a lower bound of
> 10ms, which is not unrealistic over GBE.
> 
>>>> and a recommend default value would be could as well (Note that there
>>>> are other part in section 3 where the update value is discussed as well).
> 
>>> Appendix B.
> 
>> I think this needs normative language in the body of the document.
> 
> I'm sorry, Mirja, I disagree.  See my comments about GBE above.
> 
>>>> - Section 3.8.2.4. mentions network load when requests are sent to all
>>>> neighbours after reboot. Please provide more guidance about how to pace out
>>>> these requests.
> 
>>> I've removed this section altogether.
> 
>> Why?
> 
> The mechanism is not essential, and we're unable to give more precise
> guidance that applies across a wide range of networks.  I prefer to remove
> the mechanism rather than give bad advice.

I think it would be good to have a note on network load when rebooting somewhere in the document. Maybe you can re-add a warning in the security considerations section?

Mirja



> 
> -- Juliusz
> 
>