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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 03 Nov 2020 07:11:51 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-babel-source-specific-07: 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-source-specific/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am balloting DISCUSS because I believe that the document is missing important
considerations/details related to the operation of Babel in a network.  I hope
these points should be easy to address.

This draft describes destination-first forwarding.  If I understand correctly,
for the table in §4:

             destination                source     next-hop
       2001:DB8:0:1::/64                  ::/0            A
                    ::/0     2001:DB8:0:2::/64            B

...and the example presented of a "source 2001:DB8:0:2::42 and destination
2001:DB8:0:1::57", the result is that the packet is forwarded to A.  Is this
the correct interpretation?  If so, then I believe there are important
assumptions made that are not mentioned.

In line with this document being "applicable to small networks" (§1), BCP
84/§4.3 recommends the following:

   For smaller edge networks that use provider-based addressing and
   whose ISPs implement ingress filters (which they should do), the
   third option is to route traffic being sourced from a given
   provider's address space to that provider.

Given that the draft provides no details, I assume that being "compatible with
[BCP84]" (§1) means at least that Babel nodes aim to "route traffic being
sourced from a given provider's address space to that provider".

(a) While I understand the table above is just an example, it can be
interpreted as indicating that B is the provider that assigned the
2001:DB8:0:2::/64 prefix.  If traffic sourced from that prefix is sent to A,
then there's a good chance that the packet will be dropped (in line with BCP
84, BCP 38, etc.).

Maybe the table is not intended to illustrate the routing table at a multihomed
edge router. Still, it shows how easy it is to define a policy that may not
result in the expected behavior because of the destination-first operation. 
Please add some guidance on the advertisements and how they may interact in the
routing table.

Note that what I'm asking for may just be a good example of what to do/not to
do.  rfc8678/§5 presents an example of how the forwarding table is constructed
based on a set of routes -- something like that would be great!

(b) How is the source address selected by the host?

rfc8678 uses guidance from rfc8028 and other RFCs as part of a set of
"Mechanisms for Hosts To Choose Good Default Source Addresses in a Multihomed
Site".  rfc8678 significantly differs from this document in that it assumes
source-first forwarding when discussing the selection of the source address. 
Are any of the recommendations in rfc8678 applicable here?

I may be missing something, but it seems to me that the current standards-based
recommendations/mechanisms don't easily apply to this specification.  I don't
think there's anything wrong with doing things a different way -- but I expect
those differences to be explicitly explained.

SS-ROUTING suggests a trial-and-error mechanism: for "destination
addresses...the sending host tries them all...similarly, all possible source
addresses are tried in turn."  Is that the expectation here?

Even though this document is about Babel and not the host, I would like to see
a (short) discussion about how the host is expected to behave (or what it needs
to consider) in light of the destination-first operation.

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

(1) §4 talks about "lower layers", what are those?  Please be specific.

(2) The second bullet in §4 says that "Babel...MUST either silently ignore any
source-specific routes, or disambiguate..."  Given the required (use of MUST)
nature of the disambiguation, I would like to see an algorithm for it, not just
an example.  I do not include this point in the DISCUSS section because I think
there are ways not to require disambiguation; perhaps something along the lines
of:

   ...SHOULD silently ignore any source-specific routes.  A router can also
   choose to use a disambiguation algorithm (see SS-ROUTING for an example),
   but the details are out of this document's scope.

(3) §7.1: "Source Plen  The length of the advertised source prefix."  Indicate
in bits.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 03 Nov 2020 22:45:40 +0100

>              destination                source     next-hop

[...]

> the correct interpretation?

Yes.

> If so, then I believe there are important assumptions made that are
> not mentioned.
>
> edge router.

It's not. Here's a bit of my real routing table (slightly altered to aid
clarity of example), illustrating what a real multi-homing scenario
would look like:

default from 2a00:xxxx::/48 via fe80::feec:daff:fe55:4a3b dev eth1 proto bird metric 32 pref medium
default from 2a0c:yyyy::/48 via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bird metric 32 pref medium
2a0c:yyyy::/64              via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bird metric 32 pref medium
2a0c:yyyy:1::/64            via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bird metric 32 pref medium
2a00:xxxx::/64              via fe80::feec:daff:fe55:4a3b dev eth1 proto bird metric 32 pref medium
2a00:xxxx:1::/64            via fe80::feec:daff:fe55:4a3b dev eth1 proto bird metric 32 pref medium

The first two default routes are from two different upstreams that have
assigned me prefix 2a00:xxxx::/48 and 2a0c:yyyy::/48 respectively. For
the "multi-homed ISP" scenario, the expectation is that an edge router
will announce a default route (or something similarly broad) with a
source prefix of the delegated prefix. This is absolutely compatible
with BCP38; in fact it provides automatic BCP38 filtering at the first
hop, since if a packet is spoofing its source address to something that
is outside the assigned prefix, there will not be any valid route for
that packet to reach the internet at all.

