Subject: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 06:29:21 -0700

Alvaro Retana 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 really enjoyed reading this document!  Thank you for the work and time that
has gone into it.

However, I don't think that this specification is ready to be published as a
Proposed Standard.  In general, I don't think that the document is clear or
specific enough to be considered in the Standards Track -- that is the main
reason for this DISCUSS.

(A) Clear Defaults and Operational Guidance

While I appreciate Babel's flexibility in terms of the ability to use different
strategies, I believe that both defaults and clear guidance should be provided.
 Given that "not all...strategies will give good results" and that in most
cases these are listed as possible choices, I don't think that this document
"has resolved known design choices" [BCP9/rfc7127].  The cost/metric
computation and route selection specially concern me because I believe that a
robust/clear specification is at the heart of any routing protocol.

In general what I am looking for to resolve this part of the DISCUSS are two
items:

(A1) Clear defaults.  For example, Appendix B talks about constants/default
values.  I would assume that, given the existing experience, that the values
there are probably sensible defaults.  Is that not the case?

(A2) Operational Considerations.  Given that Babel can be (and is) used in
different environments, I would like to see guidance to operators as they
deploy the protocol in their networks.  An example of the type of discussion I
would like to see expanded is: "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" (§1.1).  Consider §2 in rfc5706 (Operational
Considerations - How Will the New Protocol Fit into the Current Environment?).

I believe that both items are important, specially in a protocol as flexible as
Babel.  Some of this guidance could have been included in
draft-ietf-babel-applicability -- but this information is not there either.

(B) Error Handling

Many sections of the document describe functionality, or even Normatively
mandate it, but there is no discussion about Error Handling.

(B1) Router-Id Setting

§4.5:
   o  the current router-id; this is undefined at the start of the
      packet, and is updated by each Router-ID TLV (Section 4.6.7) and
      by each Update TLV with Router-Id flag set.

It took me some time to figure out the reason for being able to carry the
router-id in two different places inside the same packet, which is my
interpretation of the "and" above.  Let me see if I understood:  a packet can
carry multiple updates...updates contain routes that were either originated by
the local node, OR, learned from other routers...the router-id matches the
originator...  So...if a packet carries multiple updates, some locally
originated and some learned, then it is possible for the packet to first
include (for example) a Router-ID TLV (indicating router-id_A), followed by
some Update TLVs (without the R-bit set), than then some other Update TLVs
(with the R-bit set)...

Did I understand correctly?  If so, I think there are significant pieces of
this operation that are not clearly specified in the document.  There is
mention of the effect of the Router-ID TLV (or the Update TLV w/R=1) on
subsequent Update TLVs...there is an very subtle hint (for my taste) in §4.5
(Parser state) about the state learned for each packet from those TLVs...but
there is no explicit text that talks about the need for strict ordering when
sending and later when processing...it is all simply implied.

What should happen if no Router-Id has been defined?  For example, an Update (R
= 0) is received but no Router-ID TLV is present...  What if the Router-ID TLV
is present, but *after* the Update?  There are many possible combinations...

(B2) Default Prefix

Similar comments as above...  "P (Prefix) flag...establishes a new default
prefix for subsequent Update TLVs with a matching address encoding within the
same packet" (§4.6.9).   What if an update with an AE that allows compression
is received *before* the one that sets the new default prefix?

(B3) Next Hop

§4.6.9:

   The next-hop address for this update is taken from the last preceding
   Next Hop TLV with a matching address family (IPv4 or IPv6) in the
   same packet even if it was otherwise ignored due to an unknown
   mandatory sub-TLV; if no such TLV exists, it is taken from the
   network-layer source address of this packet.

What if the Next Hop TLV doesn't exist and the network-layer doesn't correspond
to the address family in the Update?  For example, let's say IPv6 is used as
the network-layer protocol and the Update contains IPv4 prefixes...

(B4) For the Normative behavior listed here (I may have missed other
instances), I have basically the same question: what should a receiver do if it
is not the case?

- §3.8.1.2: "A node MUST NOT increase its sequence number by more than 1 in
response to a seqno request."

- §4: "A Babel packet MUST be sent as the body of a UDP datagram, with
network-layer hop count set to 1..."

- §4.6.9: "If the metric is finite, AE MUST NOT be 0.  If the metric is
infinite and AE is 0, Plen and Omitted MUST both be 0."

- §4.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix is of length
0)."

- §4.6.10/§4.6.11: Is AE 3 a valid value in a request?  I assume it isn't. 
What should a receiver do if AE = 3.

