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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 04:29:39 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-babel-rfc6126bis-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a couple of points that needs addressing before this document can move
forward. Most of them should the straight forward to address. My main point is
about network load.

Thanks for discussing network load and correctly adding some warnings at the
right places, however, for a PS track document I would like to see more than
this. Usually it's good provide default values were suitable (as this often is
what people will then pick if there is no good reason to diverge) and more
important I really like to see min/max values. Note that RFC8085 recommend a
minimal interval of 3 seconds which probably is also a good hard boundary here.

More concretely I think there are these cases that need more guidance:

- 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. Moreover
the spec should also require to pace out these messages and avoid "tail loss"
by overloading the local queue.  (See also section 3.8.2.1)

- Section  3.8.1.1.  (Route Requests) says: "Full route dumps MAY be
rate-limited, especially
   if they are sent over multicast."
I think this should at least be a SHOULD. Please also provide further guidance
about to appropriately rate limit and think about other cases where a recommend
to implement rate-limiting could make sense.

- In section 4.1.1 the update interval needs a lower limit (e.g. 3 seconds) 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).

- 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.

- Section 3.8.1.2.  (Seqno Requests) discusses hop count values but could maybe
also give more concrete guidance. I would assume that the hop count value of
the current active route is usually know. Maybe that knowledge could be used to
pick an appropriate value?

Two other smaller discuss points/questions/comments:

1) Sec 4.6.8. (Next Hop): If I interpret this correctly, address compression is
allowed for the next hop field and therefore this TLV would actually not be
self-terminating. What do I miss?

2) This document needs to specify a registration policy also for each of  the
already existing registries given this document obsoletes RFC7557.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Other comments:

1) While this point might not raise discuss-level, it would probably also be
good to provide more concrete advise on how to implement jitter: Sec 3.1.: “  
A moderate amount of jitter may be applied to packets sent by a Babel
   speaker: outgoing TLVs are buffered and SHOULD be sent with a small
   random delay.”
Sec 4: “a Babel node SHOULD
   buffer every TLV and delay sending a packet by a small, randomly
   chosen delay [JITTER].”

2) Sec 4.1.2. (Router-Id) should probably state again that the router-id is
assumed to be unique within a domain.

3) Sec 4: “The most-significant bit of the sub-TLV, called the mandatory bit,
   indicates how to handle unknown sub-TLVs.”
I would recommend to also indicate this bit in the image.

4) Sec 4.4:
“If a TLV has a self-terminating format, then it MAY
   allow a sequence of sub-TLVs to follow the body.”
Initially I wasn’t quite sure what you wanted to say here. I guess you say that
the length would indicate a larger value that needed for the body and therefore
a subTLV might be present? I recommend to clarify this here a bit.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Aug 2019 20:06:31 +0200

Dear Mirja,

The replies in this mail concern -13, which I haven't submitted yet (still
working on it).  My working copy is on

  https://github.com/jech/babel-drafts

> forward. Most of them should the straight forward to address. My main point is

I agree, that's an important point, especially when running over 802.11.

> Note that RFC8085 recommend a minimal interval of 3 seconds which
> probably is also a good hard boundary here.

As mentioned in my previous mail, RFC 8085 deals with UDP packets sent
across the Internet.  What we are discussing here is a link-local
protocol, where there are no intermediary routers to congest.  Thus, on
robust link technologies (such as Ethernet) it is enough to ensure that we
don't overwhelm sender and receiver queues; on more fragile technologies
(such as 802.11), we need to ensure we don't overwhelm the MAC.

In short, if the 3 second limitation is to be enforced, then OSPF cannot exist.

> 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.

> - 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. Moreover the spec should also require to pace out these
> messages and avoid "tail loss" by overloading the local queue.  (See
> also section 3.8.2.1)

Done for the normative max and recommendation to avoid tail loss.
I haven't made the default values normative.

> I think this should at least be a SHOULD.

Agreed.

> Please also provide further guidance about to appropriately rate limit
> and think about other cases where a recommend to implement rate-limiting
> could make sense.

Done.

> - 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.

