Skip to main content

Source-Specific Routing in the Babel Routing Protocol
draft-ietf-babel-source-specific-08

Yes

(Martin Vigoureux)

No Objection

(Deborah Brungard)
(Magnus Westerlund)

Note: This ballot was opened for revision 06 and is now closed.

Erik Kline
No Objection
Comment (2020-11-04 for -07) Sent
[[ nits ]]

[ section 4 ]

* Per RFC 5952 section 4.3, please s/2001:DB8/2001:db8/g
Murray Kucherawy
No Objection
Comment (2020-11-04 for -07) Sent
What's an example of when one might deviate from the SHOULD in Section 4?
Roman Danyliw
No Objection
Comment (2020-11-02 for -07) Not sent
Thank you to Rifaat Shekh-Yusef for performing the SECDIR review and thank you to the authors for responding to it.
Warren Kumari
(was Discuss) No Objection
Comment (2021-04-21) Sent
Thanks for addressing my concerns - DISCUSS cleared.
Éric Vyncke
(was Discuss) No Objection
Comment (2020-11-05 for -07) Sent
[Dear all, please accept my apologies for the wrong DISCUSS point... a copy and paste error done without enough coffee... There are NO DISCUSS point in my ballot]

Thank you for the work put into this document. The document is easy to read albeit not always clear and specific (see later). The topic of source address dependent routing is really critical for IPv6 deployment, so, I really appreciate your work on the topic

Please find below some non-blocking COMMENT points, and some nits.

I also second Warren's DISCUSS on the lack of clarity in the section 4 example

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is an expired RTG WG adopted document and is not even cited as informative reference.

Same for reference to RFC 8678.

-- Section 3.1 --
Is the first "prefix" the "destination prefix" in the following text? If so, then I suggest to write "destination prefix" or explain what is this "prefix" with reference to the Bable RFC:
   "The source table is now indexed by triples of the form (prefix,
   source prefix, router-id)."

-- Section 4 --
May I suggest to add another example with 2 entries have the same destination prefix but different source prefixes ? 

-- Section 6 --
May be my lack of knowledge in Babel is the reason why I do not understand the loop avoidance description... As written in the text, a single non-source-aware router in the network could be enough to introduce loop (in specific configurations). Writing the following text appear to me as a little hand waving because how can this be ensure (I was about to file a block DISCUSS on this but I am trusting the routing AD on this topic):
"  Consequently, this extension MUST NOT be used
   with routers implementing RFC 6126, otherwise persistent routing
   loops may occur."

-- Section 6.2 --
The last paragraph is also a little hand waving where it is assumed that network topology/configuration is specific to avoid a route starvation.

-- Section 7.1 --
Should the text state the obvious by stating that the prefix (non 8 multiple) is padded with bits set to 0 on transmission and those bits are ignored on reception ?

== NITS ==

-- Section 4 and possibly others --
Please use RFC 5952 to write IPv6 addresses.

-- Section 5.2 --
Please introduce the "AE" acronym at first use (even if guessable in the context).
Martin Vigoureux Former IESG member
Yes
Yes (for -06) Unknown

                            
Alvaro Retana Former IESG member
(was Discuss) No Objection
No Objection (2021-04-22) Sent for earlier
[Thanks for addressing my DISCUSS.]
Barry Leiba Former IESG member
No Objection
No Objection (2020-10-29 for -07) Sent
Thanks for an easy read.  I have only some minor comments:

— Section 5.2 —
Please expand “AE” on first use.  You should also do the same in Section 4.1.4 of draft-ietf-babel-rfc6126bis.

   A node MUST NOT send
   a wildcard retraction with an attached source prefix, and a node that
   receives a wildcard retraction with a source prefix MUST ignore it.

The “it” here is ambiguous: please specify “MUST ignore the source prefix” or “MUST ignore the retraction”.  The same comment applies also to the subsequent paragraph.

— Section 6.1 —
For what it’s worth, I don’t find the diagram to add anything to the text, and I wouldn’t have a clue what the diagram was trying to say without the text.

   Packets
   destined to D but not sourced in S will be forwarded by A to B, and
   by B to A, causing a persistent routing loop

That text is describing not what will happen with this standard, but what *would* happen if this standard didn’t correct for it.  So please change “will be forwarded” to”would be forwarded”, or perhaps “would then be forwarded”.  And in the previous sentence, change “merely ignores” to “merely ignored”.  These make it clearer that they’re talking about a hypothetical situation that’s counter to what’s specified herein.
Benjamin Kaduk Former IESG member
No Objection
No Objection (2020-10-30 for -07) Sent
Section 3.1

   Note that the route entry contains a source (see sections 2 and 3.2.5
   of [BABEL]) which itself contains a source prefix.  These are two
   very different concepts that should not be confused.

I appreciate having this note; thanks.  I wonder if it is worth
reiterating that the stock [BABEL] "source prefix" is the prefix of the
source of the routing information, to jog the reader's memory.

Section 5.1

   Prefix sub-TLV.  When a node receives a source-specific Update
   (prefix, source prefix, router-id, seqno, metric) from a neighbour
   neigh, it behaves as described in [BABEL] Section 3.5.4, except that