(C) Mandatory Bit

§4.4: "The most-significant bit of the sub-TLV, called the mandatory bit..." 
The most significant bit of which part of the sub-TLV?  As written, that bit
would be the first one in the Type, which corresponds to the text in the IANA
section.  Please be specific.

In the IANA considerations section, please include the whole registry in the
table to avoid confusion.

Note that because of the mandatory bit, the 128-239 range should be
Reserved...but it is currently marked as Unassigned.  Even worse, value 128 is
assigned already [draft-ietf-babel-source-specific].  The impact may not be too
bad because I doubt that Pad1 would need to be mandatory, but it at least
causes confusion and inconsistency, and (as currently specified) there would be
no way to differentiate between Pad1 and the Source Prefix sub-TLV.

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

(a) §3.1 introduces the term "urgent TLVs".

(1) It might be a good idea to explicitly mention/list which are these TLVs. 
There are some references in subsequent sentences, which may or may not be
enough for most readers.

(2) There are some Normative actions applied to them, for example "MUST be sent
in a timely manner".  While the intent may be ok, the Normative enforcement of
"in a timely manner" is not clear at all -- how do you comply with that? 
Appendix B says:

   The amount of jitter applied to a packet depends on whether it
   contains any urgent TLVs or not (Section 3.1).  Urgent triggered
   updates and urgent requests are delayed by no more than 200ms;
   acknowledgments, by no more than the associated deadline; and other
   TLVs by no more than one-half the Multicast Hello interval.

I think it would help if this text is moved to §3.1 to make it explicitly clear
what a timely delay is...and the text was changed to (something like) "MUST NOT
be delayed more than 200ms".

(b) §3.2.2: "SHOULD NOT increment its sequence number (seqno) spontaneously" 
When it is ok to increase the seqno spontaneously?  IOW, why not use MUST NOT? 
I think it would be better if there was a clear indication of when the seqno is
increased.  Scanning the rest of the document, it seems that those indications
are in place.

(c) There seems to be no specific explanation of how the timers are handled,
what happens when they expire, etc..  For example, §3.2.4 includes this text:

   There are three timers associated with each neighbour entry -- the
   multicast hello timer, which is initialised from the interval value
   carried by scheduled Multicast Hello TLVs, the unicast hello timer,
   which is initialised from the interval value carried by scheduled
   Unicast Hello TLVs, and the IHU timer, which is initialised to a
   small multiple of the interval carried in IHU TLVs.

But there is no explanation (that I could find) about how to manage those
timers.  The only place where hello timers are mentioned is in Appendix
A.1...but that is just an example.

(d) §3.7.2 includes two instances of "SHOULD make a reasonable attempt at
ensuring that all [reachable] neighbours receive this update/retraction".  What
does making "a reasonable attempt" mean?  How can that be Normatively enforced?

(e) §3.7.2

   Finally, a node MAY send a triggered update when the metric for a
   given prefix changes in a significant manner, due to a received
   update, because a link's cost has changed, or because a different
   next hop has been selected.  A node SHOULD NOT send triggered updates
   for other reasons, such as when there is a minor fluctuation in a
   route's metric, when the selected next hop changes, or to propagate a
   new sequence number (except to satisfy a request, as specified in
   Section 3.8).

How much is "a significant manner"?  What about "a minor fluctuation"?  Are the
modifiers (next hop change, for example) the only conditions to take into
account, or are they just examples of when these significant/minor changes may
occur?   How can these terms be Normatively enforced?

(f) §3.8.1.1: "When a node receives a wildcard route request, it SHOULD send a
full route table dump."  When is it ok to not send a full table dump?  IOW, why
is MUST not used?

(g) §3.8.2.1: "a node SHOULD repeat such a request a small number of times if
no route becomes feasible within a short time."  What does "a small number of
times" and "within a short time" mean?  How can that be Normatively enforced? 
Please be specific.

(h) §4.6.9: "Omitted...that should be taken from a preceding Update TLV in the
same address family with the Prefix flag set."  What if that Update TLV is not
in the packet?

(i) Security Considerations

