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

[Lorenzo Colitti <[e-mail]>]

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

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

The intent was to document something that did not unnecessarily constrain
implementations but was detailed enough to be clear unambiguous. I agree
it's not universe-harmonizingly elegant, but on the other hand, the
documents have to be understood by implementers who aren't always experts
in graph theory.

I do think there's a decent balance there, but of course it could always be
improved. We welcome suggestions.


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

Personally, I think you're being a bit too optimistic on what is possible
in the real world. I do think it's good to document the circumstances under
which things are likely to work, but I fear that we won't actually be able
to take advantage of them because we won't be able to know if we're in one
of the working cases. So if we end up in a broken topology, most of the
time routing is dead in the water anyway.


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


If we can achieve this in a sufficiently large set of topologies.
Otherwise, it's possible that it's better to explicitly not support this
mode rather than attempt to support it only if the topology works.


> Do we want to allow TOS-specific and flow-id-specific?


Personally, I don't think so. I think source+destination routing is about
as much as we can reasonably pull off in the real world. Others may
disagree (and I know many people believe that even just src+dst is
impossible to deploy in the real world).


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

I'm just repeating what you wrote.


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

Then perhaps the problem is that instead of an implementation report, it
reads a bit like a scientific paper, with its own introduction and
characterization of the problem (which overlap with the existing work in
this working group), and partly like a specification (but an underspecified
one - for example, it doesn't say what the disambiguation looks like). And
the implementation report itself is unofrtunately lacking crucial details
like what the limitations of current OSes are and what "disambiguation
routes" need to look like, how often they appear in practice, etc.)

I have no problem with the implementation report - in fact, I look forward
to more details when you write them up. But I do think that the part of
your draft that is the implementation report should its own document,
separate from anything else, and I do think that the characterization part
should be in a separate document, either [TROAN], to which the authors do
welcome constructive criticism, or, if the working group thinks otherwise,
something else.

But putting everything in one document is not a good idea. It's true that
this is not how most documents, including as scientific papers, are
written, but on the other hand, IETF RFCs are a more collaborative
environment than your average scientific journal.