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

["STARK, BARBARA H" <[e-mail]>]

> From: Mirja Kuehlewind
> 
> Hi Juliusz,
> 
> I didn’t talk about pacing in that mail but only about defining default values
> for the interval parameters you already have defined in the draft.
> 
> If all deployed scenarios use the first set of values and these value are well
> applicable for all different scenarios that are defined in the use case doc,
> such as “small unmanaged network" as well as in a "large overlay network”,
> why don’t you just specify these values as normatively default value in the
> spec?
> 
> Mirja

Hi Mirja,
I've been staying out of this discussion, because I wasn't even close to understanding what the requested change was. But this email is providing me with more (but still incomplete) clarity.
As an author of draft-ietf-babel-information-model, I need to ask more detailed questions, because this requested change can impact that draft (and the associated YANG data model). Whenever a protocol spec defines a "parameter" with a "default", it's important for an information/data model to allow for configuration of that parameter (and indicate any default values).

In the information model, we currently have the following defined intervals (currently being sent by the implementation): 
 - multicast Hello interval (defined per interface)
 - update interval (defined per interface, used for multicast and unicast)
 - unicast Hello interval (defined per neighbor)

Are you referring to any or all of these intervals? Are there other intervals you're concerned about? For example, are you referring to implementation-specific values used to derive these intervals? 
These are the intervals the WG considered most important for deployers to have potential knowledge of. However, the WG also determined that allowing for configuration of these intervals wasn't needed and wasn't even a good idea. So they're read-only. Implementations are expected to algorithmically determine appropriate values for these intervals. 

The rfc6126bis draft expounds on some of the reasoning for this with statements like 
" For example, a mobile node
   that is low on battery may choose to use larger time constants (hello
   and update intervals, etc.) than a node that has access to wall
   power.  Conversely, a node that detects high levels of mobility may
   choose to use smaller time constants.  The ability to build such
   heterogeneous networks makes Babel particularly adapted to the
   unmanaged and wireless environment."

This suggests an implementation may have different defaults built in or algorithmically calculated, based not only on link characteristics, but also power supply (and potentially other factors). Identifying a single mandatory default would make it difficult for an implementation to handle specific environmental factors. Identifying multiple mandatory defaults based on permutations of environmental factors would be very complex, and might omit some important environmental factors (or permutations of factors) that an implementor decides to build into a particular implementation. 

IMO, the WG made the right decision not to allow configuration of these intervals (or try to identify parameters to influence calculation of these interval values). So I have to agree with Juliusz that (if these are the intervals you're talking about) the spec shouldn't identify any default values for them.

If I'm misunderstanding the request, please let me know; because I still think it will impact the info/data models.
Thx,
Barbara

> 
> 
> 
> > On 17. Dec 2019, at 20:04, Juliusz Chroboczek <[e-mail]> wrote:
> >
> >>> 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
> >
> 
> _______________________________________________
> babel mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=lAFvsU0_OPDy-
> ZlHIv5uBPdk4vfANIDrA952AjkA108&s=QurFvW6x5-
> cd6JNZ65cpchYuXzKb2bfPfMXOfIeCT5g&e=