Subject: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Fri, 19 Jan 2018 21:10:52 -0800

Spencer Dawkins has entered the following ballot position for
charter-ietf-rift-00-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-rift/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I THINK I'm happy to see this work go forward, but I am almost sufficiently
confused by the current charter to say "not ready for external review yet".
Should be easy to fix, though, so not Blocking.

(Could you spell out "Clos" on first use? I had to google that)

It seemed to me that at least some of the discussion in DCROUTING BOF described
some of the reasons why "routing in data centers is different". It would be
helpful to me, if there was a mention of at least one or two differences that
make new protocol work necessary or desirable. I mean, like, one sentence. It's
possible to reverse-engineer that out of the bulleted list a bit further down,
but that's kind of new-participant-hostile.

The description of the protocol that the working group would deliver is tied to
the deliverable based on draft-przygienda-rift, is that right? I had to look at
the table of contents for draft-przygienda-rift to figure that out - and even
then, I'm not sure.

Perhaps

 - A Standards Track **routing protocol** specification based on
 draft-przygienda-rift. The document will include:
   - an Implementation Status section as described in RFC 7942
   - an Operational Considerations section to explain how the protocol is
   configured, deployed, and diagnosed - Security and Privacy Considerations,
   although this material may refer to a separate Threat Analysis document
   (q.v.)

?

---

From: Randy Bush <[email-masked]>
Date: Sun, 21 Jan 2018 14:18:12 -0800

> (Could you spell out "Clos" on first use? I had to google that)

uh, his first name was charles, as i remember.

randy

---

From: Fred Baker <[email-masked]>
Date: Sun, 21 Jan 2018 14:45:43 -0800

> On Jan 21, 2018, at 2:18 PM, Randy Bush <[email-masked]> wrote:
> 

Yes.
https://en.wikipedia.org/wiki/Clos_network

There is no wikipedia entry for the guy himself, but the first reference in the article is to his May 1953 Bell Systems Technical Journal article, listing Charles Clos as the author.

I made the mistake of pronouncing the name "close". It rhymes with "loss".

> randy
> 
> _______________________________________________
> Rift mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rift

---

From: Scott Whyte <[email-masked]>
Date: Sun, 21 Jan 2018 15:37:39 -0800

> I made the mistake of pronouncing the name "close". It rhymes with "loss".

Surely he was French?
https://www.youtube.com/watch?v=XBjnEaYl0Ho

---

From: John E Drake <[email-masked]>
Date: Mon, 22 Jan 2018 14:00:08 +0000

Hi,

Apparently the 's' is silent:  https://en.wikipedia.org/wiki/Nonblocking_minimal_spanning_switch

Yours Irrespectively,

John

