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

[Toerless Eckert <[e-mail]>]

Yes, i know, but thanks for reminding!

Cheers
    oerless

On Mon, Apr 06, 2020 at 10:10:13AM -0700, Marie-Jose Montpetit wrote:
> There is a IRTF RG on programmable forwarding planes: COINRG.
> 
> And we have an active mailing list and an interim tomorrow if you want to
> participate.
> 
> mjm
> 
> Marie-José Montpetit, Ph.D.
> [e-mail]
> 
> 
> 
> On April 6, 2020 at 12:06:07 PM, Toerless Eckert ([e-mail]) wrote:
> 
> 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]
> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
---
[e-mail]