The four other more-specific routes in the snippet above have no source
prefix announced (like in the example in the draft); in this case, they
come from the routers exporting the prefixes used by each of local their
interfaces as separate routes to the local network. This means that a
packet trying to reach a node on the local network would be routed
directly to that router and on to the host, no matter it's source
prefix, instead of going over the internet from ISP to ISP. This is
obviously the correct behaviour in such a multi-homed scenario.

> Still, it shows how easy it is to define a policy that may not result
> in the expected behavior because of the destination-first operation.
> Please add some guidance on the advertisements and how they may
> interact in the routing table.
>

Since your concern seems to be related to a particular example of what
the source-specific extension can be used for, mentioned in the
introduction, I'm not sure I see how it would improve the document to
write a whole bunch of text addressing this particular operational
concern? I mean, the section you're quoting the example from (section 4)
literally says that the choice of dest first / source first is arbitrary
and all that is required is that it is consistent, before then going
ahead and spelling out the choice.

One small change in the introduction that may make this clearer, was to
amend this sentence in the third paragraph of the introduction:

"When using
   this technique in a network connected to multiple providers, every
   host is assigned multiple addresses, one per provider."

to read something like:

"When using
   this technique in a network connected to multiple providers, every
   host is assigned multiple addresses, one per provider, and each edge
   router exports a default route with a source prefix corresponding to
   the prefix delegated from its upstream."

> (b) How is the source address selected by the host?

[...]

> Even though this document is about Babel and not the host, I would
> like to see a (short) discussion about how the host is expected to
> behave (or what it needs to consider) in light of the
> destination-first operation.

Juliusz can correct me if I'm wrong here, but I believe this is left out
because it really doesn't matter. The host can pick source addresses
however it likes, and packets will make their way to the right upstream
(in the multi-homing scenario).

-Toke

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 4 Nov 2020 12:23:08 -0500

On November 3, 2020 at 4:45:44 PM, Toke Høiland-Jørgensen wrote:

Toke:

Hi!

> Alvaro Retana via Datatracker writes:
>
...
> > Note that what I'm asking for may just be a good example of what to do/
> > not to do. rfc8678/§5 presents an example of how the forwarding table is
> > constructed based on a set of routes -- something like that would be
> > great!
>

The choice may have been arbitrary, but §4 explicitly requires
destination-first: "A Babel implementation MUST choose routing table
entries by using the so-called destination-first ordering..."

Note that I am not questioning the choice, I'm just asking for more details.

> the prefix delegated from its upstream."

That is not a bad change.  However, my concern is not just about the
multihomed case, but about the general handling of advertisements into
the routing table.

> (in the multi-homing scenario).

If it doesn't matter, I would like to understand why.

The multihomed case with 2 default routes is straight forward -- but
how would it work in a more complex case (§4.4/rfc8678, for example)
where a specific source address is expected?  Or is this use case not
supported?

Thanks!

Alvaro.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 05 Nov 2020 13:28:52 +0100

> entries by using the so-called destination-first ordering..."

I read those two paragraphs in sequence as, basically, "(p1) the choice
is arbitrary, (p2) so for this protocol we have chosen
destination-first". As a reader and implementer this could have been
done by coin toss for all I care :)

> Note that I am not questioning the choice, I'm just asking for more

I do believe the choice was, in fact, not done by coin toss, but I'll
let Juliusz chime in here as I'm not sure I'm able to explain it myself...

> multihomed case, but about the general handling of advertisements into

Ah, so what you're saying is that you want the draft to spell out *how*
to achieve this (from s4):

"a routing table entry R1 is preferred to a routing table entry R2 when
 either R1's destination prefix is more specific than R2's, or the
 destination prefixes are equal and R1's source prefix is more specific
 than R2's."

IDK, that seems a bit like an implementation detail that should be left
up to the implementer (RFC8678 is *long*, and the kind of document that
really makes my eyes glaze over, so I guess this is a taste thing?).
I'll let the draft authors answer what they think is appropriate here...

> where a specific source address is expected?  Or is this use case not

I see nothing about the topology in RFC8678/§4.4 that could not be
implemented with Babel source-specific routing. SERb2 could just
advertise '2001:db8:0:6666::/64 from 2001:db8:0:b000::/52', and the
forwarding plane would do the right thing, in that only packets with the
matching source and destination prefix would make it to the H61 host. A
host on the local network would have to pick the right source prefix
according to the policy, but whether it does that by trial and error or
by some out of band discovery mechanism really doesn't matter as far as
Babel is concerned, and I would consider this out of scope for this
draft...

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 05 Nov 2020 14:38:50 +0100

> let Juliusz chime in here as I'm not sure I'm able to explain it myself...

Please see the penultimate paragraph of Section IV.C of [SS-ROUTING].  The
final authors' draft (essentially identical to the published version) is
available online at http://arxiv.org/pdf/1403.0445

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 05 Nov 2020 15:20:53 +0100

> available online at http://arxiv.org/pdf/1403.0445

Ah, right, obviously source-specific default routes won't work unless
destination-first ordering is used... Thanks for the pointer, should
have just realised that myself.

-Toke