[arch-d] Programmable forwarding plane discussions ? (was: Re: on the nature of architecture discussion)

[Toerless Eckert <[e-mail]>]

To give one example aspect of what i would think of as a part
of the architecture: Discussions about pogrammable forwarding planes.

We had one talk/presentation last year sponsored by IESG talking about
forwarding planes. And i think we did already see some good disagrement
(discussion starter) about how flexible or inflexible we should consider
them to be now or how much they could be more flexible in the future.
I for once think that wee could promote for them to be more flexible
if we would start getting our heads around this and maybe start writing
up insights and expectations.

There are several attendees whose organizations have collected
experiences with options such as P4, FPGA or fd.io. But we have
no forum whatsoever to discuss those programmable forwarding plane
aspects. Heck, i am sure there would be interest for IETF participants
interested in this topic to contribute educational insight, summaries
of experiences, and thoughts about gaps that should and could be
closed.

I for once am of the firm believ that the degree of innovation on any
platform is proportional to the degree of flexible programmability
by third parties. See VNF/NFV in data centers versus ossification in
gigabit switching in the WAN. But once we get to those forwarding
planes, i think freely programmable can not mean x.86 style, but
it does need to mean something beyond P4, and it does IMHO also
mean that we have to do reusable extensible protocols or else we
can not have virtual programmed networks due to lack of code space.
Etc. pp...

So, why don't we even have a mailing list for such discussions ?
Yes, fragementing into many mailing lists has downsides, but most people
here (beside probbly myself) would have likely not thought about
forwarding plane architectures when they joined architecture-discuss,
so having a more specific mailing list and promoting it might help
to even attract the interested community.

Of course, anything IETF organization would be easier if there was
a sponsor in leadership. And even for a mailing list, such a sponsor
is mandatory.

Cheers
    Toerless

