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

[Toke Høiland-Jørgensen <[e-mail]>]

Alvaro Retana <[e-mail]> writes:

> On November 3, 2020 at 4:45:44 PM, Toke Høiland-Jørgensen wrote:
>
> Toke:
>
> Hi!
>
>
>> Alvaro Retana via Datatracker writes:
>>
> ...
>> > 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!
>>
>> 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.
>
> 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..."

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
> details.

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

>> 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."
>
> 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.

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

>> > (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).
>
> 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?

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