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

[Juliusz Chroboczek <[e-mail]>]

> 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

Yes.  I've tried to avoid mathematical jargon in our draft, but I was
in a rush, and the formulation is somewhat clumsy (beginning of 2.2.2).
I think I've done a better job in RFC 6126 paragraph 3.5.1, where
I use a similar construction, we'll try to do something similar in the
next version of draft-boutier-homenet-source-specific-routing.

> This is the IETF, so you're certainly free (within reason) to trash
> him for writing something that you assert cannot be implemented,

This is not my objection.

Either you are describing the visible behaviour of routers, in which
case you should use a description sufficiently abstract to be useful
to reason about forwarding behaviours.  Or you're describing an
existing implementation, in which case you should describe the actual
algorithm.  It appears to me that your draft does neither -- it uses
fairly complex data structures while not claiming to describe an
actual implementation.

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

We certainly don't want homenet routers to be too strongly constrained
(e.g. by a concrete algorithm).  There are three questions to ask:

1. Do different forwarding behaviours interoperate?

The general answer is no -- incompatible forwarding behaviours cause
persistent routing loops (Section 2.2.2).  However, there are
particular cases where everything works out, most importantly mixing
source-specific and ordinary next-hop routing (Section 4.1).  (Please
do not underestimate the importance of this property -- what it says
is that you can mix "legacy" routers with source-specific ones.)

2. Can we characterise a class of interoperable forwarding behaviours?

The hard property -- which we're currently working on reformulating in
a manner that avoids mathematical jargon -- is that a set of routers
will interoperate without persistent routing loops as long as their
forwarding behaviours have a common linearisation.  (This is actually
an equivalence -- you can construct topologies that yield a persistent
routing loop unless there exists a linearisation.  Which is a rather
cool property.)

The softer, engineering answer is given in Section 4.2.  The
formulation there is admittedly clumsy, we're working on it.

3. What class of forwarding behaviours do we want to allow in Homenet?

Clearly, we want to allow both source-specific, destination first
routing, and classical next-hop routing to live in the same routing
domain.  Do we want to allow TOS-specific and flow-id-specific?  Do we
want to allow doubly-specific strategies (e.g. both source- and
TOS-specific)?  (I call these "three-dimensional forwarding
behaviours", you'll understand why when you see the pretty pictures
I'm preparing for Berlin.)

I hope we can define a class of interoperable forwarding behaviours
that is both large enough to cover all of the above, and simple enough
that it can be expressed in comprehensible RFC-ese.

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

This is a somewhat disingenious way of describing Section 2.2.2.

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

I think there's a misunderstanding here.
draft-boutier-homenet-source-specific-routing-00 is a description of
a working implementation of source-specific routing, that has the
"obviously right" behaviour, and that has been implemented over an
off-the-shelf operating system.  This draft was published in order to
request a slot at the Berlin meeting where I want to present this
work, describe a few of the remaining open problems, prompt further
discussion, and hopefully convince people to attempt their own
implementation.

I am very much surprised at spending so much time justifying the
existence of a draft outlining a working implementation of
a technology that is badly needed for the Homenet effort.

-- Juliusz