The initial vulnerability listed ("attacker can misdirect data traffic by
advertising routes with a low metric or a high seqno") is only one of several
actions an attacker can take.  More importantly, if the attacker happens to be
in control of an authenticated node, then the mitigation proposed doesn't help.
 This type of rogue node can, for example, set the mandatory bit in an unknown
TLV (as in completely made up!) to cause whole TLVs to be ignored, resulting in
loss of routes, etc..

I am not sure what can be done to mitigate this type of vulnerability...but I
think it is important that it is at least called out.

(j) Are the appendices intended to be Normative or not?  I'm assuming the
answer is no...but I can base that only on the references in the text to
Appendix A.*, pointing to them as examples.  What about the others?  They are
not even referenced in the text.  Some comments:

- Appendix B talks about constants/default values.  See my DISCUSS comments
above.

- Appendix C "is intended to guide designers of protocol extensions in chosing
a particular encoding."  I think is is valuable information.  It would be very
nice if there was a reference (or perhaps several, from where the different
extensibility methods are presented) in the main body of the specification.  I
can see how this is an informative section.

- Appendix D defines a "stub implementation".  This is also valuable
information.  But...there's no reference from the text, and Normative language
is used...  Why is this type of implementation (which I would think might be
relatively common) not normative?

- Appendix E simply points to the sample implementation.  Personally, I would
prefer to see an rfc7942 section instead -- it would have been nice to also
mention other implementations.

(k) "The length of..." is used everywhere in the document, but no units are
mentioned.  Some seem to obviously be in octets, but others could easily be in
bits...

(l) §4: s/SHOULD attempt to maximise the size of the packets/SHOULD maximise
the size of the packets

(m) §4.1.3: The description of AE 1 and 2 says that "Compression is allowed."
-- but it looks like the only place where it can happen is in an Update.  It
might be nice to indicate that...and avoid indicating that compression is not
allowed where it can't be done anyway.

(n) rfc8126 should be a Normative reference.

(o) Please include Informative references to rfc6126 and rfc7557.

(p) s/Bellman-Ford protocol/Bellman-Ford algorithm

(q) §2.4: Include an Informative reference to AODV (rfc3561).

(r) §2.4: "if A has selected B as its successor"  This is the only place where
"successor" is used.  For clarity, perhaps use a different word/description.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 17:44:24 +0200

Dear Alvaro,

Thank you very much for your detailed review, and thank you for the kind words.

> While I appreciate Babel's flexibility in terms of the ability to use
> different strategies, I believe that both defaults and clear guidance
> should be provided.

You'll doubtless agree that we must be careful here.  We are in a universe
in which there exist perfectly good routing protocols that operators are
already comfortable with (notably OSPF and IS-IS).  Babel's niche is the
ability to adapt to environments where OSPF and IS-IS do not work well; if
we restrict this flexibility too much, our niche vanishes.

> Given that "not all...strategies will give good results" and that in
> most cases these are listed as possible choices, I don't think that this
> document "has resolved known design choices" [BCP9/rfc7127].  The
> cost/metric computation and route selection specially concern me because
> I believe that a robust/clear specification is at the heart of any
> routing protocol.

The point here is that Babel will still converge and will still behave in
a loop-free manner whatever the algorithm chosen, as long as the conditions
described in Section 3.5.2 hold.  (This is provably true in the case where
the metric is left-distributive, and believed to hold even if it is not.)

I'll expand on the description of the suggested algorithms in Sections 3.5.2
and 3.6.  However, I shall not make it a MUST, for the reasons outlined above.
I hope that's okay with you.

> there are probably sensible defaults.  Is that not the case?

I liken this to BFD.  RFC 5880 does not give any default values for its
timers, since the suitable values depend so much on the environment.

The values suggested in Appendix B are suitable for a reasonably stable
network where outages on the order of 6 to 10 seconds are acceptable.  In
mobile networks, Hello intervals of 0.5 yield better results.  To the
contrary, people running Babel over stable tunnels have been using much
larger intervals.

> (A2) Operational Considerations.  Given that Babel can be (and is) used
> in different environments, I would like to see guidance to operators as
> they deploy the protocol in their networks.  An example of the type of
> discussion I would like to see expanded is: "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" (§1.1).
> Consider §2 in rfc5706 (Operational Considerations - How Will the New
> Protocol Fit into the Current Environment?).

This is not clear to me.  What exactly are you requesting here?

As to your remaining points, I'll work on them, and reply once I've
implemented your suggestions.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 17:44:33 +0200

Dear Alvaro,

-- Juliusz

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 7 Aug 2019 12:34:30 -0700

On August 7, 2019 at 11:44:34 AM, Juliusz Chroboczek ([email-masked]) wrote:

Dear Juliusz:

Hi!

and 3.6. However, I shall not make it a MUST, for the reasons outlined
above.
I hope that's okay with you.

It doesn’t have to be a MUST, but I would really want to see something
RECOMMENDED.

Look at rfc7419; it Updates rfc5880 to define a set of Common Intervals.
>From the Shepherd writeup: "While the draft recommends a number of timer
values, they are suggested for interoperability while not mandating that
any particular value be supported."

This is exactly what I’m looking for.  You don’t need to absolutely mandate
(MUST) specific settings, but can say “for these conditions (just like
above) then the RECOMMENDED settings are...”.   This opens the door because
“there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and carefully
weighed before choosing a different course” [rfc2119], which is where the
second part (below) comes in.

What should be the Operational Considerations for different environments
that (without explicitly mandating anything) will guide the operator to
change the recommended defaults?  For example, you mentioned above that
"people running Babel over stable tunnels have been using much larger
intervals”…ok, that’s good…why?  What are the characteristics of that type
of deployment that would make an operator consider different values?
Specifically, what would make them consider much larger intervals?  What
are the advantages?  What are possible disadvantages of not doing so?

IOW, if someone other than the implementers decide to deploy Babel, what
should they take into account when selecting a strategy or setting?

I hope this makes sense.

Thanks!

Alvaro.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 23:03:43 +0200

> I hope this makes sense.

I'll take my pen and my inkpot, and see what comes out.

Thanks for your patience, Alvaro.  Your explanations are helpful.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 08 Aug 2019 14:59:14 +0200

Dear Alvaro,

This mail deals with your Discuss points (B) and (C).  I haven't decided
what to do about (A) yet.

> mandate it, but there is no discussion about Error Handling.

In most cases, no explicit check is necessary, or even possible.  In other
cases, the TLV is ignored, which is the general approach taken in Babel
with unparseable TLVs.  I've added explicit error handling in cases where
I find it suitable.

> router-id in two different places inside the same packet,

[...]

> Did I understand correctly?  ...it is all simply implied.

You appear to have missed Section 3.5.3 "Encoding of updates", which
probably indicates that it was at the wrong sport.  I have now expanded
this section, merged it into Section 4.5 "Parser state", and added
backward references at suitable points.

> What should happen if no Router-Id has been defined?

Clarified requirement to ignore the Update TLV.

> (B2) Default Prefix

As above.

> (B3) Next Hop

As above.

> instances), I have basically the same question: what should a receiver
> do if it is not the case?

