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

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 6 Jan 2020 15:09:18 +0100

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

> On 17. Dec 2019, at 20:04, Juliusz Chroboczek <[email-masked]> 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
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 6 Jan 2020 15:52:49 +0000

> 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

> >>> 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >> 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.
> >
> > Yes, but that's irrelevant -- the Babel traffic is link-local, and
> > does not go outside the local routing domain.
> >
> > -- Juliusz
> >
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> 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=

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 6 Jan 2020 18:02:44 +0100

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 <[email-masked]> wrote:
> 
>> From: Mirja Kuehlewind
>> 
>> Hi Juliusz,
>>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 6 Jan 2020 21:54:20 +0000

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

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 6 Jan 2020 16:40:44 -0800

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 <[email-masked]> 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 ..."
> > I think this sentence you write is the core of the misunderstanding we
> might
> > have:

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 07 Jan 2020 12:49:59 +0100

Dear Mirja,

You made the very same proposition on 22 August 2019 (almost half a year ago!).
Here is what I replied at the time:

    I am sorry, but I disagree.  The original document that I submitted for
    IETF review back in 2009 had the structure that you suggest, but the
    reviewer (Joel Halpern) convinced me to a adopt the following structure:

      - the body of the document describes the main algorithm, the parts that
        are required to enforce the strong guarantees that the protocol makes
        about lack of loops and forward progress;
      - the appendices describe algorithms that have been shown to be useful
        over some link layers but that might need to be tweaked when Babel is
        run over new, exciting link layers.

    Since Joel did a good job convincing me, it will take some work to
    convince me otherwise.

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 7 Jan 2020 13:38:25 +0100

Hi Juliusz,

I did reply to this message a while ago.

I think this is a fine approach for algorithms (as you say below) however it is not useful for recommended parameters of an algorithm that is the define in the body of of the spec.

Also note that my point is not about interoperability but about safety. Often these kind of requirements are not enforceable by the protocol itself, so an implementator could diverge from the recommendation without breaking the protocol, however, it is still important to give the right recommendation in the spec. We all know that just writing a MUST or SHOULD in an RFC that will not automatically mean that is always done that way, however, that doesn’t mean that we don’t have to write it down.

Mirja

> On 7. Jan 2020, at 12:49, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear Mirja,
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 07 Jan 2020 20:16:51 +0100

> Also note that my point is not about interoperability but about safety.

I'm confused.

Interoperability is about different implementations interoperating without
endangering the integrity of the network.  What definition of safety do
you propose that is not covered by that?

In short -- what technical problem do you want us to solve that you have
witnessed with the three existing interoperable implementations of Babel,
or that you foresee with a future implementation?

-- Juliusz

---

From: Teco Boot <[email-masked]>
Date: Tue, 7 Jan 2020 20:55:02 +0100

Agreed.
This is in line with for example the OSPF RFCs.
But for unmanaged networks, good advice from an authority is almost mandatory.
For Homenets, this could be draft-ietf-homenet-babel-profile.

Teco

PS.
I don’t take the IETF suggested timers for modern LANs that serious...

> Op 7 jan. 2020, om 12:49 heeft Juliusz Chroboczek <[email-masked]> het volgende geschreven:
> 
> Dear Mirja,
> 
> https://www.ietf.org/mailman/listinfo/babel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 08 Jan 2020 01:26:14 +0100

Hi Teco,

> But for unmanaged networks, good advice from an authority is almost mandatory.

The advice is already there, it's in Appendix B, and it's referenced at
all the relevant points in the document.  However, Babel is designed so
that the exact values don't matter, so it's merely advice, not a recommendation.

That the exact values don't matter is the whole point of Babel -- it's
designed to interoperate in the presence of asymmetric configuration,
which is why it's useful in community and unmanaged networks.  If we start
recommending a default set of values, we obfuscate this fact, at which
point we're no longer communicating clearly why Babel might, in some
deployments, be a good alternative to OSPF.

