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

[David Schinazi <[e-mail]>]

Hi Barbara,

The text you mention containing "The following values are recommended"
intentionally does not use RFC2119 language. The appendices of rfc6126bis
do not contain any RFC2119 uppercase language as appendices are not meant
to be normative.

Hi Mirja,

It sounds like you're asking us to move the informative values from the
appendix to a normative statement in the core spec. That goes against the
current design philosophies of the document, which is to specify
normatively only what is needed for interoperability, and leave any advice
to non-normative appendices. I'm not sure I understand what your proposed
change would accomplish. As we have seen repeatedly, implementors of Babel
have been happy to read the appendix and follow that implementation advice
in the absence of better ideas. I would rather keep what we currently have,
as it is a principled approach that has worked in practice for all known
implementations of Babel.

Thanks,
David

On Mon, Jan 6, 2020 at 1:54 PM STARK, BARBARA H <[e-mail]> wrote:

> Hi Mirja,
> Thanks for that. OK, so you don't need them to be configurable or
> mandatory (which means the WG consensus that they not be configurable is
> acceptable) and you would be satisfied with "SHOULD". Normative language
> terminology (RFC 2119) allows for use of "RECOMMENDED" to mean the same as
> "SHOULD", and "Appendix B: Protocol parameters" currently says (in 2
> places) "The following values are recommended ..."
> If this were changed to " The following values are RECOMMENDED ...", would
> that satisfy your comment?
>
> Juliusz, would that be acceptable to you?
> Barbara
>
> > Hi Barbara,
> >
> > To me the question of configuration is actually orthogonal.
> >
> > I think this sentence you write is the core of the misunderstanding we
> might
> > have:
> > > Identifying a single mandatory default would make it difficult for an
> > > implementation to handle specific environmental factors.
> >
> > The whole point of the word “default” here is that of course you can use
> > another value (because otherwise it would not be a parameter but a
> > constant). What I’m talking about is the point of time when the code is
> > written and I as an implementator have to decide which value to set (for
> my
> > implementation). Having a normatively defined default value doesn’t mean
> > that all implementation have to use this value, but if I write the code
> at a
> > point of time where I might not be aware of specific requirements, the
> > default values should give me some reasonable idea about something that
> > will work “well” in “most” scenarios (which it seems to be case that
> this set
> > actually exists for babel as people tell me that all deployed
> implementation
> > currently use the same value). I’d say it’s common practice these kind of
> > default values are specified normatively (with MUSTs or SHOULDs) as part
> of
> > the protocol spec as it gives simply implementor (that don’t know any
> better)
> > a high incentive to use these values (more than some examples values in
> the
> > appendix).
> >
> > I guess for a default value it’s doesn’t make a real difference to have
> a MUST
> > or SHOULD because it’s only the default which always implies that you may
> > use another value if you know better. However, thinking about
> > configuration, I think a MUST default value probably makes more sense
> > when then value is configurable because then there is another way to
> > change it and a MUST might avoid surprises if used unchanged. If the
> value is
> > not configurable maybe SHOULD makes more sense… again in practice there
> > is no difference; none of these mean that another value cannot be used
> but
> > only provide guidance about a safe default.
> >
> > Further you could also specify normative min and max values to give an
> > implementor or a user (that can configure these values) a better idea
> about
> > which range of values are safe to deploy. The values would be MUST
> > requirements if there is a known boundary that will cause the protocol
> to not
> > work anymore (as expected) or could also be SHOULDs just to give a better
> > idea of common or reasonable values (maybe together with a discussion
> > about bad thinks that can happen if a larger or smaller value is chosen).
> >
> > Mirja
> >
> >
> >
> > > On 6. Jan 2020, at 16:52, STARK, BARBARA H <[e-mail]> wrote:
> > >
> > >> 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=
>
>