Most of these require no check on the receiver side, in may cases
a receiver-side check is impossible.

> response to a seqno request."

This is a requirement for the sender.  When the receiver notices that the
seqno has increased, it cannot possibly know how many requests the sender
has reaceived in the meantime.

> network-layer hop count set to 1..."

This is a requirement for the sender.  No receiver side check is required
or even possible.

> infinite and AE is 0, Plen and Omitted MUST both be 0."

Added requirement to drop the Update TLV if violated.

> - §4.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix is of
> length 0)."

No clarification is necessary here, just like no clarification is
necessary that for an IPv4 address, plen <= 32.

> What should a receiver do if AE = 3.

This case is allowed -- there's nothing in the protocol that disallows
announcing routes within fe80::/64.  Of course, it would be silly to do so.

> section.  Please be specific.

This was a typo, noticed by Éric Vyncke.  The most-significant bit of the
sub-TLV *Type*.

The sub-TLV value consists of the whole 8 bits.  TLV numbers 0 through 127
are non-mandatory, 128 through 255 are mandatory.

> table to avoid confusion.

I'm confused.  Wouldn't that force me to do a number of downrefs?

> Reserved...but it is currently marked as Unassigned.

No, this range is unassigned.  Mandatory but unassigned.

> Even worse, value 128 is assigned already [draft-ietf-babel-source-specific].

That is correct.  The source prefix is a mandatory TLV.  Value 128 has
nothing to do with Pad1, which has value 0.

-- Juliusz

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 8 Aug 2019 13:01:44 -0700

On August 8, 2019 at 8:59:16 AM, Juliusz Chroboczek ([email-masked]) wrote:

Juliusz:

Hi!

Thank you for being so responsive!

In some cases below you’re indicating actions you’ve taken (clarified,
merged the text, etc.).  I’ll wait for the updated document. :-)

Unparseable (as in unreadable, unrecognized, etc.) TLVs are not the same as
what I’m pointing to here.  The case I’m pointing out is where the behavior
is not as expected: the text mandates something, but the receiver gets
something else.

...

