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

[Juliusz Chroboczek <[e-mail]>]

>> If that is the case, then I request that you state explicitly why you
>> think that Babel must be held to a much higher standard than OSPFv3.  If
>> that is not the case, then please clear your discuss.

> In OSPFv3 as far as I can see (and I am really not an expert here) all
> values that define intervals are in seconds which leads to a minimum
> value of 1 seconds. This is not the case for babel and therefore we need
> to be more carful here.

After a change of topology, OSPF executes the procedure described in
Section 4.5.2 of RFC 5340 (Section 13.3 of RFC 2328).  At this point,
a potentially unbounded number of LSAs are flooded out every active
interface (point 5 in Section 13.3 of RFC 2328).  This flooding is not
regulated by any timer -- all that the protocol says is that the LSAs must
go out through a certain subset of the router's interfaces.

I could be wrong, but I am fairly confident that nothing in RFCs 5340 and
2328 specifies congestion control, flow control or packet pacing for this
flooding procedure.  My interpretation is that since OSPF is designed to
be deployed on local links, congestion caused by OSPF is not likely to
endanger the Global Internet, and therefore packet pacing (if required) is
left to the implementation.

I also don't recall any discussion of flow control in Moy's and Gredler's
books, but they have a lot of pages (especially Gredler's), so, again,
I could be wrong.

Where you are right, Mirja, is that packet pacing is a very difficult
problem in OSPF, where incorrectly delaying flooding could lead to
microloops; since Babel has a loop-avoidance mechanism built-in, it can
safely perform packet pacing should the need to do so be demonstrated in
a particular topology.

In summary, while I agree that packet pacing for Babel would be an
interesting research project, I maintain that by requiring packet pacing
as a condition for publication as PS, you are requiring an unreasonably
high standard, certainly a standard that neither OSPF nor IS-IS are held to.

>> Appendix B gives values that are suggested for implementations.

> Yes but it doesn’t discuss for with _deployment_ scenarios these values
> are suitable.

As far as I am aware, all current production deployments use the first set
of constants.  The one exception is an experimental testbed used for
mobility research, that uses the (more aggressive) second set of constants.

> Did you deploy the same parameters in all of the discussed scenarios.

Yes.

> Does it actually makes sense to use the same parameters in a "small
> unmanaged network" as well as in a "large overlay network"?

Yes.

> Is that network connected to the Internet or not?

Yes, but that's irrelevant -- the Babel traffic is link-local, and does
not go outside the local routing domain.

-- Juliusz