Subject: Re: [Teas] Ben Campbell's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Sep 2017 11:17:48 +0100

Thanks Ben,

> - The abstract is unusually long, and seems more like an introduction. The
> second to last paragraph could almost stand by itself as a useful abstract.

Yeah. I've been practicing writing short stories [1],[2].

We seem to be a few lines over the RFC Editor's guidelines so I have trimmed a
little for the next rev.

> - The terms "southbound" and "northbound" could use definition. (I find these
> terms cause lots of confusion, since not everyone draws the diagrams with the
> same idea of what goes on top or bottom.)

Yes. Elwyn commented about this in his GenArt review.

We now have...
       southbound control protocol (i.e.,
       a control protocol for communicating from the central controller to
network elements)
...and...
        northbound export of YANG-encoded data
        [I-D.ietf-teas-yang-te-topo] from the network elements to the
controller)
...to give an anchor to the meaning.

> - 2.1.1: It's probably too late at this point to change it, but I find the use
> of "domains" unfortunate. That may be one of the most overloaded terms in the
> IETF lexicon, if not in that of the networking crowd at large. Since you
> describe them as "partitions", I think "partitions" would have been better.

Oh, yes, maybe 10 or 12 years too late for PCE :-)

RFC4655 has...
   A domain is any collection of network elements within a common sphere
   of address management or path computation responsibility.  Examples
   of domains include IGP areas, Autonomous Systems (ASes), and multiple
   ASes within a Service Provider network.  Domains of path computation
   responsibility may also exist as sub-domains of areas or ASes.
...and all PCE work since then has leveraged that definition. Actually, you also
see that meaning being adopted across TEAS, MPLS, and CCAMP.

But I have added a citation at the point where "domain" is introduced.

> - 2.1.2, 2nd to last paragraph: "This is nominally a simple task if
>    there are just two controllers, but can actually be quite complex if
>    state changes in the network are not to be lost."
> 
> That sentence seems self-contradictory. I don't think it's simple, nominally
or
> otherwise.

I couldn't agree with you more that this is not simple. However, "nominally" it
is simple to say "Let's just have the controllers synchronise state by sending
updates to each other." This would be funny if it wasn't for the fact that
managers (pointy-haired or otherwise) keep saying it! I have seen plenty of
projects (including router hardware designs) crash and burn by assuming this
simplicity.

Thanks,
Adrian

[1] https://www.amazon.com/Tales-Wood-Adrian-Farrel/dp/1786100924
[2] https://www.amazon.com/More-Tales-Wood-Adrian-Farrel/dp/1786972565