I've repeatedly explained this back in August, but apparently wasn't clear
enough.

> For Homenets, this could be draft-ietf-homenet-babel-profile.

Homenet-babel-profile goes further than that -- it defines the set of
extensions required in order to implement Homenet routing (MUST IPv6,
SHOULD IPv4, MUST source-specific routing), and it defines the
interactions between HNCP and Babel.

-- Juliusz

---

From: Teco Boot <[email-masked]>
Date: Wed, 8 Jan 2020 07:52:54 +0100

> Op 8 jan. 2020, om 01:26 heeft Juliusz Chroboczek <[email-masked]> het volgende geschreven:
> 
> Hi Teco,
> 

I know and I agree.
So please try to finish this work.

> interactions between HNCP and Babel.

There is nothing on timers. OK, the rfc6126bis suggested timers make sense. 
But how can a homenet device vendor know to select one of the use cases? 
I also think the guidance for link costs for homenets has too much freedom.
IMHO, for Homenets, all of this needs strict rules.
But this is out of topic here.

I only wanted to suggest that there are other and better places to define the protocol 
parameters. This could help to close this discussion.

Teco

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 10:54:38 +0100

Hi Juliusz,

Just recommending default value doesn’t mean that anybody has to use the same values and it still conserves the benefits that babel works with a brought set of values. However, you already said that all deployed implementation use the same set of values, so what’s the point of not recommending these?

You made several times the point that babel is based on implementation and testing. Given all deployed implementations use the same values that actually is the only set that is really tested and therefore the only one that should be recommended.

You said:
"Interoperability is about different implementations interoperating without
endangering the integrity of the network.”

The smaller the time interval are that you use, the higher is the load on the network. That means certain configuration would endanger the integrity of the network if the network capacity is below the load that is generated by the updates and hello. 

This is not discussed in appendix B. Appendix B only talks about e.g. "networks with little mobility, and where occasional outages of up to 14 seconds are acceptable” but it doesn’t say anything about load. The effect of the chosen configuration on the network load/integrity needs further discussion and it needs this discussion in the body of the spec and not only in the appendix with relation to the concrete parameter values or a certain range of values.

Mirja

> On 8. Jan 2020, at 07:52, Teco Boot <[email-masked]> wrote:
> 
> 
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 08 Jan 2020 16:15:36 +0100

> The smaller the time interval are that you use, the higher is the load
> on the network. That means certain configuration would endanger the
> integrity of the network if the network capacity is below the load that
> is generated by the updates and hello.

Mirja -- this is not a transport-layer protocol that is deployed over
a heterogeneous Internet; it's a signalling protocol that is deployed over
the local link.  Since there are no intermediate routers to congest,
congestion control issues are very different from what you are used to.

The amount of signalling traffic that a Babel node generates is minuscule,
on the order of a few hundred bytes per second, a few kB/s in large
networks.  Since there are no intermediate routers to congest, the only
limiting factor is the speed of the local link.

> This is not discussed in appendix B.

Neither does RFC 5340.

There is no concensus whether congestion control for link-local signalling
protocols is a real issue.  If you believe that it is an issue, then
I encourage you to create a WG to deal with the issue in a general manner,
one that applies to OSPF, IS-IS, Babel and even DHCPv6 and ND.  (I know at
least one person who thinks like you, and would probably be interested in
participating; I, for one, would be interested in reviewing any documents
you produce.)

Requiring us to solve this (real or imagined) problem within the Babel WG
is not reasonable, just as it would not be reasonable to request that it
be solved within the OSPF WG.

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 16:30:36 +0100

Hi Juliusz,

This is not about congestion control. Congestion control is something that has a control loop and is based on feedback. This is not possible and not required here. However, limiting the total load a protocol can induce on a network is a common safety mechanism that I usually look for in all protocols including routing protocols. As explained already e.g OSPF has a limit because all interval values are in units of seconds, however, this is not the case here.