Ahh…I see.  The increase MUST NOT be more than 1 per request.  That part
was not clear to me.

Well, if the received TTL > 1 then the receiver knows something is wrong.

Please take a look at rfc5082 and consider using that mechanism instead.

...

What do you mean by “no clarification is necessary”?

I understand why the values are 0.  What I’m asking for is what should the
receiver do if AE = 0 and Plen = n (any number other than 0)?

Silly doesn’t mean that someone won’t try it…and may end up filling up
someone else’s table with garbage.  I think this is a vulnerability.

As a point of reference, OSPFv3 doesn’t allow the advertisement of
link-local addresses as destinations.  I strongly suggest Babel do the same
thing.

No…I think the references to draft-chroboczek-babel-diversity-routing (and
the other drafts) can be Informative.

This was not clear to me either…thanks for clarifying!

Because the use of the bit is explained as a bit then my interpretation was
that any sub-TLV could set the bit…

I think it would be better if in §4.4 the text described a mandatory
sub-TLV, not just a mandatory bit.  Perhaps:

   The most-significant bit of the sub-TLV type (the bit with value 80

   hexadecimal), called the mandatory bit, determines if the sub-TLV is

   mandatory or not.  An unknown sub-TLV MUST be silently ignored, and the
rest

   of the TLV is processed normally.  If an unknown mandatory sub-TLV is

   received, then the whole enclosing TLV MUST be silently ignored (except
for

   updating the parser state by a Router-Id, Next-Hop or Update TLV, see

   Section 4.6.7, Section 4.6.8, and Section 4.6.9).

Also, please label the registry so that it is easier for everyone going
forward to identify the range for mandatory sub-TLVs.  I know you’re the
Designated Expert in the registry…but better to cover all the bases. ;-)

Thanks!

Alvaro.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Aug 2019 00:12:21 +0200

> Ahh…I see.  The increase MUST NOT be more than 1 per request.  That part was
> not clear to me.

Ah, I think I see the problem: "in response" is ambiguous.  I'll change it
to "in reaction".

 
> Well, if the received TTL > 1 then the receiver knows something is wrong.

Sure, but there's not much that this check buys you.

> Please take a look at rfc5082 and consider using that mechanism instead.

That's what ND does, right?

It was considered (in the dark times before Babel was at IETF), and
rejected.  We behave like RIPng and OSPFv3: we use link-local addresses
with a TTL of 1, and require checking that the source address of
a received packet is link-local.

At any rate, changing it at this stage would break compatibility with the
installed base, which would be the death of Babel.

> What do you mean by “no clarification is necessary”?

I'll add a mention, but I believe it is redundant.

No explicit mention that IPv4 routes with a prefix length of 57 are
malformed and must be ignored.  That's because IPv4 routes have a maximum
prefix length of 32.

Analoguously, AE 0 has a maximum prefix length of 0, and it si redundant
to mention explicitly that AE 0 routes must not have a plen of 57.

> receiver do if AE = 0 and Plen = n (any number other than 0)?

It's a malformed prefix.  You ignore the TLV, just like you would ignore
a TLV that announces 1.2.3.4/57.

> Silly doesn’t mean that someone won’t try it…and may end up filling up someone
> else’s table with garbage.  I think this is a vulnerability.

Sure.  I agree with you that a robust implementation of Babel should
filter out fe80::/64, ff00::/8, as well as 0/8, 127.0.0.1/32 and 224.0.0/24.
I just don't agree this filter needs to be hardwired in the protocol
specification, it's an implementation detail and should be configurable.

A case in point: babeld used to filter out Class-E addresses, and then
this happened:

  https://alioth-lists.debian.net/pipermail/babel-users/2018-December/003492.html

> As a point of reference, OSPFv3 doesn’t allow the advertisement of link-local
> addresses as destinations.

OSPFv3, like all link-state protocols, requires uniform filtering rules
within an area, so it makes sense to standardise a default set of
filtering rules.  Babel, like any distance-vector protocol, has no such
limitation (nodes with different filtering rules will interoperate just
fine), so it's much more reasonable to leave filtering to the implementation.

-- Juliusz

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 9 Aug 2019 06:38:31 -0500

On August 8, 2019 at 6:12:24 PM, Juliusz Chroboczek ([email-masked]) wrote:

...

But that doesn’t cover IPv4 properly.

Are you saying that if both an IPv4 and IPv6 network-layer is available
then IPv6 should be preferred?  I think that would be a good statement to
make.

Not if you make it optional.

I brought this comment up because the text says that “Plan MUST be 0”.

