Re: [homenet] draft-boutier-homenet-source-specific-routing-00

[Lorenzo Colitti <[e-mail]>]

On Tue, Jul 9, 2013 at 11:40 AM, Juliusz Chroboczek <
[e-mail]> wrote:

> > Does the algorithm you propose implement the conceptual forwarding
> > algorithm in [TROAN], then?
>
> I've refrained from criticising your draft, since I appreciate people
> taking the time to write legible, thought out drafts and thus sharing
> their work with others.  However, I do not think that your "conceptual
> forwarding algorithm" is a suitable basis for further work on
> source-specific routing.  While I am glad to acknowledge that this
> draft appears to be technically correct and was published before
> I even started seriously thinking about source-specific routing,
> I have no intention to base my work on what I believe is a flawed
> formalism.
>

Ok, so we agree that the forwarding algorithm is conceptually the same,
then. That's a start. The next step is putting that into one document. This
document *must not* be a babel-specific or linux-specific document, because
it needs to apply to more than just babel or linux (Which is why [TROAN]
says "conceptual forwarding algorithm" instead of "forwarding algorithm",
but that's not the point here.)

On the one hand, your "conceptual forwarding algorithm" is impossible
> to implement directly on any operating system known to me.  On the
> other hand, it's expressed in operational terms, with uselessly
> complex data structures (two-level routing tables? eek!), which makes
> it more difficult to understand than a purely abstract specification.
>

Since Ole wrote that text, I'll let him comment on it (when he comes back
from vacation). This is the IETF, so you're certainly free (within reason)
to trash him for writing something that you assert cannot be implemented,
but please do note that he does work for a company known to implement
things like this, and that he has, I believe, written implementations
himself, so I would advise you not to write him off without good reason,
because doing so might have the effect of lessening your credibility in the
eyes of the working group.

Look, given the right concepts, your "conceptual forwarding algorithm"
> can be defined in one sentence:
>
>   (d, s) pairs are ordered according to the lexicographic product of
>   the longer-prefix orderings
>
> This is a proper abstract formulation, and one that doesn't uselessly
> introduce data structures where they don't belong.  This is what I've
> attempted to do (without using order-theoretic language) at the
> beginning of Section 2.2.2.
>

Since we have now agreed that the two solutions are in fact the same, then
any formulation that achieves the consensus of the working group is
acceptable, as long as there is only one and not two.

While I'm sure "lexicographic product of the longer-prefix orderings" is an
elegant way of stating this, I doubt that the IETF would publish an RFC
that says so, because its intended audience might not understand that
language (I know I don't, and I would guess much of the working group does
not either, and who knows about implementers).

However, leaving things and unspecified - for example, introducing
"disambiguation routes" without saying how they are calculated, is also
unlikely to gain consensus because it is not implementable.

I'm afraid that in order for people to understand what you are proposing
(which is sort of required for them to agree with it), you will need to
explain to them why "OSes" (by which I assume you mostly mean "Linux",
though you don't say what they are) require these disambiguation routes -
for example, by stating that the primitives available make a decision first
on the source address and only then on the destination address, and thus
you need to create extra routing table entries to make things work. You and
I know this already, but I suspect there is very little chance of anyone
understanding this based on your current text alone.


> you don't even explain in prose or justify the particular behaviour that
> you have chosen for source-specific routing.  The reason for this
> particular behaviour was explained to me by Fred Baker by private mail, and
> a summary of our discussion appears in Section 2.2.2 (with proper credit
> given to Fred).
>

Perhaps, but on the other hand, "this is the right thing to do because Fred
Baker says so in private email" is not appropriate justification either. At
least we get to say "we took it to the working group and consensus on the
floor was that this is what we want to do".

Once again: I'm glad to cite your work, and I'm glad to recognise that
> you were there first.  Please do not ask me, however, to reformulate
> my work to fit a formalism that I happen to find deficient.
>

Oh no, I'm not asking you to reformulate your work. I will, however, make
the suggestion that if you would like the working group to adopt your work,
then you should write it in a way that the working group can understand and
agree with, and that you avoid duplication of effort. If you do not do so,
then it is likely that your work will not find adoption, with possibly
little sympathy for that outcome.