> -----Original Message-----
> From: Rift [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Sunday, January 21, 2018 5:46 PM
> To: EXT - randy <[email-masked]>
> Cc: [email-masked]; [email-masked]; Spencer Dawkins
> <[email-masked]>; [email-masked]; The IESG <[email-masked]>
> Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04:
> (with COMMENT)
> 
> 
> 
> There is no wikipedia entry for the guy himself, but the first reference in the
> article is to his May 1953 Bell Systems Technical Journal article, listing
> Charles Clos as the author.
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 22 Jan 2018 14:28:48 +0000

But it is one of those French names that has been anglicized… At least I’ve never heard them called Clo networks. 

Acee 

On 1/22/18, 9:02 AM, "Rift on behalf of John E Drake" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Yours Irrespectively,
    
    John

---

From: Scott Whyte <[email-masked]>
Date: Mon, 22 Jan 2018 07:47:55 -0800

We called them Clo networks within Google netops for at least 10 years

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jan 2018 00:23:33 -0600

My apologies for getting the addressees wrong on my first follow-up - this
is a resend.

But just following up ...

On Jan 19, 2018 23:10, "Spencer Dawkins" <[email-masked]>
wrote:

Thanks for catching me up on Charles Clos. Beyond that ...

It seemed to me that at least some of the discussion in DCROUTING BOF
described
some of the reasons why "routing in data centers is different". It would be
helpful to me, if there was a mention of at least one or two differences
that
make new protocol work necessary or desirable. I mean, like, one sentence.
It's
possible to reverse-engineer that out of the bulleted list a bit further
down,
but that's kind of new-participant-hostile.

Did that make sense? It seemed useful to me, to help new participants
understand why this work is necessary.

I'll plead guilty to reading "data centers are special" and no details, and
hearing the echos of 20 years of "wireless is special" and no details in
various TSV working groups and BOFs, but ...

The description of the protocol that the working group would deliver is
tied to
the deliverable based on draft-przygienda-rift, is that right? I had to
look at
the table of contents for draft-przygienda-rift to figure that out - and
even
then, I'm not sure.

I'd really like to see this laced together more tightly. It didn't seem
reasonable to me, to send someone off to the data tracker, to read the
table of contents in draft-przygienda-rift and figure out that it is the
basis for the proposed working group's major deliverable, when making that
clear in the charter looked like a two-word addition.

Any thoughts about that?

Spencer

Perhaps

   configured, deployed, and diagnosed - Security and Privacy
Considerations,

?

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 23 Jan 2018 23:11:56 -0800

Spencer, thanks for comments.

>From my side as  input: I think the RIFT draft REQ section is written very
tightly and has been  summarized in the charter  (in a somewhat overly
terse form possibly). Providing a full explanation of Clos and what
happened in DC routing is probably outside the scope here on the other hand
... Moreover, I do obviously think that IP Clos fabrics are special (and
given the scale/pervasiveness of those now we reached a point where a
solution that allows their operation at as close to 0 OPEX as possible is
desirable to many organizations). I consider RIFT as strawman (albeit there
is significantly more than straw there ;-) proposal for such a solution
while I look forward to the group welcoming further discussions on the
topic. And yes, we can and do extend some existing protocols to meet few of
the suggested goals (and that work is obviously going on) but to achieve
for IP clos (optionally and ideally extending all the way to the servers)
what traditional routing achieved for generic networks the thinking leads
to new paradigms.

And is wireless special? Having looked @ BABEL and its behavior and having
spent lots time with the creator I do think so (in terms of routing
perspective). As is industrial automation RPL is targeting. We can consider
ourselves as a body offering every car as long it's a Ford T with one of
the extensions but we can also think of IETF in 21st century (in routing
perspective) as opening towards different verticals needing specialized
solutions. An analogy would be the database industry where not every
solution is a SQL server or storage where we are not forced to put
everything on harddisks ... Random musings a bit ...

Do please suggest otherwise the 2-3 words you think would improve the
charter's readability

thanks again

--- tony

On Tue, Jan 23, 2018 at 10:23 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> I'll plead guilty to reading "data centers are special" and no details,
> and hearing the echos of 20 years of "wireless is special" and no details
> in various TSV working groups and BOFs, but ...
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jan 2018 08:27:56 -0600

Hi, Tony,

On Wed, Jan 24, 2018 at 1:11 AM, Tony Przygienda <[email-masked]>
wrote:

> happened in DC routing is probably outside the scope here
>

Right. Agreed. I needed a pointer, and I got one.

> on the other hand ... Moreover, I do obviously think that IP Clos fabrics
> are special
>

Right. What I'm asking, is WHY. And, specifically, what is at least one
problem with using unmodified existing routing protocols in data centers,
that RIFT will fix?

Sorry if that wasn't clear.

> (and given the scale/pervasiveness of those now we reached a point where a
> And is wireless special?

Sure. As above, there are things we did in transport protocols to
accommodate wireless, but we were working on specific problems ("high error
rate" got you UDP-lite, that only did checksum coverage of the UDP header,
for example). We had plenty of proposals based on hand-waving about
"wireless is special" that we didn't move forward, because that wasn't
engineering.

> Having looked @ BABEL and its behavior and having spent lots time with the
> creator I do think so (in terms of routing perspective). As is industrial
> automation RPL is targeting. We can consider ourselves as a body offering
> every car as long it's a Ford T with one of the extensions but we can also
> think of IETF in 21st century (in routing perspective) as opening towards
> different verticals needing specialized solutions. An analogy would be the
> database industry where not every solution is a SQL server or storage where
> we are not forced to put everything on harddisks ... Random musings a bit
> ...
>
>> My apologies for getting the addressees wrong on my first follow-up -
>> this is a resend.
>>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 24 Jan 2018 08:42:56 -0800

> Sorry if that wasn't clear.

Spencer, and here I have to fwd' you to the REQ section of current RIFT
draft (or the published DC requirements draft which lots of people with
vendor/opex experience in this space co-authored & discussed) which
explains the problems (and then there is good amount which has to do with
novel implementation techniques, the way software is delivered in DC and so
on which really is not something that is part of a protocol spec or this
discussion). I spent long days over years twiddling with traditional
protocols thinking how to do all the things required well and @ certain
point in time I cut my losses realizing that the problem presented is
fundamentally different one from generic SPF on a generic graph we solved
by now. To mention one fundamental problem I would say the "how do I keep
blast radius minimal" is a hard one since it inevitably leads to
"sumarization of information" which must be handled somehow once you incur
reconfiguration/failures to prevent blackholes. Solving both problems @
same time with generic algorithms on generic graphs does not seem feasible
to me today (and never was IMO, the discussion was really had during PNNI
complex node times in depth that used barrels of ink without any practical
or even theoretically feasible result and to go deeper, it has to do with
some epistemological principles some very smart people talked to me about).
So  you either summarize & pay blackholes (you may declare you network
reconfiguration or failure-free to which I drily observe that doing
anything but static routing is overcomplicating your solution then or you
may have to treat your IP fabric like a faulty RAM chip and throw the whole
lot away on a link failure) or you don't summarize and your blast radius is
everything on every change which presents (a.k.a host routes flat IGP)
inherent scaling/stability problems (to which one can of course declare
that amount of memory is infinite today, software is bug free and speed of
light is a temporary anomaly only of course).

Now, REQ can be discussed of course (REQ depend of course again on
customers, which markets you're addressing and so on so e'one has one piece
of the elephant especially in still nascent market like DC) and there's a
school of thought that " we can do what we can do and rest is irrelevant"
which is Ford-T and my add-on catalogue analogy I applied. Nothing wrong
with that of course and it will be done but this is often done under
assumptions of OPEX being free for everyone (i.e. humans can solve any
complicated problem that occurs, are abundantly available and they should
be royally paid for twiddling endless amount of non-orthogonal knobs and
damn' if  computers could solve that with good algorithms, not an economic
school of thought that carried lots of success over longer time horizons).
Reality is that network IT is being hard squeezed there for many orgs and
humans are slow & fallible (again, all depends on customer classes and so
on)  ... We are still thinking that "networking is special" and "bandwith
is not a commodity" and unfortunately, I dispute that strongly as far IP
fabrics go and I think our success as IETF will depend on being able on
deliver a technology that gives people "network as a RAM chip", i.e.
bandwith is a component needing zero OPEX to "buy-and-deploy-more-off" ...

So, I digressed a bit here and all this would  probably blow the format of
a charter by at least an order of dimension. Some of the stuff was talked
in the BoF format and then it needs bar discussions and involvement in the
group I'd say ...

--- tony

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 25 Jan 2018 09:44:45 -0500

On January 24, 2018 at 11:43:37 AM, Tony Przygienda ([email-masked])
wrote:

Hi!

I digressed a bit here and all this would  probably blow the format of a
charter by at least an order of dimension. Some of the stuff was talked in
the BoF format and then it needs bar discussions and involvement in the
group I'd say ...

Yes, I believe that the reasons for doing the work are well known to the
participants and whoever paid attention at the dcrouting BOF.  However, to
Spencer’s point, the charter is written not just for the benefit of the
proponents (and others who understand and support the reasoning), but for
the benefit of potential new participants and other interested parties —
including future IESGs which will have the task of evaluating the output
and even rechartering the WG.

I think that we can come up with a general introductory paragraph (just a
few sentences) that provides some specific background for the DC-related
routing work.  I will borrow from the references that Tony pointed to and
bounce something by thing list before the end of the day.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 25 Jan 2018 12:57:36 -0500

On January 25, 2018 at 9:44:45 AM, Alvaro Retana ([email-masked])
wrote:

I put together a couple of sentences as a brief introduction and submitted
it as -05 [1].  Please take a look.

I plan on asking the IESG Secretariat to move the charter on to External
Review before the end of the day today.

Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/charter-ietf-rift/00-05/

Diffs:
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-rift%2Fwithmilestones-00-04.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-rift%2Fwithmilestones-00-05.txt

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 26 Jan 2018 13:08:12 -0600

Hi, Alvaro,

On Jan 25, 2018 11:57, "Alvaro Retana" <[email-masked]> wrote:

My apologies for only noticing this now.

The diff looks good - the opening paragraph was what I was hoping for.

If you're still open for suggestions, I'd also suggested

"A standards track *routing protocol* specification that will include"

to make it a bit more obvious that this specification was the same work
described earlier in the charter, but that wasn't as important.

Do the right thing :-)

Spencer

Thanks!

Alvaro.

Diffs:  https://www.ietf.org/rfcdiff?url1=https%3A%2F%
2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-rift%2Fwithmilestones-00-04.txt&
url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-rift%
2Fwithmilestones-00-05.txt