There are (I think) two different cases:

- Plen doesn’t make sense, IPv4/57, for example.  This is clearly malformed.

- Plen doesn’t matter.  In the case of AE = 0 in a Route Request, does it
really matter what Plen is set to?  IOW, if the request is ignored then no
routes are provided…

Going back to the use of MUST.   I think consistency is important.  In this
case, there’s no explicit text saying that for AE = 1 Plen MUST be <=32.  I
then think it is ok to not make normative the setting for AE = 0.  s/Plen
MUST/Plen must

> Silly doesn’t mean that someone won’t try it…and may end up filling up
someone

> As a point of reference, OSPFv3 doesn’t allow the advertisement of
link-local

fine), so it's much more reasonable to leave filtering to the
implementation.

Ok.  While I still think that not filtering out link-local routes is a
vulnerability, please at least mention it: “An implementation may consider
filtering useless information…or should provide configuration filters….
These are the considerations to do so (or not): potential too much garbage…”

Thanks!

Alvaro.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Aug 2019 14:39:48 +0200

Would adding the following informative appendix solve the problem?  Are
you going to complain that it's not referenced in the document body?

Appendix C.  Route filtering

   Route filtering is a procedure where an instance of a routing
   protocol either discards some of the routes announced by its
   neighbours or learns them with a metric that is higher than what
   would be expected.  Like all distance-vector protocols, Babel has the
   ability to apply arbitrary filtering to the routes it learns, and
   implementations of Babel that apply different sets of filtering rules
   will interoperate without causing routing loops.  The protocol's
   ability to perform route filtering is a consequence of the
   definitions in Section 3.5.2: Babel can use any metric that is
   strictly monotonic, including one that assigns an infinite metric to
   a selected subset of routes.  (See also Section 3.8.1, where requests
   for nonexistent routes are treated in the same way as requests for
   routes with infinite metric.)

   It is not in general correct to learn a route with a metric smaller
   than the one it was announced with, or to replace a route's
   destination prefix with a longer one.  Doing either of those may
   cause persistent routing loops.

   Route filtering is a useful tool, since it allows fine-grained tuning
   of the routing decisions made by the routing protocol.  Accordingly,
   some implementations of Babel implement a rich configuration language
   for configuring route filtering.  At a minimum, these implementations
   allow selecting routes for filtering by incoming interface and by
   destination prefix.

   In order to limit the consequences of misconfiguration, Babel
   implementations provide a reasonable set of default filtering rules
   even when th don't allow configuration of filtering by the user.  At
   a minimum, they discard routes with a destination prefix in
   fe80::/64, ff00::/8, 127.0.0.1/32, 0.0.0.0/32 and 224.0.0.0/8.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 9 Aug 2019 05:51:28 -0700

On August 9, 2019 at 8:39:52 AM, Juliusz Chroboczek ([email-masked]) wrote:

Would adding the following informative appendix solve the problem?

Yes, it would address the filtering part.

Are you going to complain that it's not referenced in the document body?

Yes.

I think that you could either reference it in one of the sections mentioned
in it…or maybe you just want to provide a information about the appendices
somewhere in the Introduction.  Either way would be fine for me.

Thanks!

Alvaro.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Aug 2019 15:54:41 +0200

> Are you saying that if both an IPv4 and IPv6 network-layer is available then
> IPv6 should be preferred?  I think that would be a good statement to make.

Yes, that has been the WG consensus for a long time (all implementations
known to me run in that mode).  However we only wrote it down recently at
Eric Vyncke's prompting (my bad).  Section 3.1:

   The exclusive use of IPv6 for all control traffic is RECOMMENDED,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Aug 2019 22:07:01 +0200

Dear Alvaro,

This mail concerns your Discuss point (A) and your Comments.  Discuss
points (B) and (C) have been discussed in an earlier mail.

> should be provided.  Given that "not all...strategies will give good
> results" and that in most cases these are listed as possible choices,
> I don't think that this document "has resolved known design choices"
> [BCP9/rfc7127].  The cost/metric computation and route selection
> specially concern me because I believe that a robust/clear specification
> is at the heart of any routing protocol.

After thinking it over very carefully, it is with utmost sadness that
I must disagree with you on this latter point.

This document does three things:

  - it makes normative requirements where the issues are well-understood
    (e.g. strict monotnicity of the metric);
  - in all cases, it suggests algorithms that are known to work well;
  - it gives a statement of caution to the adventurous implementer.