Even if the communication is link local, overloading that one link and the respective endpoint (or actually all neighbours) can have an impact on the network as a whole as this can also push away all other traffic. Even if the traffic rate generated by the protocol is low, you still have to make sure that it is lower than the local link capacity. That seems straight forward to us maybe but still some good advise to give in the spec.

Further if misconfigured it is still possible that the babel traffic does not stay local. So even for this unlikely error case we must insure that babel can’t crash the network.

I know this seem overly cautious because these are unlikely cases, however, that’s still makes it important to discuss them in proposed standard spec.

I don’t really understand the whole discussion here to be honest because I actually don’t ask for much. Why is it such a problem to recommend the one value set that you have tested and works well for all scenarios? Again, of course that doesn’t mean that all implementations have to use this and that was never what I asked for. And why do you think it is a problem to add more text in the spec that explains better the network impact of choosing these value, e.g. like calculating the load that is expected by the choice of certain value?

I don’t think we will make any progress here, as I have the feeling you are just unwilling to make any further changes to the document, and would like to ask Martin as the responsible AD to intervene and provide further guidance to both of us!

Mirja

> On 8. Jan 2020, at 16:15, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 08 Jan 2020 18:08:06 +0100

> As explained already e.g OSPF has a limit because all interval values
> are in units of seconds, however, this is not the case here.

I refer you to my mail of 17 December 2019 where I explain why this is not
the case.

> I have the feeling you are just unwilling to make any further changes to
> the document,

Over the last six months, Mirja, I have made dozens of changes, many of
which I don't feel improve the text at all.

What I'm unwilling to do is to break the structure of the document in
order to adress a problem that is purely hypothetical, and with no
commitment that you will actually clear your objection after I do that.

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 18:12:58 +0100

Hi Juliusz,

You didn’t make any concrete proposals for changes that I could commit to.

Mirja

> On 8. Jan 2020, at 18:08, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: "Mirja Kühlewind (IETF)" <[email-masked]>
Date: Wed, 8 Jan 2020 18:31:48 +0100

Hi again,

Please also note that changes you already did are good (maybe with the exception of adding the second set of example parameters which we are still discussing here) and they  address already part of my discuss. 

Also note that Alvaro also still has a discuss on the document which is also related to default parameters. Unfortunately I have the feeling we don’t make any further progress about this point in the discussion right and would therefore like to rely on Martin as the responsible AD for further advise.

Mirja 

> Am 08.01.2020 um 18:13 schrieb Mirja Kuehlewind <[email-masked]>:
> 
> Hi Juliusz,
>

---

From: David Schinazi <[email-masked]>
Date: Wed, 8 Jan 2020 18:35:10 -0800

Hi Mirja,

Thanks for recognizing that we have addressed parts of your DISCUSS. I
think that the document is better as a result. However, that doesn't mean
that we will make further changes only because you would prefer the
document to be a certain way.

If the only remaining part of your DISCUSS is the absence of normative
default values, then you have to consider whether delaying the document's
approval is the best path forward.

Juliusz and I are failing to understand what problem you're trying to
solve. I agree that you're asking for something small, but we won't make
changes to the document if we don't understand how they make the document
better. As discussed earlier in this thread, the issues you describe appear
to be unrelated to the routing protocol at hand.

Feel free to clarify what singles Babel out for mandatory default values,
but please consider that lifting your DISCUSS is also a viable option given
that this is a minor point.

Thank you,
David

On Wed, Jan 8, 2020 at 9:31 AM "Mirja Kühlewind (IETF)" <[email-masked]>
wrote:

> Hi again,
>
> Please also note that changes you already did are good (maybe with the
> exception of adding the second set of example parameters which we are still
> discussing here) and they  address already part of my discuss.
>
> Also note that Alvaro also still has a discuss on the document which is
> also related to default parameters. Unfortunately I have the feeling we
> don’t make any further progress about this point in the discussion right
> and would therefore like to rely on Martin as the responsible AD for
> further advise.
>
> Mirja
>
>