On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote:
> Toerless,
> 
> I helped with a series of 'Re-Arch' research workshops from 2008 to 2010.
> The name was about "re-architecting" the Internet (whatever that means), but
> the accepted papers included articulation of insights about the existing
> architecture. I was also involved in various activities before that to
> promote research investigation into the Internet's architecture. So, based
> on that experience, here's my 2 penny's worth.
> 
> You don't want to have "arch-dispatch" sessions too often. Good
> architectural ideas don't come up that often, so if you create too much
> space to talk about them, the vacuum will get filled with waffle. Once a
> year is probably enough. But then, if you detect waffle is starting to fill
> a vacuum, it's best to back off the timer to biennial. Of course, if some
> new activity spins out of this (as it sometimes should from an arch-dispatch
> activity), that takes on a separate existence that is more frequent than the
> annual cycle of dispatch sessions.
> 
> You certainly don't want to do this from mic lines. It's too easy for
> "random-ietf-bigot" to have opinions about architecture that don't add
> anything (other than for those collecting lists of opinions). Contributors
> need to have had to do some work, like writing an accepted paper, to even
> get into the room.
> 
> It needs to be framed in a context of actionable outcomes. I mean, something
> like arch-dispatch would be a suitable context, 'cos it gives out the
> "actionable-only" message. That doesn't preclude "vague thoughts", but only
> as long as they have the potential to lead to some change that will impact
> on real life once they firm-up.
> 
> So, IAB might be a more appropriate context than IRTF, but you want an
> environment that will attract researchers and thinkers. So the "political
> officers" need to be in the background managing the process rather than
> holding the floor.
> 
> The architecture of such a valuable artefact as the Internet can become
> highly political. Huge businesses have been built on the Internet's current
> architecture, with a vested interest for it not to change. One person's
> architectural improvement is destruction of someone else's business (selling
> hacks to work round architectural problems is big business). And one
> progression of changes destroys someone else's idea of how they thought
> changes would progress. So altho the discussion will often seem academic,
> the structure in which ideas are taken forward has to be resilient against
> the wars it might start. That part is much easier said than done.
> 
> Cheers
> 
> 
> Bob
> 
> On 03/04/2020 02:05, Toerless Eckert wrote:
> > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote:
> > > On 4/2/20 11:34 AM, Toerless Eckert wrote:
> > > > Was it only presentations or also associated drafts ? Was the
> > > > material asked to be make available sufficiently long ago to
> > > > allow quality updates be prior review ?
> > > Neither, really.  It largely consisted of heated discussions at
> > > the mike lines.  While there were presentations, for the most
> > > part they were not architectural in nature (with a few notable
> > > exceptions).
> > Ok, remembering some bits now.
> > That was fun, but yes, not what i was thinking of.
> > 
> > > My sense, from several decades of involvement in the IETF in
> > > various capacities, is that 1) it would take years to get
> > > agreement on a diagram of the current internet architecture
> > > and what you'd end up would be aspirational rather than
> > > descriptive;
> > I think we can and are doing descriptive. Most of stackevo
> > mentioned by you below was descriptive. So are IMHO
> > many other documents/RFC i would consider to be architectural.
> > 
> > I can think of aspirational as a good and even necessar thing.
> > 
> > > 2) architectural discussions in the past have
> > > had minimal impact on actual protocol design;
> > That is a very broad statement. We should first have an
> > unserstanding about what we mean with architecture before
> > i should even ask you to give me example evidence of this.
> > 
> > My architecture interests for example are probably a lot lower
> > inside the machine room of the Internet than e.g. the
> > Internet BGP peering architecure. But all of it is valid
> > architecture topics to me.
> > 
> > For example, i would consider CBOR an example of an
> > architcure concept (presentation layer) brought into
> > IETF and protocols.
> > 
> > One example architecture area of interest for me is the problem that we
> > are not well enough taking the architecture of routers in to
> > account for our protocols, or better yet propose to evolve
> > architecture of both routers and protocols to be better fits in the
> > future.
> > 
> > I am betting neither of these topics are what you would
> > have considered to be architecture in your statement... ??
> > 
> > > and 3) complexity
> > > always wins in the end (the history and output of the NSIS
> > > working group might be a particularly illustrative example
> > > of the latter).
> > > 
> > > Right now, there is nothing stopping anybody from publishing
> > > drafts and contributing to (or, indeed, leading) architectural
> > > discussions in IETF working groups.  I'm not sure what
> > > inferences we should make from the fact that for the most part
> > > that's not happening now.
> > If architecture can be associated directly with protocols
> > of an IETF WG, then yes, it could and should happen
> > in that WG, but i think there are more cases where even
> > this does not happen. E.g.: I have seen ADs eliminate architecture
> > from charters because it does not produce implementable protocols.
> > 
> > But the more fundamental issue is that architecture mostly
> > needs to predate protocol development, like research mostly
> > needs to predate architecture and protocols. I can not
> > see a logic that argues we must have an IRTF, but we cannot
> > have an IATF (Internet Architecture Task Force). The
> > whole construct of IAB for architecture is weird to me.
> > 
> > > I'm skeptical about the actual value of what you're proposing
> > > but as I said, there's nothing stopping you (or anybody else)
> > > from starting up something informally, which would give us all
> > > a better sense of the actual interest level and what the likely
> > > output would be.
> > Oh, i think there is a lot of sport in trying to discourage work
> > that is not officially sponsored by the IETF/IAB authorities
> > at least from my imited experience.
> > 
> > We need to be darn careful with every single word we
> > write about a side meeting. Make sure it is called "non official"
> > every time you mention it, having people seemingly "borrow"
> > sign up sheets for examination what could be wrong with them,
> > ending up with concerns of using the same color (!) as "official" IETF
> > meeting sign up sheets. Dismissive comments about even doing
> > a side-meeting, Not being allowed to use IETF tooling
> > like webex, jabber, wiki, etherpad, and so on.  Because using
> > IETF tools would mean "endorsement of the activity" *sigh*.
> > 
> > This is sad in general, but at a time when it is legally crucial
> > to make sure all communications is easily recognizeable as
> > public and published because of the US Govt. export regulations
> > (see EAR 734.7) it is outright dangerous to make it so difficult
> > for inofficial side-meetings to use or emulate the
> > public/published nature of official IETF meetings.
> > 
> > > Also, note that there have been IAB programs like stackevo to
> > > deal with these questions.
> > Last RFC published in 2016. Concluded in 2019.
> > Followup to architecture-discuss according to closing mail.
> > 
> > Cheers
> >      Toerless
> > > Melinda
> > > 
> > > 
> > > -- 
> > > Melinda Shore
> > > [e-mail]
> > > 
> > > Software longa, hardware brevis
> > > 
> > 
> > 
> > 
> > > _______________________________________________
> > > Architecture-discuss mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/architecture-discuss
> > 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
---
[e-mail]