This gives enough information to the implementer to implement something
that works, while not unduly restricting the possibilities of future
experimentation.

Compare this with RFC 4271, which proudly states:

   BGP can support any policy conforming to the destination-based
   forwarding paradigm.

even though many such policies will cause persistent oscillations.  (By no
fault of theirs -- determining statically if a given set of BGP route
policies gives rise to oscillations is an open research problem.)

(FWIW, early drafts of RFC 6126 used to describe cost and metric
computation normatively.  It was Joel Halpern who convinced me to move
them to an informative appendix, and to give more flexibility in the core
protocol.  The results we have obtained with RTT-sensitive routing show
that he was entirely right.)

> there are probably sensible defaults.  Is that not the case?

I've rewritten Appendix B in the way you suggest, and added references to
it in the document.

> intervals, etc.) than a node that has access to wall power" (§1.1).

I've expanded Appendix B.

> (B) Error Handling

Discussed in a previous mail.

> (C) Mandatory Bit

Discussed in a previous mail.

> (a) §3.1 introduces the term "urgent TLVs".

The whole paragraph has been rewritten, and the terminology unified
throughout.

> (b) §3.2.2: "SHOULD NOT increment its sequence number (seqno)
> spontaneously" When it is ok to increase the seqno spontaneously?

It is always ok.  The worst it can do is prematurely make some unselected
routes unfeasible at downstream nodes, which they will recover from.

This is intended as a warning to the implementer familiar with DSDV where
seqnos are incremented periodically.

> IOW, why not use MUST NOT?

This document is fairly consistent in its usage of MUST NOT and SHOULD
NOT.  You MUST NOT break the network.  You SHOULD NOT do harmless but
pointless things.

> I think it would be better if there was a clear indication of when the
> seqno is increased.  Scanning the rest of the document, it seems that
> those indications are in place.

I'm fairly positive this is the case.  Starvation avoidance is a crucial
part of the algorithm.

> what happens when they expire, etc.

I have added some precisions.

> The only place where hello timers are mentioned is in Appendix A.1...but
> that is just an example.

This is expected.  Hellos are used to compute link cost, and cost
computation is in Appendix A.

> (d) §3.7.2 includes two instances of "SHOULD make a reasonable attempt
> at ensuring that all [reachable] neighbours receive this
> update/retraction".  What does making "a reasonable attempt" mean?

This is expanded in the next two paragraphs.

> How can that be Normatively enforced?

If an implementation implements one of the two algorithms, it complies.
If an implementation implements a different algorithm that can be shown to
have the same effect, it complies.  If an implementation doesn't implement
any algorithm that has a similar effect, it doesn't comply.

> How much is "a significant manner"?  What about "a minor fluctuation"?
> Are the modifiers (next hop change, for example) the only conditions to
> take into account, or are they just examples of when these
> significant/minor changes may occur?

I'm not sure what you're aiming for here.  This enumeration lists a set of
events for which an implementer might be tempted to send a triggered
update, and states that it's a bad idea.

> How can these terms be Normatively enforced?

In order to comply, an implementation:

  - doesn't send an update when the metric changes by 1 and nothing else
    changes;
  - doesn't send an update when NH changes and nothing else changes;
  - doesn't send an update when seqno changes and nothing else changes.

The boundary between minor and major fluctuation is left to the
implementation, which is okay, since in any case that's only a MAY.  The
intent being that it's reasonable to send a triggered update when the
metric fluctuation is large enough to indicate that the route has probably
become unusable.  If the implementation doesn't follow the MAY, then the
fluctuation will be propagated by the next periodic update.

> (f) §3.8.1.1: "When a node receives a wildcard route request, it SHOULD
> send a full route table dump."  When is it ok to not send a full table dump?

It is always okay to not send one.  The protocol does not rely on full
route dump requests.  The ability to make a full route dump makes
debugging easier, and the feature has very little implementation cost
(since you already have code to send a full dump).

> IOW, why is MUST not used?

Because you might be rate limiting the updates.  I've added a sentence to
that effect.

> times" and "within a short time" mean?  How can that be Normatively enforced? 

Suggested values are given in Appendix B:

      Request timeout: initially 2 seconds, doubled every time a request
      is resent, up to a maximum of three times.

I've added a forward ref.

> (h) §4.6.9: "Omitted...that should be taken from a preceding Update TLV
> in the same address family with the Prefix flag set."  What if that
> Update TLV is not in the packet?

That's part of error handling, your Discuss above.

> (i) Security Considerations