To put things into perspective, a full-size Ethernet frame is able to
carry over 60 Babel updates (assuming 50% IPv4 + 50% IPv6 and reasonably
successful IPv6 prefix compression).  Thus, in a network with 1000 routes,
a full update occupies 16 packets.  With an update interval of 0.1
seconds, we are sending an average of 160 packets per second, which is
very reasonable for a number link technologies.

>  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.

> neighbours after reboot. Please provide more guidance about how to pace out

I've removed this section altogether.

> - Section 3.8.1.2.  (Seqno Requests) discusses hop count values but
> could maybe also give more concrete guidance. I would assume that the
> hop count value of the current active route is usually know. Maybe that
> knowledge could be used to pick an appropriate value?

The hop-count is a last resort mechanism intended to save your network
from catastrophic failure in case everything goes horribly wrong.  It
never triggers in normal usage.

Any value will do.  I've made that clear, and suggested the value 64
(non-normatively).

> self-terminating. What do I miss?

Address compression is only allowed in Update TLVs (the only compression
mechanism allowed in NH is AE 3).  I've clarified that.

> already existing registries given this document obsoletes RFC7557.

Ok.

> good to provide more concrete advise on how to implement jitter: Sec 3.1.: “  

Expanded this in 3.1.  Removed from Section 4.

> assumed to be unique within a domain.

No, this section only defines the datatype, which is carried by Router-ID
TLVs.  It does not define the local Router-ID field, which is part of the
data structures.

>    indicates how to handle unknown sub-TLVs.”

This has been clarified.

> I would recommend to also indicate this bit in the image.

The mandatory bit is part of the TLV Type (see the discussion with
Alvaro), this has been clarified.  I am not aware of a way to describe
that in a packet diagram.

> 4) Sec 4.4: “If a TLV has a self-terminating format, then it MAY allow
> a sequence of sub-TLVs to follow the body.”  Initially I wasn’t quite
> sure what you wanted to say here. I guess you say that the length would
> indicate a larger value that needed for the body and therefore a subTLV
> might be present? I recommend to clarify this here a bit.

Done.

Thanks,

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 14 Aug 2019 17:10:55 +0200

Hi Juliusz,

Thanks for the work and relies. Please see inline. 

> On 9. Aug 2019, at 20:06, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear Mirja,
> 

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. I was just referencing to the 3 second in absence of a better value, however, I’m sure you know better what would make sense.

> 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.
> I haven't made the default values normative.

Why not? 

>> I think this should at least be a SHOULD.

Good.
>> and think about other cases where a recommend to implement rate-limiting

Thanks!
> very reasonable for a number link technologies.

(See above) Maybe then 0.1 seconds is a suitable minimum value…?
>> are other part in section 3 where the update value is discussed as

I think this needs normative language in the body of the document.

> I've removed this section altogether.

Why?

> Any value will do.  I've made that clear, and suggested the value 64

Okay.

> mechanism allowed in NH is AE 3).  I've clarified that.

Okay. Thanks!
>> already existing registries given this document obsoletes RFC7557.

Great!

> Expanded this in 3.1.  Removed from Section 4.

Similar, as my comment on pacing, I’m wondering if you can be even more concrete in order to make it easy for people to implement this correctly. 
> TLVs.  It does not define the local Router-ID field, which is part of the

Okay. Maybe just provide a pointer then?

>>   indicates how to handle unknown sub-TLVs.”

Thanks!

> that in a packet diagram.

Ah I entirely missed that.

>> might be present? I recommend to clarify this here a bit.

Great.

Thanks!
Mirja

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Aug 2019 18:51:19 +0200

> 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).

> 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.

>>> value here.

> Why not? 

What exact problem are we trying to solve here?  Do you expect that the
current non-normative language will cause issues?

> (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.

>>> are other part in section 3 where the update value is discussed as well).

> I think this needs normative language in the body of the document.

I'm sorry, Mirja, I disagree.  See my comments about GBE above.

> 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.

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 22 Aug 2019 16:22:27 +0200

Hi Juliusz,

Please see below.

> On 14. Aug 2019, at 18:51, Juliusz Chroboczek <[email-masked]> wrote:
> 

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.

> 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. 

> 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.

> 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