It looks like some section renumbering has occurred, as §3.5.3 of
draft-ietf-babel-rfc6126bis-20 looks much more relevant than §3.5.4
does.

   the entry under consideration is indexed by (prefix, source prefix,
   neigh) rather than just (prefix, neigh).

[The two prefix lengths are implicit now, though were explicit in
[BABEL]?]

Section 5.2

We should probably expand "AE" on first use.

Section 6.2

Is there also the possibility of a kind of starvation where
source-specific routers do not get source-specific routes because the
source-specific routes are dropped by non-source-specific routers
between them and the source of the route advertisement?  Intuitively, it
seems that once you have a connected backbone of source-specific routers
this would only happen if a given source-specific router only has paths
to the backbone that go through non-source-specific routers, and so the
router in question is effectively operating in a non-source-specific
mode, but perhaps there are more interesting scenarios in the absence of
such a backbone.

   A simple yet sufficient condition for avoiding starvation is to build
   a connected source-specific backbone that includes all of the edge
   routers, [...]

I'm not sure I understand what "connected backbone that includes all of
the edge routers" is intended to mean.  If the edge routers are to be
included in the connected backbone (i.e., to implement source-specific),
then wouldn't that make the connected backbone basically all routers?
Or is the intent that any given edge router has a link to a router in
the backbone?  Or something else?

Section 7.1

If I recall correctly, Babel sub-TLVs do not admit sub-sub-TLVs, so we
would treat a sub-TLV "length" that indicates more bytes of payload than
indicated by the "source plen" as an encoding error and reject the
sub-TLV, right?

   Source Plen  The length of the advertised source prefix.  This MUST
             NOT be 0.

Please use "length in bits" to match 6126bis.

Section 7.3

Should we consider being consistent about the use of parentheses around
"route" in the section heading and section body?

Section 7.4

Just to check my understanding: we do not expect issues where (e.g.) a
source-specific seqno request is sent to a non-source-specific node and
thus dropped, because seqno requests are supposed to be sent only to
nodes that are or in the past were advertising a (possibly non-feasible) route
for that prefix.  Such a source-specific advertisement would only be sent
by a source-specific node, that would accordingly not drop the seqno request.

Section 9

I was surprised to see in a quick check of 6126bis that there did not
seem to be a prominent mention in the security considerations of "make
sure your parser handles TLVs that indicate a length larger than the
size of the packet".  Should there be one?

Other than that (which is not really even a comment on this document), I
like the security considerations here: they're clear on the consequences
of the new behaviors from this protocol extension, and give enough
examples of how that might impact the security properties of the system
as a whole.  Thank you!

   The extension defined in this document adds a new sub-TLV to three
   TLVs already present in the original Babel protocol, and does not
   change the security properties of the protocol itself.  However, the

We might as well toss another [BABEL] in here; they're cheap.

Section 11.1

We cite BCP84 as part of the line "which is compatible with [BCP84]".
That in and of itself does not necessarily seem like enough to justify a
normative relationship, though perhaps there are other reasons why it is
needed.
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Martin Duke Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2021-04-21) Sent
Thanks for answering the question in my DISCUSS.
Robert Wilton Former IESG member
(was Discuss) No Objection
No Objection (2020-11-05) Sent for earlier
Hi,

Caveat, I'm not familiar with the Babel routing protocol, and I might be getting the wrong end of the stick.

In some ways I found the content and concepts of this document easy to understand, but the choice of particular terminology made is hard for me to know for sure that I am correctly interpreting this document.  In particular, I am confused between the definition of "source", "destination prefix" and "source prefix" between this document and draft-ietf-babel-rfc6126bis.

I might be completely confused, but my understanding is that what is called the "destination prefix" in this document, is effectively what is referred to as the "source" in draft-ietf-babel-rfc6126bis (e.g., in the Route Table in section 3.2.5), that also happens to be a prefix.  Is that right?

A further confusion is that this draft seems to sometimes describes prefixes differently from how they are described in the Babel RFC that it is extending.  E.g., it seems that in some cases the prefix-length is implicitly part of the prefix, and in other cases it is described as a separate element (e.g., in the 'source' and 'route' table indexes).

Specifically:

    3.1.  The Source Table

       Every Babel node maintains a source table, as described in [BABEL]
       Section 3.2.5.  A source-specific Babel node extends this table with
       the following field:

       o  The source prefix specifying the source address of packets to
          which this entry applies.

       The source table is now indexed by triples of the form (prefix,
       source prefix, router-id).

According to 3.2.5 of draft-ietf-babel-rfc6126bis, the table is already index by a triple, i.e. prefix, prefix-len, router-id.  Is the intention of this document to remove prefix-len as one of the keys to the index?  I presume not, and that the new table is really indexed by a 5-tuple, i.e., adding source-prefix and source-prefix length to the existing keys.


       Note that the route entry contains a source (see sections 2 and 3.2.5
       of [BABEL]) which itself contains a source prefix.  These are two
       very different concepts that should not be confused.
       
Should this reference be to 3.2.6?  It may be helpful to expand on what the original "source" in a route entry means to avoid any confusion.

If my understanding is right, then I think that this document would greatly benefit from being very clear on the differences in terminology and probably be very specific about what they mean in the context of this document.

Regards,
Rob