We've rewritten this section.

> Appendix A.*, pointing to them as examples.

I've removed all normative language from the appendices.

> What about the others?  They are not even referenced in the text.

Appendices A and B are referenced.  I've added a reference to what was
Appendix C (now D).

> is used...

This is not references in the main body.  I don't see a good way to
reference it.

I've removed all normative language from this appendix, since all the
properties stated are consequences of the protocol definition.

> Why is this type of implementation (which I would think might be

This appendix doesn't add any new requirements -- it merely describes what
is in our opinion the smallest useful implementation that complies with
the body of the spec.  It is a convenience for the implementer.

> - Appendix E simply points to the sample implementation.

I've removed the whole appendix.

> mentioned.

Added suitable boilerplate.

> (l) §4: s/SHOULD attempt to maximise the size of the packets/SHOULD maximise

Done.

> allowed where it can't be done anyway.

Done.

> (n) rfc8126 should be a Normative reference.

Done.

> (o) Please include Informative references to rfc6126 and rfc7557.

Done.

> (p) s/Bellman-Ford protocol/Bellman-Ford algorithm

Done.

> (q) §2.4: Include an Informative reference to AODV (rfc3561).

Done.

> "successor" is used.  For clarity, perhaps use a different word/description.

Done.

-- Juliusz

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 20 Aug 2019 13:54:47 -0700

On August 9, 2019 at 4:07:03 PM, Juliusz Chroboczek ([email-masked]) wrote:

Juliusz:

Hi!  Sorry for the delay in getting back to you...

It also makes me sad that we’re not agreeing.

Specification doesn’t necessarily preclude experimentation…or deviation
from the defaults.

Without a clear specification I’m afraid that the text still reads like an
Experimental document to me.

Yes, but it also specifies a clear Decision Process to guarantee that "BGP
speakers within an AS do not make conflicting decisions regarding route
selection that would cause forwarding loops to occur.” (§9.1.2).
Flexibility is build in, even allowing a Custom Decision Process [1], but
defining what the base behavior should be to guarantee consistency.  BGP
speakers can have their own policies, but within a clear set of rules
starting from a base behavior: we all know from rfc4271 what the default is.

[1] https://tools.ietf.org/html/draft-ietf-idr-custom-decision

[Aside: Still inside an AS, the persistent oscillations [rfc3345] are the
result of constrained information from route reflectors [rfc4456] or
confederations [rfc5065]…which are extensions to the base.]

I think that BGP is in fact a good example of what I am asking for:  There
are all kinds of options and variations that individual ASes can decide to
implement…but rfc4271 clearly defines what the default behavior is.

...

...

The reason I’m asking these questions is because rfc2119 says that the
keywords defined there "MUST only be used where it is actually required for
interoperation or to limit behavior which has potential for causing harm”.
By using “MAY” (in this specific case) I assume that the document is trying
to define a behavior that can be expected across implementations…but the
explanation indicates the opposite: the intent is not to define a common
behavior.  IMO, you then shouldn’t use rfc2119 keywords in these cases.

Thanks!

Alvaro.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 21 Aug 2019 03:17:23 +0200

> Experimental document to me.

As explained previously, the normative language in this document
guarantees the lack of forwarding loops (this has been proven).
Additionally, the non-normative advice (Appendix A.2 and the penultimate
paragraph of Section 3.6) guarantees convergence and the lack of
persistent oscillations (this hasn't been formally proven yet, but we're
all convinced that's the case).

This is way more than BGP does, which only guarantees the lack of
forwarding loops, and only after convergence (unlike Babel, BGP makes no
attempt to avoid transitory loops).  It is my understanding that BGP does
not guarantee the lack of oscillations, not even in the absence of
Confederations or Route Reflectors, and not even if the algorithm
specified in RFC 4271 Section 9.1.2 is followed.  Please see

  K.Varadhan, R.Govindan, and D Estrin. Persistent route oscillations in
  inter-domain routing. Computer Networks, 32:1–16, 2000.

Please be aware that this is not a criticism of BGP -- this is pretty much
the best we can do given the current state of the art without impairing
BGP's flexibility.  The same is true of Babel.

> selection that would cause forwarding loops to occur.” (§9.1.2).

We're not discussing loops, Alvaro, we're discussing oscillations.  I am
reasonably sure that Rekhter does not claim lack of oscillations.

> By using “MAY” (in this specific case) I assume that the document is
> trying to define a behavior that can be expected across
> implementations…

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

-- Juliusz