Subject: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Apr 2020 16:58:36 +1200

All our troubles will soon be over, apparently:

https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services
 
Stay well
   Brian Carpenter

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Apr 2020 06:59:54 +0200

> https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services

… and you can find one thoughtful piece of discussion from the IETF chair at the unlikely place of

https://datatracker.ietf.org/liaison/1677/

Grüße, Carsten

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Apr 2020 07:42:04 +0200

On Wed, Apr 08, 2020 at 06:59:54AM +0200,
 Carsten Bormann <[email-masked]> wrote 

> https://datatracker.ietf.org/liaison/1677/

It seems that IETF's answer is about another project, by ITU. ITU and
ETSI have the same discourse
<https://www.itu.int/en/ITU-T/studygroups/2017-2020/13/Documents/Internet_2030%20.pdf>
but, apparently, they operate separately.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Apr 2020 07:55:30 +0200

I think there are also different opinions about
the usefulness of this overall ITU-T/IETF exchange.
And the reports in the media ensuing from it
are painfully politically charged and misleading.

But then again, even if the exchange per se
would have been more useful IMHO, i am not
a fan of leadership-to-leadership only processes
that do not actively involve the respective
communities but post notes on rarely
visited URLs.

This form of communications reminds me of:

...All the planning charts and demolition
 orders have been on display at your local
planning department in Alpha Centauri...

The media reports also sound like Douglas Adams.

Cheers
    Toerless
   
On Wed, Apr 08, 2020 at 06:59:54AM +0200, Carsten Bormann wrote:
> ??? and you can find one thoughtful piece of discussion from the IETF chair at the unlikely place of
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Apr 2020 08:15:52 +0200

On Wed, Apr 08, 2020 at 07:42:04AM +0200, Stephane Bortzmeyer wrote:
> It seems that IETF's answer is about another project, by ITU.

Yes.

>  ITU and ETSI have the same discourse

What information makes you think that ?
I do not think that that is true.

> <https://www.itu.int/en/ITU-T/studygroups/2017-2020/13/Documents/Internet_2030%20.pdf>

That document was input to ITU-T Study Group 13 (SG13) for the start
of Focus Group 2030 (FGNET2030). FGNET203 was not formally involved
in the creation of the Liaison Statements referred to in the
liaison exchange pointed to by Carsten. Instead that was done
by ITU-T Telecommunication Standardization Advisory Group (TSAG)
probably with help from SG13.

There are ITU-T members and contributors who think that
topics related directly to the evolution of IP (often
referred to as "New IP") should be discussed by interested
 parties directly to IETF instead of of being brought
into some IMHO obfuscated leadership statements via some liaison
process. At least thats what i believe, which is why we
have inofficial IETF side meetings about "New IP" and other
related topics. But then again, this is from my team working
only in FGNET2030, but not having been involved in any of the
payload of the TSAG/SG13 liaison statements.

> but, apparently, they operate separately.

Yes. ETSI is a completely separate SDO from ITU,
Not a United Nations organization.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Apr 2020 10:28:12 -0700

Brian,

> On Apr 7, 2020, at 9:58 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Interesting.

Seems to me that an application designer has a big choice here.  They can design their application/service so it works over the Internet (with a mix of L2 technologies that includes 5G), or with this over 5G only with what is apparently being proposed here.

IMHO, this is going to be a simple choice for most.

Bob

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Apr 2020 20:57:02 +0200

Hi Stephane,

> On 2020-04-08, at 07:42, Stephane Bortzmeyer <[email-masked]> wrote:
> 
>> 

Yes.  I do know about the difference between ETSI and ITU-T.
But the technical content (that I could find) was, at first look, indistinguishable to me; Alissa’s text can be used right away as a reply to this press release.

There has been a decade of “clean slate Internet” discussion, and only ICN emerged as an interesting new architecture from that context.  So I’m not very optimistic with any process that tries to relive that process.  But genuine new ideas do get generated now and then, and I would be quite interested to hear about them without the now obligatory press release bombast on how they will create cheaper battery technology for flying cars and cure Covid-19 at the same time.

Grüße, Carsten

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 Apr 2020 11:53:09 -0700

Hello,
>are painfully politically charged and misleading.

A past chairman of ETSI commented that ETSI has members from 80 
countries [1].  The IETF, in comparison, describes itself as having a 
large open international community of individuals interested in the 
Internet.  Depending on one's view of the world, it might or might 
not be viewed as being able to reach out to the world out there.

Irrespective of whether the reports are misleading, the question is 
that those reports will have an impact on future decisions.

>communities but post notes on rarely

Communication between two or more entities is usually formal.  The 
communication is said to represent the views from each side instead 
of what some people describe as "speaking for myself".

The "rarely visited URLs" practice was introduced by an IETF 
Chair.  Over time, such an initiative can turn into a practice in 
which manufacturers or providers gain exposure for their products.  I 
doubt that it is very effective for URLs rarely show up in search 
results or in industry discussions.

Regards,
S. Moonesamy

1.  According to the ETSI web site the number is 65.

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Apr 2020 15:19:19 -0400

On Wed, Apr 8, 2020 at 1:28 PM Bob Hinden <[email-masked]> wrote:

> Seems to me that an application designer has a big choice here.  They can
> design their application/service so it works over the Internet (with a mix
> of L2 technologies that includes 5G), or with this over 5G only with what
> is apparently being proposed here.
>

So ... we will get this, with IP and associated protocols layered over it,
and all the applications over that.

---

From: Tony Li <[email-masked]>
Date: Wed, 8 Apr 2020 12:22:37 -0700

> So ... we will get this, with IP and associated protocols layered over it, and all the applications over that. 

Which is exactly fine.  We cannot stop them from creating overlays and as long as they are an overlay, they do not pervert the base architecture.
If they do come up with something interesting, we’ll be able to integrate it.

Tony

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Apr 2020 15:23:00 -0400

--On Wednesday, April 8, 2020 10:28 -0700 Bob Hinden
<[email-masked]> wrote:

>> https://www.etsi.org/newsroom/press-releases/1749-2020-04-ets
>> i-launches-new-group-on-non-ip-networking-addressing-5g-new-s
>> ervices
> 
> Interesting.
> 
> Seems to me that an application designer has a big choice
> here.  They can design their application/service so it works
> over the Internet (with a mix of L2 technologies that includes
> 5G), or with this over 5G only with what is apparently being
> proposed here.
> 

Right.  And that suggests one constructive thing that could be
said to them (both the ETSI and ITU-T efforts, as Carsten points
out) that is not covered by Alissa's (otherwise quite good, IMO)
note.  The letter, at least as I understood it, focused on the
"above IP" ("above waist of hourglass") solutions with which the
IETF has traditionally worked.  I don't know nearly enough to
have a competent opinion about whether it would help with the
problems they are pointing at, but we have a long history of
IP-over-foo protocols that are specific to particular physical
or link layers.  I assume that, if they wanted to design a
specific IP-over-5G protocol (completely in line with _their_
layering model, which Alissa was too polite to point out), that
the IETF would be delighted to have them do that.  They might
even discover, as some other developers of IP-over-foo protocols
have, that they gain insights into the lower-layer design of 5G
itself that enable them to make improvements.

Otherwise, in addition to your observation about application
designers (with which I agree unless those designers have their
development costs unwritten by ETSI, ITU-T, or their members)
this feels a lot like "every decade or so we need to revisit
either OSI or its layer-less predecessors because we aren't good
at learning (perhaps because of those strange-looking bells
stuck over our heads)".   If so, we should probably encourage
them to charge ahead and let us know how it works out for them
:-(

Mumble.
   john

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Apr 2020 21:41:54 +0200

On Wed, Apr 08, 2020 at 08:57:02PM +0200, Carsten Bormann wrote:
> But the technical content (that I could find) was, at first look, indistinguishable to me; Alissa???s text can be used right away as a reply to this press release.

>From Alissa's statement:
"The IETF maintains copyright and change control for the IP specifications..."

That fact is AFAIK the reason why ETSI choose expicitly call their
effort "Non IP", even if it might come up with proposals that for
reasons of global adoption might better be done within the IETF.
That and the probably more limited scope of networks considered
is probably the key difference to ITU-T goals.

Alissas liaison statement goes on to give IMHO a correct but ineffective
explanation how contributors from other SDOs can come to IETF.

Given how this is a leadership-to-leadership exchange,
i would be surprised if any relevant amount of ITU contributors
would even be made aware of Alissas text explicitly and officially
by ITU. Which is IMHO the same on the reverse side. When would have
IETF leadership ever have tried to explain/help IETF attendants to
do better work in another SDO ? Which meeting did i miss about this ?
Maybe with the small exception of RTCweb and W3C (or maybe even more
 in APP, i am not that much involved there).

IMHO, IETF leadership would be well helping IETF by figuring out a
better outreach method to other SDO than such liaison statements. 
But of course there is the main issues of SDOs first trying to
fight for their own survival and relevance.

> There has been a decade of ???clean slate Internet??? discussion, and only ICN emerged as an interesting new architecture from that context.  So I???m not very optimistic with any process that tries to relive that process.  But genuine new ideas do get generated now and then, and I would be quite interested to hear about them without the now obligatory press release bombast on how they will create cheaper battery technology for flying cars and cure Covid-19 at the same time.

Flying cars give 3 dimensions of social distancing.
Obvious Covid-19 solution.

Our IETF issue to make more progress than we do is IMHO
rooted that we conflate everything into one concept "Internet".
In reality, "Internet" is one instance of an overlay
"Internetwork Layer" running on at least one or more interconnected
"Network Layers", such as formed by IP/MPLS or IPv4/IPv6 or SRv6.
And then we apply one architecture (RFC8200) to the often
contradictory requirements of Internetwork and 
Network layers and wonder why we have problems.

If we would at least acknowledge this architecture
and fundamental difference in requirements, it would be a lot
easier not only for IETF to make progress, but also for
more specialized SDOs to propose enhancements for the
Network Layer in networks they are interested in
(5G) and i think they would have a lot more interest to fit
their work into an IETF lead overall Internetwork Layer 
+ Network Layer(s) architecture. 

I think IETF is just going through puberty, having to evolve
from reactive to proactive:

When technologies are young, you just let engineers
innovate and implement and when everything is done, you
can go and fight for it to get standardized. When an
industries becomes more mature and a lot more capital
investment heavy, you need to revert this and SDOs
need to play a lot more proactive role in defining
next-gen solutions. See 3GPP. IETF is not doing this
at the architecture scale. Only at small incremental
enhancements.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Apr 2020 21:56:22 +0200

Thanks, S. inline

> > are painfully politically charged and misleading.

[...]
> 
> Irrespective of whether the reports are misleading, the question is that
> those reports will have an impact on future decisions.

Definitely, but most people looking at those reports
in the media will not even understand the nature of how
or why they where created: To sell one particular political
view, however tainted, wrong and misleading the result is.

Alas, there is really no good investigative journalism
in our field that would expose how this is e.g.: a fight
for votes in next ITU-T round of decision making.

> communication is said to represent the views from each side instead of what
> some people describe as "speaking for myself".

The key word of my criticism is "only". None of
what done in liaison is per-se bad, its just too
isolated from the communities. But i am of course
repeating just my core ask to have a more open
architecture evolution forum in the IAB/IETF to
be able to more effectiely pull in possible
contributors from other SDOs.

Heck, think of a track where you start to inviting
3GPP, ETSI, ITU-T and other SDO presenters, ask
them to present what they do and their thoughts how
it should impact the future of IETF work. And make
sure the time planning allows double the amount of
time for IETF participants to discuss. And hopefully
help them to understand where/how that integration could
be suggested/done via specific contributions to IETF.

(and be careful in selecting whom to invite so you do
 not end up with administrative slide deck readers).

> The "rarely visited URLs" practice was introduced by an IETF Chair.  Over
> time, such an initiative can turn into a practice in which manufacturers or
> providers gain exposure for their products.  I doubt that it is very
> effective for URLs rarely show up in search results or in industry
> discussions.

Indeed. The problem though is to figure out how to get to
more effective forms of actual architecture/engineering
process and not to better marketing mechanisms. Then again,
given how ossified our industry is, there is unfortunately
something to be said about scaring people to wake up, even
though i do not like it.

Cheers
   Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Apr 2020 22:07:31 +0200

On Wed, Apr 08, 2020 at 12:22:37PM -0700, Tony Li wrote:
> If they do come up with something interesting, we???ll be able to integrate it.

Indeed. See my email about us not even acknowleding
architecturally our own layering (Network / Internetwork).

If a new underlay ("Network Layer") from 3GPP or some other
SDO would define great new better than best effort service
distinctions, IETF would be really bad & slow on mapping these
into end-to-end service distinction controllable by applications.

"Please try to figure out how your new underlay fits into
 the crappy DiffServ Model of the IETF".

Alas, i think as bad as IETF is, any other network layer SDO
work is worse. When 3GPP did broadcast services (3G times ?),
it didn't even bother to map it to IP multicast on top of it,
but expected every application to implement against their new isolated
service interface. Guess how successful that was.

Toerless

-- 
---
[email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 8 Apr 2020 15:08:36 -0500

For what it's worth,

> itself that enable them to make improvements.

THIS.

I've deleted multiple replies in this thread, but I'd really like to see
that mentioned in a liaison response ... pointed somewhere.

I don't see ETSI listed as a formal liaison at
https://www.ietf.org/about/liaisons/, but note that (1) ETSI is one of the
"partners" in 3GPP, (2) 3GPP has many thoughts about 5G, which might or
might not map onto this ETSI project, and (3) Gonzalo Camarillo is still
listed as the IETF's liaison manager to 3GPP, which seems like an excellent
resource we might want to involve.

Perhaps that's (also?) a fruitful place to engage on this topic.

Best,

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Apr 2020 08:48:18 +1200

Hi Toerless,

> communities but post notes on rarely

The formality of our interaction with ITU-T, ETSI (and ISO/IEC)
has never been *our* choice; it was forced on us many years
ago by those organizations.

Nobody from those organizations has ever been denied admission
to any IETF discussion. The converse is not true.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Apr 2020 22:53:38 +0200

John,

I think 3GPP 3/4/5/6G is not a fitting example to apply
the IP-over-foo approach. 

4G/5G "core" networks effectively are overlays on top of of some
typically IP based transport network. Today the overlay nodes are mostly
software in edge-data-centers/pops. So its more naturally an
overlay.

There is some liaison process whereby IETF technologies are pitching
their benefits to 3GPP if used an an underlay (i reall having
heard about this for SRv6 or LISP). Yet, 3GPP seems to prefer not
to really change anything fundamental in their overlay architecture
from what i've been told (only tangentially watching this).
"Only simple, minimal layering integration is good integration".

The more fundamental problem is that the mobile services in most
service providers are where the money is coming from, so now
they want to re-design the hardware underlay in their name, aka: the actual
physical network infrastructure besides DCs and radio towers.
And i think 3GPP has no clue what to do there exactly. But i
am sure that something strange will evolve.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 8 Apr 2020 13:54:30 -0700

I assume that, if they wanted to design a

the IETF would be delighted to have them do that.

GTP Layer. I guess, it's there for 20+ years and serving them fine
(hopefully).

As far as I understand, there aspects on underlay that need to be dealt
with to get  some of the new services.
The underlay (IP and MPLS) are IETF protocols I see more flexibility beyond
what these underlays offer.
Else one can put the edge close to base station (the "new edge compute" to
avoid the traffic on best effort IP layer). Can they?

I second Toerless and we as IETF community ought to have more broader
discussions to nail down actual requirements.

Cheers!
--
Uma C.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Apr 2020 23:24:29 +0200

> ago by those organizations.

The IETF process of keeping this liaison a leadership only
exercise within the IETF surely was not forced upon us by
other SDOs.

> to any IETF discussion.

Being open is not the same as being inviting or proactive.

> The converse is not true.

Yes, it is quite weird to think that government policy based
admission to a telecommunications standard body was ever
considered to be a good idea. I have only come to experience it as a 
weapon in an economic war of aggression. And IETF is not even
marketing itself as being superior over such standard bodies
using those type of examples.

Toerless

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 8 Apr 2020 16:32:51 -0500

I've gotta get back to work stuff (which this isn't, no matter how much fun
as it is), but

On Wed, Apr 8, 2020 at 4:24 PM Toerless Eckert <[email-masked]> wrote:

(deleted down to)

> weapon in an economic war of aggression.

I couldn't possibly comment ...

> And IETF is not even

Does anyone know if anything replaced https://open-stand.org/about-us/ (from
2012)?

Enjoy your days/nights, of course!

Best,

Spencer

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 Apr 2020 15:40:09 -0700

Hi Toerless,
>for votes in next ITU-T round of decision making.

It is a cyclic event.

>contributors from other SDOs.

My guess is that another SDO would have its own culture.

>be suggested/done via specific contributions to IETF.

Have you watched a presentation of IETF work in a non-IETF 
forum?  Sometimes, it is not an accurate reflection of the IETF discussions.

I'd say that the above suggestion is worth a try instead of viewing 
it through pessimistic lenses.

Yes.

>something to be said about scaring people to wake up, even

I don't think that businesses would remain idle if there was an 
effective way to change things over the short term.

Regards,
S. Moonesamy

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 01:08:53 +0200

> My guess is that another SDO would have its own culture.

Sure. But i was talking about reaching out to contributors,
not SDOs as an organization.  There are a limite amount of
individuals working across multipiple SDO including IETF.
But i suspect that there are more contributors that
wouldn't dare to go out of their comfort zone without being 
invited. Of course, there is a large amount of SDO participation
that is just doing work within a narrowly defined scope of
operations by their sponsor, those typically would not be
of interest. 

> Have you watched a presentation of IETF work in a non-IETF forum?
> Sometimes, it is not an accurate reflection of the IETF discussions.

If all you have is a liaison statement you will
always wander on thin ice attempting to extrapolate
the meaning between the lines / discussion.  Goes both ways.

> I'd say that the above suggestion is worth a try instead of viewing it
> through pessimistic lenses.

? Sorry, to much thread cutting... which suggestion ?

> I don't think that businesses would remain idle if there was an effective
> way to change things over the short term.

As said in the othre thread, i don't think in an industry as 
mature as ours and as capital intensive, that there is
a lot you can change short term and from a single player.
Hence the need IMHO for IETF to have to rethink to promote
and support more poactive longer term architiecture discussions.
(and if you don't like the word architecture, use design, strategy,...)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 8 Apr 2020 18:39:41 -0700

Hi Toerless,

Your observations are right, of course
Quick replies in-line [Uma]:

overlay.

[Uma]: Right. But those overlays served well and all IP/MPLS transformation
started there 10 years ago (from LTE days). It's only 2 bearers effectively
till now.  And those were simply not enough for some of the critical
services envisioned in 5G networks beyond eMBB (so called  "slice"). Hence
you will continue to see some of the efforts in this thread as in the
title  of this thread (while I know some of the big operators  which
support that I am not plugged in that effort).

[Uma]: Lot of discussions couple of years ago in various side meetings. But
at the end those were not so fruitful.  Partly because there was a
misguided effort to remove their heavily deployed overlay.  Obviously,
collapsing underlay and overlay won't help. LISP is different and it can
potentially solve the control plane signaling and other issues in 3GPP
domain but it's not that backward compatible (yet). But I am sure, Dino and
other might be working in future releases ..

[Uma]:  Yes; we all heard E2E slicing at some point in last few years?
There is a lot in that E2E including L2 and IP/MPLS. You can get only so
far moving the edge. Radio (with NR) is dis-aggregated  and  it doesn't
help even for small sub-set of use cases, which can be solved by
moving your DCs/Edge closure (cost, complexity and security issues).

But the bottom line is underlay (IETF) needs to evolve independently of
5G/B5G (at best this is one use case), given the earlier futile
discussions/efforts as you mentioned above. This would benefit vast number
of use cases with new media, non-eMBB slices and industrial internet
seeking beyond-best-effort which can co-exist along with BE. While I am not
claiming I know fully, but yes, some of these aspects could belong rightly
in this forum perhaps.

Cheers!
--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 8 Apr 2020 19:10:31 -0700

>  All our troubles will soon be over

While I don't know all their troubles by reading that announcement; would
definitely love to hear what do you think our troubles are ...(if any). *

--
Uma C.

[*] Appreciate your  work and concur a lot on
https://tools.ietf.org/html/draft-carpenter-limited-domains-13 .

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 Apr 2020 23:10:38 -0700

Hi Toerless,
>the meaning between the lines / discussion.  Goes both ways.

There are liaisons who are expected to get the message across.  In 
theory, that should prevent the two sides from misunderstanding the 
(formal) statements.

>? Sorry, to much thread cutting... which suggestion ?

It was the one where you mentioned several SDOs and having them 
presenting what they do [1].

>(and if you don't like the word architecture, use design, strategy,...)

I'll have to review past discussions (unrelated to this thread) to 
provide a good answer.  It may be possible [2] to make some short 
steps, e.g. have a venue for a discussion.  Someone will have to 
convince the IAB members to include that in their list of pet projects. :-)

Regards,
S. Moonesamy
1. 
https://mailarchive.ietf.org/arch/msg/architecture-discuss/D8Mxm3e4BPSf15JDXzfITNlwjbo/
2. I would rate the probability of success as very low.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 Apr 2020 09:41:30 +0100

> On 8 Apr 2020, at 22:24, Toerless Eckert <[email-masked]> wrote:
> 

There is of course history here. It is within my working lifetime that many PTTs were denationalised and ITU changed from being a meeting of civil servants to a meeting in which engineers working for private enterprise were permitted to attend, express a view and vote on outcomes.

It is a great pity that governments do not automatically allow any entity legally operating in their jurisdiction automatic entry to the ITU, particularly countries claiming to be core drivers of the “free world”.

That said the IETF really does need to be more open to new revolutionary ideas.

The old concept of the innovators dilemma applies to SDOs as much as to vendors. An idea that seems an outlandish toy to the established player who completely dismisses the concept as unworkable, a position reinforced by the threat to its core business, may indeed turn out to be a valid replacement for its major technology. Sooner or later someone will have an idea that ultimately leads to the obsolescence of IP. Whilst that seems unthinkable to many, remember how many thought that the internal combustion engine would provide the motive power for transport for ever. That position looks a bit shaky at the moment. If the IETF is always dismissive of a change from IPv6 to another forwarding layer, eventually some other SDO will latch onto its replacement and will take primacy in the development of what people will still call the Internet but which will work another way. Another lesson from the innovator’s dilemma is the exponential speed of the transition making it rare that an organisation supporting the old can reconfigure to the new.

The IETF could try to buck the trend here by more openly fostering investigation of the mechanisms and protocols that will ultimately replace its core offerings, and this is why we need more to be open minded about the operation of all parts of the Internet, something that I do not see in the IETF’s current mode of operation.

- Stewart

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Apr 2020 10:46:42 +0200

On Wed, Apr 08, 2020 at 08:57:02PM +0200,
 Carsten Bormann <[email-masked]> wrote 
 a message of 27 lines which said:

> But the technical content (that I could find) was, at first look,
> indistinguishable to me;

I agree. But Toerless Eckert does not.

Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services
From: Toerless Eckert <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>
Cc: Carsten Bormann <[email-masked]>, [email-masked]
Date: Wed, 8 Apr 2020 08:15:52 +0200

Yes.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Apr 2020 10:58:15 +0200

On Thu, Apr 09, 2020 at 09:41:30AM +0100,
 Stewart Bryant <[email-masked]> wrote 

> That said the IETF really does need to be more open to new

Is it really the role of the IETF? The IETF standardizes things for
the Internet. Nothing lasts forever so, one day, the TCP/IP Internet
will be replaced by something different. It is not a problem if this
is done by another organisation. The IETF is not a goal in itself, it
has a purpose, dealing with the current Internet. I'm fine with the
idea that other organisations (but certainly not ITU or ETSI) work on
more revolutionary ideas.

(This may be also a job for the IRTF.)

> Sooner or later someone will have an idea that ultimately leads to
> the obsolescence of IP. Whilst that seems unthinkable to many,

It is perfectly thinkable, one day, it will happen, but so what? Our
goal is to make people communicate, not to maintain the IETF for ever.

> If the IETF is always dismissive of a change from IPv6 to another
> forwarding layer, eventually some other SDO will latch onto its
> replacement and will take primacy in the development of what people
> will still call the Internet but which will work another way.

I'm OK with that. But I bet this "other SDO" will never be ITU or
ETSI.

> The IETF could try to buck the trend here by more openly fostering
> investigation of the mechanisms and protocols that will ultimately
> replace its core offerings, and this is why we need more to be open
> minded about the operation of all parts of the Internet,

Or IETF may think that it is not its role and happily defer to
researchers outside the IETF.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Apr 2020 12:07:26 +0300

> There has been a decade of “clean slate Internet” discussion, and only ICN emerged as an interesting new architecture from that context.  So I’m not very optimistic with any process that tries to r…

+1

An even ICN has an uncertain road to larger-scale deployment.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Apr 2020 12:14:04 +0300

Hi,

> at the architecture scale. Only at small incremental

if this is what you belief needs to happen, please do take this work to the ITU-T.

Lars

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 Apr 2020 10:50:18 +0100

> On 9 Apr 2020, at 00:08, Toerless Eckert <[email-masked]> wrote:
> 

That depends on what you mean by short term and what the financial imperative is.

Think about the heady days when the Internet rolled out in several waves to the consumer world, and the rate at which modems changed and then switched to DSL then to xDSL, and from MPLS to Ethernet as the primary backhaul in many networks.

The key enabler this time is the move to edge service combined with the move to apps which hold their own network stack and tunnel to the edge service. That significantly reduces the scope of and hence barrier to change needed to introduce a new innovation.

So as with many things it comes down to imperative. Think of the rate of military technical evolution between 1939 and 1945 and how many impossible things were done because of the imperative. Think of the social change that has happened in the last few weeks. If the incentive is high enough long term can be a remarkably short time.

- Stewart

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 9 Apr 2020 12:28:34 +0200

Dear Carsten, all,

Thanks for the pointer and the interesting discussion!
I think one additional point was not yet mentioned regarding the Non-IP
architecture. In LPWANs you have essentially this, and the goal of SCHC
(RFC-to-be-8724) is exactly that - having IP-over-NonIP. There is even a
draft on SCHC-over-NBIOT.

What would be the way to make sure the ETSI people are aware that they can
have the benefits of the Non-IP approach, all without losing compatibility
with the Internet?

Cheers,
Alexander

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 13:30:17 +0200

On Wed, Apr 08, 2020 at 11:10:38PM -0700, S Moonesamy wrote:
> There are liaisons who are expected to get the message across.  In theory,
> that should prevent the two sides from misunderstanding the (formal)
> statements.

Sure, and lets assume everybody does an excellent job in that:
Where on the IETF schedule is the open meeting with those liaisons
to discuss with them ? (same thing other side of course too).

> It was the one where you mentioned several SDOs and having them presenting
> what they do [1].

Ack.

> I'll have to review past discussions (unrelated to this thread) to provide a
> good answer.  It may be possible [2] to make some short steps, e.g. have a
> venue for a discussion.  Someone will have to convince the IAB members to
> include that in their list of pet projects. :-)

Its crazy that in research (IRTF) and protocol development (IEF),
 the groups are started by pet topics of the community, and leadership
provides process management and adult supervision.

And in architecture its the opposite: Work has to be pet topics
of IAB and the community has to provide adult supervision.

WHich model works better ?
Why is architecture not using the model of research and protocol
development ?

Cheers
    Toerless

> Regards,
> S. Moonesamy
> 1. https://mailarchive.ietf.org/arch/msg/architecture-discuss/D8Mxm3e4BPSf15JDXzfITNlwjbo/

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 13:52:27 +0200

Alexander:

John Klensin pointed to the general approach of IP over/for Foo.

I pointed to the problem that if Foo supports more than best effort,
there is likely more work needed so that this can be used in the IP
over Foo. Such improvements for IP may not be able to work all
across the tradtional Internet, but across all the interesting
IP networks running over Foo, such as e.g.: metropolitan/city networks.

If technologies such as those sought by ETSI become such a candidate
Foo, we foremost need to ask if they desire to support IP over Foo
or if they totally want to eliminate IP all the way to the
application.

For example, Google could easily completely eliminate
TCP/IP. They are already doing it for TCP (QUIC), and if they
roll out more google Fiber access, all user traffic could well be QUIC
over Google Foo instead of IP. There is nothing stopping a
market player doing this.

Work in IETF today only happens when it is driven by players with
overwhelming market power, so IETF will only be involved
reactively if any such happens. Exactly like it did happen for
QUIC. I think we can see how this works in several working
groups already for above example.

I have expressed my opinion about whethre i think it is the best
mode of operations for IETF to be reactively moved only by
big industry players, or if a more proactive approach to shape
the future would be better for IETF.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 9 Apr 2020 07:09:31 -0500

Another day, another e-mail from Spencer :-)

> have the benefits of the Non-IP approach, all without losing compatibility

That's actually a helpful question that's not arch-discuss-related. (This
thread has had interesting questions that ARE arch-discuss-related - I'm
just talking about the external relationship with other SDOs.

Per https://tools.ietf.org/html/rfc2850#section-2,

   (f) External Liaison

   The IAB acts as representative of the interests of the IETF and the
   Internet Society in technical liaison relationships with other
   organizations concerned with standards and other technical and
   organizational issues relevant to the world-wide Internet. Liaisons
   are kept as informal as possible and must be of demonstrable value in
   improving the quality of IETF specifications.  Individual members of
   the IETF are appointed as liaisons to other organizations by the IAB
   or IESG as appropriate.

I am told (because I asked) that the IAB is also discussing the ETSI press
announcement.

Conveniently, the IAB already has a program on liaison oversight (details
at https://www.iab.org/activities/programs/iab-liaison-coordination-program/
).

It has two current IAB members, and a bunch of people with deep experience
in liaison management, shepherding, and trying to Do The Right Thing.

I know that the IAB is also aware of this thread (because I asked), so we
might wait for a few minutes while the new IAB (seated last month) gets
organized and gets to work, and see what they do next.

Please continue discussion as seems appropriate to you, of course.

And that's my e-mail for the day :-)

Best,

Spencer, no hats

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 14:19:41 +0200

> if this is what you belief needs to happen, please do take this work to the ITU-T.

Just making sure i understand your statement correctly:

You only want for IAB and IETF to continue do only small
incremental enhancements ?

Btw: I do not need to take any work to ITU-T or 3GPP.
These SDOs will move forward with whatever they want to
do without consulting IETF.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 14:24:09 +0200

To me, the interesting question is really if/whether ICN
has a chance to happen as software in data centers.
Last i looked (2 years ago ?), Cisco seems to have made
that pitch architecturally.

I am always sceptical of classical interoperating
networking solutions (ICN or else) to be successul 
in that DC software-only deployment model. Lot more
abilities for vertical proprietary solutions to be
faster successful.

Any good "state of affairs" summary in ICNRG ?
Sorry... didn't track the RG.

Cheers
    Toerless

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Apr 2020 14:26:50 +0200

On 2020-04-08, at 21:41, Toerless Eckert <[email-masked]> wrote:
> When would have
> do better work in another SDO ?

I’m not sure WG chairs qualify as “leadership” in your view (they do, in my view), but that has been a constant theme for us in IoT-land.

> Which meeting did i miss about this ?

Well, we didn’t quite start by saying “this is the way we, the IETF, will work with other SDOs, now eat it”.  We started by working with other SDOs and tried to find out what they actually need.
Interestingly, one of the homes of that work is the T2TRG, as it turns out that IETF and other-SDO work isn’t already perfectly aligned, so you need a wider view (and a longer outlook) to really be useful.

I’m sure we are not yet nearly doing enough of this, but you can’t say we (as an organization) ignore working with other SDOs.

> in APP, i am not that much involved there).

It may help that some of the IoT work is in ART (which encompasses what previously was APP).

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 14:34:02 +0200

On Thu, Apr 09, 2020 at 02:26:50PM +0200, Carsten Bormann wrote:
> I???m not sure WG chairs qualify as ???leadership??? in your view (they do, in my view), but that has been a constant theme for us in IoT-land.

Ok. great. I did mention i can imagine this to happen better in APP/ART,
if it also happens in IoT land, all the better. I was just
coming from not seeing it for ITU-T.

Cheers
    Toerless

> Well, we didn???t quite start by saying ???this is the way we, the IETF, will work with other SDOs, now eat it???.  We started by working with other SDOs and tried to find out what they actually need.
> Interestingly, one of the homes of that work is the T2TRG, as it turns out that IETF and other-SDO work isn???t already perfectly aligned, so you need a wider view (and a longer outlook) to really be useful.
> 
> I???m sure we are not yet nearly doing enough of this, but you can???t say we (as an organization) ignore working with other SDOs.
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 9 Apr 2020 05:48:37 -0700

Interesting that you mention vertically integrated solutions because in
COIN and in related IoT research we are looking at common data layers to
avoid having to go back to the DC or cloud before applications (in
industry, agriculture etc.) can interoperate or data can be processed and
communicated in order to create more advanced solutions using distributed
cognition and machine learning. I know called these “pet projects” in a
previous email but believe me there is not pet there but a real need.

And I gather you may know about the ICNRG since your team was contributing
:)

And while this thread has gone on for a while and it’s nice to criticize
what are you exactly proposing. What is the architecture you would like to
be discussed?

mjm

Marie-José Montpetit, Ph.D.
[email-masked]

On April 9, 2020 at 8:24:33 AM, Toerless Eckert ([email-masked]) wrote:

Cheers
Toerless

On Thu, Apr 09, 2020 at 12:07:26PM +0300, Lars Eggert wrote:
> > There has been a decade of ???clean slate Internet??? discussion, and
only ICN emerged as an interesting new architecture from that context. So
I???m not very optimistic with any process that tries to relive that
process. But genuine new ideas do get generated now and then, and I would
be quite interested to hear about them without the now obligatory press
release bombast on how they will create cheaper battery technology for
flying cars and cure Covid-19 at the same time.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 15:06:14 +0200

On Thu, Apr 09, 2020 at 05:48:37AM -0700, Marie-Jose Montpetit wrote:
> cognition and machine learning.

Yes. interesting virtual meeting earlier this week.

> I know called these ???pet projects??? in a

Maybe i have not been using the term "pet" correctly, i was
meaning to have it express something people are passionate about.

Maybe i should have rather pointed to the financial incentives:
Folks contributing work to IETF and IRTF do this because its
most often part of their job/funding and its not really primarily
self-elected (beyond the fact how they may be able to self-elect
within bounds their funding). I think situation of topic selection by IAB
members follows quite different rules. For better or worse.

> And I gather you may know about the ICNRG since your team was contributing

Only had limied time to track that. Unfortunately a lot of
defunding of ICN going on i think.

> And while this thread has gone on for a while and
> it???s nice to criticize what are you exactly proposing.
> What is the architecture you would like to be discussed?

Well, this threas was not started by what architecure
i would like to see, that was a different thread, but
thanks for asking:

If you want to provide more explicit criticism for what wee
have put out so far, please comment on:

https://datatracker.ietf.org/doc/draft-bryant-arch-fwd-layer-ps/

Btw: while it will be fun to focus on the pieces you don't
like (common feedback has been "i do not believe in hologram
use-cases"), its obviously also helpful to comment on what
you do agree on.

This is not really proposals for specific architecture or protocol
components, because there are certainly a lot of possible options.

We started to write down the areas of concerns as a gap
analysis because we have primarily seen the discuss about
anything "New IP" come back with "what problem are you trying
to solve". Of course we have ideas and proposals how to solve
them, and will write them down too, but it would be a lot
more interesting if other members of the community would bring
in their ideas as well.

Practically speaking, in our opinions, most of interesting
future internet traffic that needs more than best-effort-network
services will happen in metropolitan networks between
towers/usrs and edge-DC, and i think we can and need to
evolve the internet architecture for that future on many
laers, starting at making the actual forwarding plane
of all routes/switches programmable (which would be where
i think your interest might be), up to the point of how
to introduce monetization models for consumption of such
future network services beyond the current model of
"flat rate for network transport and secret anticompetitive backend
deals for differentiated service delivery"

Cheers
    Toerless

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Apr 2020 16:51:16 +0300

Hi,

> incremental enhancements ?

You seem to think small, incremental enhancements are somehow a bad thing. We're disagreeing on that. We've managed to evolve the Internet and its architecture pretty well through a series of small, incremental enhancements at all layers. I don't see why continuing on this path is such a bad thing.

You seem to want to do some large-scale, monolithically-designed "v2" architecture thing. This is not what the IETF does. Hence, my suggestion is you try and do the work in a forum that likes to work that way, and see if you manage to get anyone to deploy the outcome in the end.

> do without consulting IETF.

Great. I guess we can then stop this discussion on am IETF list.

Lars

---

From: Bob Hinden <[email-masked]>
Date: Thu, 9 Apr 2020 09:26:10 -0700

I wonder if this desire for new non-ip networking architectures, is really a replay of the what I call the packet switching vs. circuit switching debate.   Somewhat more recently Ethernet vs. Token ring.  Basically, can networking architectures provide deterministic service (like circuit switching), or is the Internet best effort OK.

It was very common to hear that voice or video couldn’t possibly work over an Internet style packet switching network.   I haven’t heard that in a while, or at least until recently after the 5G hype started gearing up.

I attended the lunch speaker session on 5G at the Singapore IETF, slides can be found:

https://datatracker.ietf.org/meeting/106/materials/slides-106-edu-sessa-5g-impact-on-networks-edge-cloud-and-slicing-00

Seemed to me it was proposing (see slide 13) an end to end 5G network/service.  Lots of words like "Guarantee transport SLAs for each service”, “Optimize network resources as load conditions change”, etc.   I think arguments proposing a new non-ip networking architecture is back to wanting a more deterministic networking (aka circuit switching).   I suppose it also has something to do with wanting to sell services to very large numbers of devices (vs. the current Internet model a subscription per enterprise or home user).

I didn’t understand why all of this couldn’t be built today with the current set of IP wireless and wired technologies.   I was thinking of coming to the mic and ask the speaker if he had heard about the Internet, but decided it wouldn’t be constructive :-)

Bob

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 9 Apr 2020 12:40:08 -0400

Since we're talking slides, I'll throw in my take:

http://www.cs.columbia.edu/~hgs/papers/2019/2019%20Internet40%20IIT-RTC.pdf

Every single failed network architecture has promised QoS by making bits
more expensive; every successful technology has lowered the total cost of
deployment and operations and making bits cheaper.

On Thu, Apr 9, 2020 at 12:26 PM Bob Hinden <[email-masked]> wrote:

> I wonder if this desire for new non-ip networking architectures, is really
> a replay of the what I call the packet switching vs. circuit switching
> debate.   Somewhat more recently Ethernet vs. Token ring.  Basically, can
> networking architectures provide deterministic service (like circuit
> switching), or is the Internet best effort OK.
>
> It was very common to hear that voice or video couldn’t possibly work over
> an Internet style packet switching network.   I haven’t heard that in a
> while, or at least until recently after the 5G hype started gearing up.
>
> Seemed to me it was proposing (see slide 13) an end to end 5G
> network/service.  Lots of words like "Guarantee transport SLAs for each
> service”, “Optimize network resources as load conditions change”, etc.   I
> think arguments proposing a new non-ip networking architecture is back to
> wanting a more deterministic networking (aka circuit switching).   I
> suppose it also has something to do with wanting to sell services to very
> large numbers of devices (vs. the current Internet model a subscription per
> enterprise or home user).
>
> I didn’t understand why all of this couldn’t be built today with the
> current set of IP wireless and wired technologies.   I was thinking of
> coming to the mic and ask the speaker if he had heard about the Internet,
> but decided it wouldn’t be constructive :-)
>
> Bob
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 19:54:31 +0200

Thanks for the discussion points, Lars,
inline.

On Thu, Apr 09, 2020 at 04:51:16PM +0300, Lars Eggert wrote:
> You seem to think small, incremental enhancements are somehow
a bad thing. We're disagreeing on that.

I am surprised to read that because that is not what i
wrote and not what i think. I fear that maybe other people
too are interpreting too much and wrong things into the
whole excurse with ITU-T.

I said "only":

Incremental improvements are are absolutely essential.
They are just not sufficient anymore IMHO for specific
topics.

> We've managed to evolve the Internet and its architecture
> pretty well through a series of small, incremental
> enhancements at all layers. I don't see why continuing
> on this path is such a bad thing.

Yes, and 30 years ago we made a mayor new step (IPNG -> IPv6)
and learned a lot through it.

After > 25 years of IPv6 we do not even seem to welcome a
broader discussion how well or how-not-well-enough that
step and its evolution since then has been. Or thinking
about the benefits that even thinking about another
IPNG step could have. Without saying that the result
couldn't even be just a set of incremental enhancements
(which mfor example could be expanding beyond RFC8200).

Btw: stackevo does have a nice set of analysis of
subsets of what we learned. Alas, the whole problem
of evolving transport stack functions started with SPUD
was not really followed up on.

> You seem to want to do some large-scale,
> monolithically-designed "v2" architecture thing.

I never said this, and i don't want that. I am not
sure i would read from the ITU-T(TSAG) statements
a monolithical-designed v2, but i understand how
that claim was made. I already said that i and
my team where not involved in that but that our
undersstanding of problems is in our gap draft
and that we have not published specific architecture
propsals beyond what you can glean from that draft.

> This is not what the IETF does.

I am not even sure what a good definition of
monolythic architecture would be, but obviously one
doesn't want to throw out the baby with the bathwater,
and if we're talking about modularity, i think we
rather need more than less. Aka: reusing CBOR
as a common presentation layer like ancoding instead
of monolytic one-off TLV definitions, or equally
(my pet peeve) reused transport protocol components
(such as SPUD) instead of every protocol (like QUIC)
reinventing the whole wheel). Just examples.

> Hence, my suggestion is you try and do the work in
> a forum that likes to work that way, and see if you
> manage to get anyone to deploy the outcome in the end.

Oh, i did work in such a forum. Its called a big vendor
inventing new stuff, getting it deployed and then
going to the IETF and attempting to get it standardized.

When today most routers are becoming white box vendors,
the opportunity to do innovation that way in that
space is just going to shift quite a bit.

> Great. I guess we can then stop this discussion on am IETF list.

Well.. "this" thread was already "derailed" by Carsten
with an ITU-T mentioning, even though it says "ETSI".
(not a complaint...)

I am indeed happy if we do not need to continue to
 discuss ITU-T/TSAG statments, but as long as there is the
presumption that that ITU-T/TSAG statement is
about what i and my colleagues are talking about,
i am very happy that you give me the opportunity
to clear up that misperception and confusion in threads like this.

Thanks again
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 20:14:28 +0200

This really goes to what i also think is one of the core architectural questions.

There is an important amount of DiffServ in many private networks,
including service provider video to the ome, that users might
consider "Internet". There are IntServ uses for criticial traffic
in Service providers and Enterprises (RSVP-TE), also for higher
resilience (reroute with resource guarantees). TSN has  a lot
of critical manufacturing and othher industrial use cases, and
those all want L3 support (DetNet). 

On the oter hand, we have in IETF not even come up with a better
definition of fairness than don't kill all competing traffic,
we have AFAIK no agreement of what level of aggressiveness of TCP
congestion control should be the fairness standard (maybe L4S will
help here a bit), and we are far from even acknowledging that we
should also have solutions for differentiated dynamic bandwidth,
even though we already have good technology proof points that it
can be done. (Stuck in Net Neutrality ...). See below.

We have recently made a bit of progress in IETF to better
support less than best effort, that could actually make
bits less expensive too.

Aka: I agree that from 50,000 feet you are right, but when you
come closer, you see that the picture is less binary,
but that what you say its true for "Best Effort Internet",
but that is not really sufficient, and its not true for many
private networks. And it is going to become more of an
issue, the more we want to apply Internet technologies
for more critical infrastructure functions IMHO. Or
even for more differentiated services experiences.

I for once think its not a good QoS architecture when
presidents have to call up NetFlix's CEO and ask him
to reduce his companies pressure on the networks, because
networks themselves can not distinguish this entertainment
traffic from more critical traffic. Do you think this
is the right QoS architecture for the Internet ? Are
we going to have an IANA registries for the FAX numbers
of those CEO's ? ;-)) (yeah, sorry, couldn't resist).

Cheers
    Toerless

On Thu, Apr 09, 2020 at 12:40:08PM -0400, Henning Schulzrinne wrote:
> > It was very common to hear that voice or video couldn???t possibly work over
> > an Internet style packet switching network.   I haven???t heard that in a
> > service???, ???Optimize network resources as load conditions change???, etc.   I
> > I didn???t understand why all of this couldn???t be built today with the
> > but decided it wouldn???t be constructive :-)
> >
> > Bob
> >
> >

-- 
---
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Thu, 09 Apr 2020 11:38:44 -0700

Hi Toerless,
>to discuss with them ? (same thing other side of course too).

It's not on the schedule.

>Why is architecture not using the model of research and protocol

I don't see commenting on a draft as the community providing adult 
supervision to what the IAB may be working on.  As for pet topics, 
there are one or more topics which I may be familiar with.  Some 
people are more comfortable working on such topics.  Looking at 
things from the outside, it is easy for me to say that a model would 
work better.  The reality could be different.

There isn't a unique model for protocol development (in the IETF).  I 
commented about architecture previously: 
https://mailarchive.ietf.org/arch/msg/architecture-discuss/2oi-BrLgaosxRL-Q6KXuHaO8S7o 
Sorry, that doesn't answer your question.

Regards,
S. Moonesamy

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 9 Apr 2020 19:11:06 +0000

I seem to recall that SDN came out of Clean slate Internet program from NSF. That was in 2007 or so (same year as the CCN paper).
Best,

C. 

-----Original Message-----
From: Architecture-discuss <[email-masked]> On Behalf Of Lars Eggert
Sent: Thursday, April 09, 2020 2:07 AM
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services

+1

Lars

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 9 Apr 2020 12:23:00 -0700

Bob/all,

We have published a draft that outlines in great details the architectural framework (based on IP and existing IETF technologies) in the slides presented at lunch speaker session on 5G at the Singapore IETF - draft-bookham-rtgwg-nfix-arch.
There’s already a number of successful deployments.

Cheers,
Jeff

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 21:26:46 +0200

On Thu, Apr 09, 2020 at 11:38:44AM -0700, S Moonesamy wrote:
> supervision to what the IAB may be working on.  As for pet topics, there are
> one or more topics which I may be familiar with.  Some people are more
> comfortable working on such topics.  Looking at things from the outside, it
> is easy for me to say that a model would work better.  The reality could be
> different.

Sure, its just my impression that the IETF WG and IRTG RG model
works a lot better from where i stand than the IAB model. 
I also didn't mean adult supervision in itself as a negativ
term, i am quite happy that overall it happens in a way it
does from IESG to WGs. I am just saying that i wish that
i do not see any benefits in how the IAB is run differently
from that model. 

> commented about architecture previously: https://mailarchive.ietf.org/arch/msg/architecture-discuss/2oi-BrLgaosxRL-Q6KXuHaO8S7o

;-) Haha, well, that mail discuss is more an example of the problem
we have applying the IPv6 protocol architecture not only the
the Internet layer, but also to network layers (forgive the missng
well formalized names here). Different topic.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2020 08:44:30 +1200

On 10-Apr-20 06:14, Toerless Eckert wrote:
...
> is the right QoS architecture for the Internet ? 

No, but I tend to blame the largely ignorant political polemics
(one cannot say "debate") about a mythical beast called "network
neutrality". 

This:
https://tools.ietf.org/html/rfc3086
and this:
https://doi.org/10.1109/JPROC.2002.802000

The fact is that there are fundamental mathematical limits on
QoS in a network that is dominated by contention for switching
resources and by queueing theory. You can only change that by
getting rid of contention. Is there a plan?

> Are

No, we have Google for that ;-)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2020 09:08:00 +1200

> and learned a lot through it.

Actually, I disagree. IPv6 is a very conservative design that had
exactly no effect on fundamentals. That was intentional. Remember
TUBA (TCP and UDP over Bigger Addresses)? That's what we did,
with the tiny detail of using homebrew IPv6 instead of ISO8473.
What we learned is that even a minor step like bigger addresses is
expensive *because of the even more tiny details* like the socket
API, router CLI commands, and the address configuration mechanism.

The major lower-layer atchitecture change in the last 30 years
was completely unplanned: middleboxes.

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Apr 2020 14:19:06 -0700

> API, router CLI commands, and the address configuration mechanism.

I agree with you Brian. But remember NSAP addresses are variable length so we could have addressed nodes out of different sized addresses. 

The big question would TCAM and DRAM vendors have designed their chips for the smaller case or the 20 byte case. For IPv6 they were required to design for the 128-bit case.

Also, back then, we would have thought crazy that software forwarders would be so popular like they are today.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 23:21:12 +0200

Not sure what exactly you're disageeing with. "mayor" ?

I guess everything is relative. Creating something not backward
compatible counts as "mayor" to me, even if its just 96 more
address bits. 

21++ 32->128 bit migration mechanisms is IMHO a lot of good experience.

All very painfull of course. stackevo summarized a bit of it, but
don't think we've really tried to conclude on how to avoid / minimize
these issues if we every would have a chance to redo. I guess most
high level marketing always says variable length addresses for
next-gen, but there is certainly a lot more architectural/mechanism
to be worked out ...

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 23:28:41 +0200

Anything variable length is still under i think a lot of contention
in forwarding plane, even P4 if i remember correctly some discussions.

Heck, i even had a lot of fight when we wanted to introduce variable
length in control plane addressing a decade ago (FEC in mLDP ;-)

I think this is one of those architectural topics where we need to
push so that hardware inventors invest cycles to make variable
length addresses more likely to become mainstream.

There is quite a good amount of private networks, that have no
interest to deal with 128 bit addresses and are happy with
rfc1918 addresses for example.

Most service provider cores run with 20 bit addresses, not even
requiring aggregation. Others use non-aggregateable 48 Bit
addresses. Or 64 bit addresses.

Aka: IMHO the argument of variable length addresses is still 
quite an open issue..

-- 
---
[email-masked]

---

From: Tony Li <[email-masked]>
Date: Thu, 9 Apr 2020 14:35:21 -0700

> Aka: IMHO the argument of variable length addresses is still 

It shouldn’t be.  Today’s hardware is enormously capable and continues to grow aggressively (thank you Gordon Moore).

It would be backwards to let hardware limitations constrain the architecture.  Instead, the hardware will always grow to what is needed by the architecture.

That said, that’s no excuse to create enormously wasteful architectures.  Resources are not free. Waste not, want not.

Tony

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 23:42:05 +0200

On Thu, Apr 09, 2020 at 02:35:21PM -0700, Tony Li wrote:
> It shouldn???t be.  Today???s hardware is enormously capable and continues to grow aggressively (thank you Gordon Moore).

Nice to hear. I was thinking this for a long time for higher end
platforms, but i am unsure about TCAM architectures with fixed
upfront parsers. No ideas about the latest lower end, e.g.:
enterprise level switches. P4 also seems to have overheads
with variable length parsing (only hearsay, need more cycles
to read into those levels of P4 details).

> It would be backwards to let hardware limitations constrain the architecture.  Instead, the hardware will always grow to what is needed by the architecture.

Did you watch the forwarding plane reality talk we gave a few IETFs ago ?
There was still a lot of concern about the right degree of flexibility to
expect from one of the co-presenters slides.

> That said, that???s no excuse to create enormously wasteful architectures.  Resources are not free. Waste not, want not.

Well... I had discussions with a bit Service Provider wondering about what
they thought about the overhead of e.g.: 6x128bit SRv6 SIDs, and he
was not concerned. One person of course, but i think we have to assume
that there is a wide range of opinions about what would constitute
"wasteful" on the wire. 

Variability in headers is a nice concept to make more use-cases happy
IMHO, but when can we really expect it to be acceptable on any
low-end switch (worst hardware).

-- 
---
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Apr 2020 14:43:41 -0700

And OSPF was too complicated for networks and IGRP will live on into 2020.  ;-)

My point being Toerless, is that the variable length issue would now be 2 decades behind us, very well understood and mainstream today.

Dino

> On Apr 9, 2020, at 2:35 PM, Tony Li <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Apr 2020 23:59:25 +0200

> My point being Toerless, is that the variable length issue would now be 2 decades behind us, very well understood and mainstream today.

I got your point.  But remember last years forwarding plane talk (i think you where there).

Right now we only have the disucss whether somehing works in forwading plane
individually in each protocol new field discuss, and that does not give us
good coverage. It also raises the risk that someone who does not like a
protocol uses the "not possible in forwarding plane" as a scapegoat
not having to say no on a protocol due to otherreasons (company policies etc..).

Cheers
    toerless

-- 
---
[email-masked]

---

From: [email-masked]
Date: Thu, 9 Apr 2020 15:00:40 -0700

> Did you watch the forwarding plane reality talk we gave a few IETFs ago ?

I was the one who asked the embarassing question about SRv6.

> that there is a wide range of opinions about what would constitute

SPs are somewhat sheltered from hardware limitations.  They simply ask for scale numbers.

I don’t think that the bandwidth implications of SRv6 are well understood yet. IMHO, those are actually more of a concern.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Apr 2020 15:06:00 -0700

> not having to say no on a protocol due to otherreasons (company policies etc..).

Let me try to be specific on your point. I could be completely misunderstand you. Here are some basic statements:

(1) IP is a robust network layer that has proved to work for many applications.
(2) ICN/NDN is a new data-plane paradigm that is designed for non-conversational flows.
(3) It is not clear yet, if an ICN forwarding plane is faster than a IP forwarding plane. And it may not matter.
(4) ICN can do source authentication for each packet. That is a nice feature at some cost.
(5) IP cannot do packet source authentication.

So you might follow to say that IP can’t do source authenticaiton and therefore IP doesn’t have enough coverage for new features.

Is that what you are claiming?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Apr 2020 15:07:14 -0700

> I was the one who asked the embarassing question about SRv6.

And I was the won who said “are we going to leave any data for the user”. Where I heard a loud Tony Li laugh from the audience.  ;-)

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2020 00:07:49 +0200

On Thu, Apr 09, 2020 at 03:00:40PM -0700, [email-masked] wrote:
> I don???t think that the bandwidth implications of SRv6 are well understood yet. IMHO, those are actually more of a concern.

Indeed. I remember some rude platform awakening in IP multicast when
throughput was designed for video with > 1K avg packet size and the
customers where finance market data with < 200 byte payload.

Its really hard to predict if environmental telemetry in metropolitan
networks will become an actual problem in this respect, but from what i
understand, the amount of telemetry collected in DCs already is often
surprisingly more traffic volume than one would guess.

Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2020 00:23:41 +0200

> Let me try to be specific on your point. I could be completely misunderstand you. Here are some basic statements:

You make a lot of good observation to discuss below, but my comments
where not meant to be specific to ICN. Think about something
else, like BIER, or any other interesting new forwarding plane
features. Think about a vendor who might have stood up and 
said "BIER is nogo as my HW does not do it", but suspicion
could be that he just does not want to see devaluation of
investment into existing multicast forwarding plane.

If instead we had a broader agreed upon understanding of what
forwarding plane functionality we could expect upfront, this
could not happen. Think about defining some reference thats
maybe P4++ (we know its too limited, we don't know what an
acceptable ++ is). So you demonstrate that you can do your
forwarding plane feature in P4++ and that should settle the
"acceptable for forwarding plane in IETF" argument.

Just as a very rough idea on potential goals for forwarding
plane architecture.

Cheers
    Toerless

P.S.: If you want a discuss about ICN/NDN i am all game. Still trying to
figure out its benefits over PGM with DLR (kidding).

> So you might follow to say that IP can???t do source authenticaiton and therefore IP doesn???t have enough coverage for new features.
> 

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2020 10:32:31 +1200

I think Uma's question deserves some thought:

On 09-Apr-20 14:10, Uma Chunduri wrote:
> While I don't know all their troubles by reading that announcement; would definitely love to hear what do you think our troubles are ...(if any). *

I know I've said it before, but I sum it up as "you can't beat queueing theory". I don't know how we are going to meet stringent real-time requirements in a network architecture that fundamentally assumes contention and queues (and has done since 1969). I don't how ETSI is going to do that either.

   Brian

> 
> --
> Uma C. 
> 
> [*] Appreciate your  work and concur a lot on  https://tools.ietf.org/html/draft-carpenter-limited-domains-13 . 
> 
> 
>  On Tue, Apr 7, 2020 at 9:59 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Apr 2020 15:47:35 -0700

Right, so you want new forwarding features. But let’s pop up to a higher level discussion. I think what is more important than technology at a single layer is that you have to get it deployed with useful features at other layers. A holistic approach. And if you want to run it over the Internet, your new features may or will not work well.

IPv6 shows up how a simple protocol takes a long time to get deployed. And that the applications that run over IPv6 could also be run over IPv4.

I’d argue that when IPv6 was developed and if we created QUIC at the same time, people would argue there are more useful features that merit the change. IMO, I think its still not enough.

Dino

> On Apr 9, 2020, at 3:23 PM, Toerless Eckert <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2020 01:16:46 +0200

On Thu, Apr 09, 2020 at 03:47:35PM -0700, Dino Farinacci wrote:
> Right, so you want new forwarding features. But let???s pop up to a higher level discussion. I think what is more important than technology at a single layer is that you have to get it deployed with useful features at other layers.

Indeed.

IMHO, having lived with classical vendor/operator driven network
innovation for 3 decades, i think the best long-term evolution is 
if we had networks that would allow a limited number of hop-by-hop
programmable virtual networks with something like P4++. Consider for the
research community to have such a virtual self-programmed network
would empower to experiment in a real network. Would make network
infra behave like a DC.

> A holistic approach. And if you want to run it over the Internet, your new features may or will not work well.

I don't think i need to run a lot of new things end-to-end across
the planet. I'd be happy if i can run it across a metro space to
edge-DCs. at least for everything commercially relevant. 
global DC to DC traffic is typically across variety of priate
networks anyhow.

> IPv6 shows up how a simple protocol takes a long time to get deployed. And that the applications that run over IPv6 could also be run over IPv4.

There is a lot more permissionless software upgrades
these days than 20 years ago.  I think we understand dependencies to
enable faster innovation cycles.

> I???d argue that when IPv6 was developed and if we created QUIC at the same time, people would argue there are more useful features that merit the change. IMO, I think its still not enough.

Back when IPv6 was done nobody had calculated how many
billions of dollars could be made if advertisements on
web browsers are displayed a few RTTs earlier.

But yes, agree.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Apr 2020 16:27:09 -0700

> global DC to DC traffic is typically across variety of priate

Even if you had a completely new 4-hop network (non-IP) with multiple paths, you could not guarantee zero packet loss. And what I understand from the requirements, you can’t have delayed packets either. So retransmission cannot be used as a tool.

So the only option you have with a new protocol or with IP is to send the same packet over diverse paths. The more diverse paths you have, the greater probablity the packet will not be dropped. And for Brian’s point, you have to measure queuing delay to you can pick 5 out of the 10 diverse paths that meet your delay requirement. And the delay will change so quickly, packet will already be launched into a congestive path. 

You can only do this with an overlay so the edge of the network can select different paths by simply changing the destination address (either with tunneling or translation). But its a hard problem that may be unsolvable. You would have to set expectations very clearly what this new architecture provides and how and when it fails.

Having said that, you may as well build solutions that are IP based. You don’t really need an IPvN.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2020 01:42:51 +0200

On Thu, Apr 09, 2020 at 04:27:09PM -0700, Dino Farinacci wrote:
> Even if you had a completely new 4-hop network (non-IP) with multiple paths, you could not guarantee zero packet loss. And what I understand from the requirements, you can???t have delayed packets either. So retransmission cannot be used as a tool.

Not sure how this relates to my paragraph above, but yes,
solutions that offer higher resilience and lower packet loss
at lowest latency are crucial for more critical services IMHO
in the future.
> 
> So the only option you have with a new protocol or with IP is to send the same packet over diverse paths. The more diverse paths you have, the greater probablity the packet will not be dropped. And for Brian???s point, you have to measure queuing delay to you can pick 5 out of the 10 diverse paths that meet your delay requirement. And the delay will change so quickly, packet will already be launched into a congestive path. 

I would alredy be happy if we had a better overall system standard
to simply operationale path diversity. distributed MRT IGP
extensions was the only thing i rememer we did, and while
its cool, it doesn't offer lowest latency (shorted path
length compared to centralized diverse path calculation).
Hence also proposal from our side like PPR for easier
forwarding plane agnostic path engineering.

What you are talking about are cool ideas which have been
had in more ad-hoc networks for a while now, but i wonder
how well they would really improve resilience over
the more traditional mechanisms (like simple N-path diversity).

>From one of the older discuss i had, ROLL for example
was not allowed way back to charter more forwarding
plane centric functions (stick to routing), so ideas
such as having those intelligent functions such that
flexible forwarding planes like the following did
not happen in IETF yet:

"try to send  packet to link i with up to j retransmissions, max total wait time k, afterwards try link l,..."

Similarily of course extenible to replicate for reasons
of resilience.

> You can only do this with an overlay so the edge of the network can select different paths by simply changing the destination address (either with tunneling or translation). But its a hard problem…

The simple n-path diverse pathset calculation is easy to
use in any network, thats why its a good starting point
the more dynamic mechanisms you mention are still good
research topics IMHO. At least for quantitive evaluations.

> Having said that, you may as well build solutions that are IP based. You don???t really need an IPvN.

If RFC8200 wouldn't make extensions so convoluted and
expensive for controlled networks, i think i could do
everything needed for network layer as IPv6 extensions,
 except things where i really don't like the initial IPv6 
header. For example integrating the best ideas of MPLS.
And whenever i really do not want 2 * 128 bit addresses.
Such as when we come up with better privacy models
where the source address was waste of space.

Cheers
    toerless

-- 
---
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Apr 2020 16:54:24 -0700

> forwarding plane agnostic path engineering.

Then why don’t you write a solutions draft that says “use X, Y, and Z protocols that allows near-zero packet loss and probablisic delays”.

> research topics IMHO. At least for quantitive evaluations.

That’s right. So write a draft that starts out using IP. It will go a long way and you can test it sooner. ;-)

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2020 01:59:35 +0200

On Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino Farinacci wrote:
> Then why don???t you write a solutions draft that says ???use X, Y, and Z protocols that allows near-zero packet loss and probablisic delays???.

There is always more drafts one could write than time. We
presented PPR drafts as a generic concept, its benefits and
maybe even specific details for disjoint paths is still
one some Todo list.

> That???s right. So write a draft that starts out using IP. It will go a long way and you can test it sooner. ;-)

I am not even sure that something that improves IPv4 value
equal to IPv6 would be welcome by part of the community ;-)

But i think there are a lot more pieces to the puzzle
than path diversity, and those othre pieces would
require additional header info, and thats where we
run into 8200 and other issues.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2020 02:09:37 +0200

On Thu, Apr 09, 2020 at 03:07:14PM -0700, Dino Farinacci wrote:
> And I was the won who said ???are we going to leave any data for the user???. Where I heard a loud Tony Li laugh from the audience.  ;-)

Btw. There are interesting hybrid optical/electrical research
network architectures, where optical packets arriving are
passed through an optical delay loop and the packet header
spoofed into the electrical side to make packet
processing decisions, which can then happen when the packet
header starts to appear at the end of the optical delay loop.

Given how these optical networks will be many orders of
magnitudes faster than the electrical processing
capability, we may end up with networks that just scream
to get larger packets to max out performance. 100 Kb minimum.
And then we can waste all the header space we ever wanted.
SIDs in URL encoding, x86 BIER replication function !!!!

Cheers
    Toerless

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 9 Apr 2020 17:11:06 -0700

Toerless, you (we) have to present a design. You gotta write it down in some form. How else do you get peer review?

Dino

> On Apr 9, 2020, at 4:59 PM, Toerless Eckert <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Apr 2020 17:16:34 -0700

some times people do what we thought could not be done.  it might be
cool if this was one.  given the mess we're in and will be for the
years to come, i say best wishes.

as i said to spencer the other day

with my limited time and resources, i focus on doing the best work i
can, and let others do as they choose.  i am not holden caufield and
do not have time, energy, or talent to play him on the net.  these
will be hard times.

randy

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 9 Apr 2020 17:21:29 -0700

Toerless,

You have been mentioning P4 in almost every email.
P4 (and similar) is an abstraction on top of forwarding plane, if anything - it doesn’t enhance one. The problem with such layers in an heterogeneous environment - almost always they end up being lowest common denominator, or variability inevitably kills them (OF ;-))
At scale - In the chain NB(programmable logic you interact with)->magic(translation from high level to 0..1)->SB - SB(silicon) is fixed, magic is limited by amount of permutations, eventually NB that is exposed to you have to limit amount and variability of features to support more than 1 target.
So if I end up with: convoluted management plane (I have to program my forwarding plane directly, 1:1 relationship)  a handicapped feature set across different HW and at the end can't do anything else at line rate  besides moving IP packets from A to B… I’d stick to BGP ;-)

Cheers,
Jeff

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2020 02:54:29 +0200

> Toerless, you (we) have to present a design. You gotta write it down in some form. How else do you get peer review?

I think i explained in another mail on the thread that
we first did the gap analysis to not immediately run into
the concern "why" on any proposal. Just sequentialization.

Cheers
    toerless

> > ???On Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino Farinacci wrote:

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Apr 2020 03:05:50 +0200

On Thu, Apr 09, 2020 at 05:21:29PM -0700, Jeff Tantsura wrote:
> P4 (and similar) is an abstraction on top of forwarding plane, if anything - it doesn???t enhance one.
>  The problem with such layers in an heterogeneous environment - almost always they end up being lowest common denominator, or variability inevitably kills them (OF ;-))

Sure. BUt remember example from prior mail in this thread,
the question is what to do with such a programming
language. E.g.: using it purely as a proof of feasiblity
of a proposed forwarding plane function. This is just
one example. Your argument that is often lowest common
denominator seems to very well support this option.
We already know it makes researchers happy. thats a second
example. Using it to write highest performance production
probably as you said not ideal for that. But initial
research might well get away with lower speed or lower scale code.

> At scale - In the chain NB(programmable logic you interact with)->magic(translation from high level to 0..1)->SB - SB(silicon) is fixed, magic is limited by amount of permutations, eventually NB th…

Exactly. Thats another core important aspect to consider.

> So if I end up with: convoluted management plane (I have to program my forwarding plane directly, 1:1 relationship)  a handicapped feature set across different HW and at the end can't do anything else at line rate  besides moving IP packets from A to B??? I???d stick to BGP ;-)

I think you are taking apart a combination of options of your own design ;-)

Today, everybody can fairly easily build a virtual programmed
overlay network as long as he just uses routers that are
VM/container in DCs, and somehow doesn't have to care
about controlling QoS on the paths between them, but is
fine with controlling them indirectly. SD-WAN being one example
of such overlay networks. And there is IMHO a lot of
great innovation in it. Is the innovation inside the
network layer ? Who knows, its all proprietary. I'd guess there
is some.

So, how do i make a hardware router/switch based metro network
a possible target for such innovator ? Make it programmable.
And of course that comes with a lot of challenges. But it
wrt. management plane it could be similar to how a
SW-overlay network is deployed on DC: Totally separate to
what the actual SW on the VM/containers does. Aka: The
system to download some P4++ code into a network infra has
nothing to do with what protocols that P4++ code implements.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2020 15:32:52 +1200

> header starts to appear at the end of the optical delay loop.

That's roughly how computers worked in the early 1950s, with words
stored serially in mercury delay lines, where the bits travelled
at the speed of sound, so that micro-second latency vacuum tube logic
circuits could comfortably do their thing before the bits emerged
from the delay line.

Such computers were almost impossible to program and they died as
soon as faster memories were invented. The problem was that you had
to be ready exactly when the bits you wanted came around; this was
called optimum programming and the people who could do it were
the übergeeks of 1950.

As you said, "research architectures". Or limited domains, as
somebody else said.

> SIDs in URL encoding, x86 BIER replication function !!!!

Sure, but it won't help typical UDP streams much. We may not like
the historical traffic patterns, but we can't ignore them.

   Brian

> .

---

From: S Moonesamy <[email-masked]>
Date: Fri, 10 Apr 2020 03:08:27 -0700

Hi Toerless,
>i do not see any benefits in how the IAB is run differently

I did not read your comment as negative.

There was this discussion on an IETF thread in which it was argued 
that an IETF WG was a SDO.  I wonder whether it was made for the sake 
of argument or because that is how the IETF model operates.  The IAB 
is an artefact.  In my opinion, and I could be wrong, the two are not 
comparable.

It is the privilege of IAB members to determine how their committee 
should be run.  Whether I like or do not like does not make any 
difference to the state of affairs.

Regards,
S. Moonesamy

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 10 Apr 2020 06:04:06 -0700

in-line..

On Thu, Apr 9, 2020 at 3:32 PM Brian E Carpenter <
[email-masked]> wrote:

> > While I don't know all their troubles by reading that announcement;
> would definitely love to hear what do you think our troubles are ...(if
> any). *
>
> I know I've said it before, but I sum it up as "you can't beat queueing
> theory".

Right. And yes, statistical multiplexing  would always be there.

I don't know how we are going to meet stringent real-time requirements in a
> network architecture that fundamentally assumes contention and queues (and
> has done since 1969). I don't how ETSI is going to do that either.
>

Me too.

However, there is lot of work happening in various forums including
IEEE/TSN, research communities and  other SDOs. This is one of the aspects
perhaps IRTF or some other relevant forum in IETF can look into; if at all
if, there is a forum to see better than BE stuff and how it can co-exist
with BE with our transport layer fairness principles.

Remember there could be other aspects too.

mIOT stuff. There was  this topic on "potentially" billions of  IoT (non
vehicular or non UAV UEs), which are resource constrained and can't do
(IPv6) header compression. These devices emit smaller amount of data
connecting to the radio and the associated spectrum cost (one of the most
sacred and expensive resource in that domain)...

--
Uma C.

> [email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 10 Apr 2020 06:05:08 -0700

Lot of (brutal) truths in the link below.

But this slides would have painted a different picture if there were
incentives for the E2E Qos way back. There was no business model to deploy
this (besides the neutrality stuff).

However, as so many changes with better hardware than 2-3 decades ago,
programmable schedulers, and the raise of limited domain use cases (+ the
new E2E with disappearing transit) there is a possibility. Perhaps when the
initial hype cycle of 5G/B5G is over with $$ on the table for some
verticals.

Or who knows; it may never happen!

--
Uma C.

On Thu, Apr 9, 2020 at 9:41 AM Henning Schulzrinne <[email-masked]>
wrote:

>> I wonder if this desire for new non-ip networking architectures, is
>> really a replay of the what I call the packet switching vs. circuit
>> switching debate.   Somewhat more recently Ethernet vs. Token ring.
>> Basically, can networking architectures provide deterministic service (like
>> circuit switching), or is the Internet best effort OK.
>>
>> It was very common to hear that voice or video couldn’t possibly work
>> over an Internet style packet switching network.   I haven’t heard that in
>> a while, or at least until recently after the 5G hype started gearing up.
>>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 10 Apr 2020 06:12:10 -0700

> run into 8200 and other issues.
Indeed. At some point you will come down here..

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 10 Apr 2020 06:23:32 -0700

>
>
> It shouldn’t be.  Today’s hardware is enormously capable and continues to
> grow aggressively (thank you Gordon Moore).
>
> It would be backwards to let hardware limitations constrain the
> architecture.  Instead, the hardware will always grow to what is needed by
> the architecture.
>
> That said, that’s no excuse to create enormously wasteful architectures.
> Resources are not free. Waste not, want not.
>

I can't agree more.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 10 Apr 2020 17:22:48 -0700

> was completely unplanned: middleboxes.

The post-2013 general deployment of encryption is a pretty big change
too. It was only partially planned. And if QUIC comes to displace TCP,
that too would be a significant change.

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Apr 2020 14:56:30 -0400

--On Friday, April 10, 2020 17:22 -0700 Christian Huitema
<[email-masked]> wrote:

>> Actually, I disagree. IPv6 is a very conservative design that
>> had exactly no effect on fundamentals. That was intentional.
>> Remember TUBA (TCP and UDP over Bigger Addresses)? That's
>> what we did, with the tiny detail of using homebrew IPv6
>> instead of ISO8473. What we learned is that even a minor step
>> like bigger addresses is expensive *because of the even more
>> tiny details* like the socket API, router CLI commands, and
>> the address configuration mechanism.
>> 
> The post-2013 general deployment of encryption is a pretty big
> change too. It was only partially planned. And if QUIC comes
> to displace TCP, that too would be a significant change.

It may also be worth noting that a, perhaps the, major add-on
change in IPv6 --much touted in its early days-- was supposed to
be ubiquitous lP-level encryption.  That post-2013 encryption
deployment, at least AFAICT, relies on methods much closer to
the applications layer, sometimes ones that are at least
partially specific to particular applications and applications
protocols.  If there is a message in those things, I think it is
either that we are not good at predicting which of our
innovations will be successful and which will not or that, when
the IETF says "go forth and do X", thee are no guarantees that
the world will listen.

And I expect it will be some years more before we actually know
whether our more recent push toward encryption has helped the
Internet and its users by increasing privacy or whether pushback
and reactions from the political and law enforcement sectors
ultimately result in fragmentation, large-scale interconnection
problems, and the either development of a lot of ad hoc
solutions or movement of work to other SDOs because the IETF was
too stuck on the importance of encryption no matter what.   I
don't predict that outcome and definitely don't wish for it, but
I think our architectural work would be improved by more
recognition of the possibility.

best,
     john

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 16 Apr 2020 12:43:09 +0200 (CEST)

> Il 13/04/2020 20:56 John C Klensin <[email-masked]> ha scritto:
> 
> If there is a message in those things, I think it is

Incidentally, the attempted discussion on the relationship between the IETF and non-technical, policy-oriented stakeholders would also be pertinent to this. Sometimes, the world seems not to have listened (or even actively resisted) because what the IETF did was not aligned with non-technical incentives, or was affecting some other stakeholders too negatively.

> recognition of the possibility.

Or, in general, by having a dialogue in advance with the rest of the Internet community on this kind of far-reaching change, so that the resulting non-technical issues are at least understood properly, and possibly taken into account in the design; and an alignment of interests can be created to promote the change.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 16 Apr 2020 19:48:40 +0200

On Mon, Apr 13, 2020 at 02:56:30PM -0400, John C Klensin wrote:
> be ubiquitous lP-level encryption.

Indeed. It is almost puzzling to think that end-to-end
encryption at IP(sec) level was presumed to be a good
architectural choice. Besides the obvious beneeit of being
agnostic to transport protocol choices but then failing on
ever getting a host stack model that would allow applications
to leverage it easily. Of couse, luckily we have it (IPsec)
as there are a lot of other good use cases for it.
Maybe a bit too much of the "one size fits all" syndrom that
new technologies by sheer self interest always come to presume ?

>  That post-2013 encryption

Well, i think IPsec was an example of things working well in IETF.
They may have overexpected on the range of where it best
fits (and can be completed by host stack/APIs, which always is
the worst dependency of any IETF work), but they (IPsec) folks
AFAIK never tried to stop TLS with arguments like "we must only
have one protocol" or the like, one of the negative syndroms we
have IMHO seen for othre protocols in the IETF. But nothing
the IETF can really do. Just comes when its participants develop
a particular protocol religion or know how their jobs may depend
on a specific protocol.

> recognition of the possibility.

If i limit your "encryption to "(TLS) end-to-end encryption", then
i think there are already a lot of people that have opinions about
the results even visible today.

IMHO, TLS has two main neglected consequences: It has become the
key component of a strategy for revenue supremacy from one part of
the industry, and it has moved the bad behavior (perpass and its
revenue tail) into a layer of the solution (application) where it
is out of the control of the IETF. Or at least out of the scope
of interest of the companies shaping the IETF standards in that
space because they are the beneficiaries of this evolution.

So, the next round of privacy discussion as we already see will
mostly be happening outside the IETF. For better or worse.

This is of course non-withstanding the basic necessities to use
TLS and its benefits.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Apr 2020 09:17:05 +1200

>> be ubiquitous lP-level encryption.

Not touted by the IPv6 protagonists, however. Yes, there was an intention
to make IPsec mandatory-to-implement, but there was never a claim from the
IETF that IPv6 with IPsec was intrinsically more secure than IPv4 with IPsec.

The claim that IPv6 was intrinsically secure was indeed touted; if I'm
not mistaken it orginated in an industry white paper, was picked up and
exagerrated by the IPv6 Forum, and got into draft-ietf-iab-case-for-ipv6-00,
(which led to draft-iab-case-for-ipv6-06 and was then scrapped). But it
also featured in various lists of IPv6 Myths over many years.

    Brian

---

From: Geoff Huston <[email-masked]>
Date: Fri, 17 Apr 2020 07:52:20 +1000

> On 17 Apr 2020, at 7:17 am, Brian E Carpenter <[email-masked]> wrote:
> 
> Not touted by the IPv6 protagonists,

Evidently you never sat through a Latif Ladid presentation Brian! I heard
many many many stories about how IPv6 and IPSEC was a revolutionary
combination that was going to change the internet, yada yada yada.

> Yes, there was an intention

Gee, the rooms I was in at the time was full of such wondrous claims. I kinda
wonder which room you were in at the time!

With 20/20 hindsight I’d say the host-centric perspective of IPSEC was comprehensively 
flawed, as the subsequent move in the marketplace for protocols attests.

As for IPv6: extension headers. No more need be said.

Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Apr 2020 11:21:22 +1200

Geoff,

I was talking about IETF IPv6 protagonists, not about people outside the IETF.

Regards
   Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Apr 2020 23:46:15 -0400

--On Friday, April 17, 2020 09:17 +1200 Brian E Carpenter
<[email-masked]> wrote:

>>> change in IPv6 --much touted in its early days-- was
>>> supposed to be ubiquitous lP-level encryption.
> 
> Not touted by the IPv6 protagonists, however.

Really?  You obviously were not at some of the IPv6 Forum events
that I got to.  Now, if you mean (as suggested below) "IETF IPv6
protagonists", then I would probably agree, but the same IPv6
Forum leadership were citing the IETF as authority for a lot of
things few, if any, IETF participants ever said.  

(Obviously agreeing with Geoff here, just writing more slowly.)

And, since we are mentioning names, Latif wasn't the only one.
Arguably "we" -- IETF, IAB, and ISOC -- said some things that
were interpreted as indicating that IPv4 address exhaustion was
going to occur really soon, that it would be the end of life as
we knew it, and that IPv6 was the only solution.  While most of
those/ "our" comments were very nuanced, they left a vacuum that
a variety of people --some very sincere and a few pushing
products that were often not quite ready -- pushed, supposedly
quoting/representing "us".

> Yes, there was
> an intention to make IPsec mandatory-to-implement, but there
> was never a claim from the IETF that IPv6 with IPsec was
> intrinsically more secure than IPv4 with IPsec.

Agreed.  But there were a lot of claims that, since it was or
soon would be mandatory to implement, it was going to be much
more widely supported under IPv6 than it had been, or would
likely ever be, under IPv4.  And the implication of many of
those claims was the IPSec over (or integrated with) IPv6 would
be far more secure, easier to implement and deploy, etc., than
what was available (as an add-on, they said) over IPv4.  See
above.

> The claim that IPv6 was intrinsically secure was indeed
> touted; if I'm not mistaken it orginated in an industry white
> paper, was picked up and exagerrated by the IPv6 Forum, and
> got into draft-ietf-iab-case-for-ipv6-00, (which led to
> draft-iab-case-for-ipv6-06 and was then scrapped). But it also
> featured in various lists of IPv6 Myths over many years.

And I am pushing on this because, at least IMO, we are still
talking about when IPv6 will dominate IPv4 on the Internet
and/or making claims about how rapidly it is deploying.  That
breaks, by far, the record of claims for "two years from now"
about a small collection of protocols unrelated to the IETF,
claims that you may remember every couple of years through the
1980s.

>From an entirely non-technical perspective, we --the IETF and
various bodies that claimed our support and involvement, with
said IPv6 Forum high on the list-- made two very fundamental
political-economic errors.  "We" claimed that it was ready, and
products that would support it were ready, and that it was/would
be easy to deploy at a time when the claims about readiness were
dubious (because the assorted dual-stack and other arrangements
at the endpoints were not quite finished or because ISPs were
not ready to deploy either the packets or the boundary routers
or equivalent).   And some of the organizations that took "our"
advice and tried to deploy got burned and became harder to
convince to try again later.  The other is that, at least IMO,
we failed to adequately consider incentives for deployment once
one moved past fear of running out of address space (which,
predictably, tended to be seen as something to be worked around
or someone else's problem).  

This is, I think, important today, not because of the IPv6
issues but because the Internet has matured enough that it may
be even more important now than it was then to include in our
thinking about major new protocols or protocol changes an
analysis of incentives and disincentives to deployment, and, if
appropriate, who benefits and who loses, not just analyses of
whether they can be implemented and will work.  And it would be
reasonable for us to share that advice with others as well as
following it ourselves.

best,
  john

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 Apr 2020 02:08:28 -0700

Hi Toerless,
>new technologies by sheer self interest always come to presume ?

IPv6 was promoted as "secure by default" as IPsec was part of it.  It 
took many years for the IETF to admit that the technology selected by 
its central planning department did not see widespread use.  It's a 
bit like "SEND".

Have you ever heard of FILTH [1]?  There are people who visit what is 
sometimes referred to as an undeveloped country.  Some of those 
people tout their affiliation with the IETF to convince entities in 
that country to deploy a technology on the premise that it is used in 
advanced countries.

The "one size fits all" rarely works.

Regards,
S. Moonesamy

1. http://r.elandsys.com/r/10933

---

From: Victor Reijs <[email-masked]>
Date: Fri, 17 Apr 2020 10:45:50 +0000

Hello all of you,

> From: Architecture-discuss <[email-masked]> On Behalf Of
> S Moonesamy
> Sent: Friday, 17 April 2020 11:08
> To: Toerless Eckert <[email-masked]>; [email-masked]
> IPv6 was promoted as "secure by default" as IPsec was part of it.  

[Victor Reijs] 
I can remember that when we together had a fully operational TUBA/CLNS service in Europe and US (really 90s). The missing of IPSec was one of the reason not to choose for TUBA/CLNS (beside that it was an ITU standard). TUBA/CLNS was only providing longer (flexible length) addresses. While IPv6 should do indeed secure stuff. Not much has materialise in all these years during which IPv6 needed to be developed/deployed...
But ok that is in the past.

I now read in the ETSI ISG-NIN group that the major issues not to use IP inside B5G is de additional cost of spectrum (which is quite limited) due to the large headers in IPv4/v6 and many encapsulations happening. Furthermore congestion control and QoS are really not supported and that might cause problems for real-time or time critical applications. The ICANN report (5G Technology) says that IP can all do that, but why are the ICANN arguments not (yet) convincing the mobile operators?
I think the specifications are quite clear defined by ETSI NGP's KPI (https://www.etsi.org/deliver/etsi_gs/NGP/001_099/012/01.01.01_60/gs_NGP012v010101p.pdf ) so it must be 'easy' to determine if IP can or cannot do it.

All the best and stay healthy,

Victor Reijs
Research engineer: future internet

Attendance (CEST): Mon 8.15-16.45 | Tue 8.15-16.45 | Fri 9.00-17.30

SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM | The Netherlands
T +31 (0)26 352 55 00 | M +31 (0)6 12 45 00 11
[email-masked] | www.sidn.nl

---

From: John Day <[email-masked]>
Date: Fri, 17 Apr 2020 10:30:54 -0400

One minor correction.  

TUBA/CLNS was an ISO effort. It is true that it does have a ITU number but nearly all OSI standards had both an ISO number and an ITU number. 

The ITU consistently opposed connectionless and CLNP at every opportunity they had starting with the OSI Reference Model to keep connectionless out of OSI. The first amendment to the OSI Reference Model was to add connectionless and the ITU fought that tooth and nail.  It was only through the efforts of *computer companies,* not ITU members, that connectionless and CLNP was there and the work progressed.

The ITU never wanted CLNP and the IETF obliged them.

There was more CLNP deployed and operational in the Internet in 1992 than IPv6 in 2014.

The ITU owes the IETF an immense debt of gratitude for keeping this issue uncertain for the past 28 years.  This has greatly facilitated the ITU's great success in bringing the IETF even closer to the ITU direction.

Congratulations.

John

> On Apr 17, 2020, at 06:45, Victor Reijs <victor.reijs=[email-masked]> wrote:
> 
> Hello all of you,
>

---

From: Victor Reijs <[email-masked]>
Date: Fri, 17 Apr 2020 14:40:53 +0000

Indeed I was running the TUBA/CLNBS project worldwide😉

Victor Reijs

> From: John Day <[email-masked]>
> Sent: Friday, 17 April 2020 16:31
> To: Victor Reijs <[email-masked]>
> Cc: S Moonesamy <[email-masked]>; Toerless Eckert <[email-masked]>;
> [email-masked]
> TUBA/CLNS was an ISO effort. It is true that it does have a ITU number but nearly
> all OSI standards had both an ISO number and an ITU number.
> 
> The ITU consistently opposed connectionless and CLNP at every opportunity they
> had starting with the OSI Reference Model to keep connectionless out of OSI. The
> first amendment to the OSI Reference Model was to add connectionless and the
> ITU fought that tooth and nail.  It was only through the efforts of *computer
> companies,* not ITU members, that connectionless and CLNP was there and the
> work progressed.
> 
> The ITU owes the IETF an immense debt of gratitude for keeping this issue
> uncertain for the past 28 years.  This has greatly facilitated the ITU's great success
> in bringing the IETF even closer to the ITU direction.
> 
> Congratulations.
> 
> John
> 
> 
> 
> >> From: Architecture-discuss <[email-masked]> On
> >> Behalf Of S Moonesamy
> > I can remember that when we together had a fully operational TUBA/CLNS
> service in Europe and US (really 90s). The missing of IPSec was one of the reason
> not to choose for TUBA/CLNS (beside that it was an ITU standard). TUBA/CLNS
> was only providing longer (flexible length) addresses. While IPv6 should do indeed
> secure stuff. Not much has materialise in all these years during which IPv6 needed
> to be developed/deployed...
> > I now read in the ETSI ISG-NIN group that the major issues not to use IP inside
> B5G is de additional cost of spectrum (which is quite limited) due to the large
> headers in IPv4/v6 and many encapsulations happening. Furthermore congestion
> control and QoS are really not supported and that might cause problems for real-
> time or time critical applications. The ICANN report (5G Technology) says that IP
> can all do that, but why are the ICANN arguments not (yet) convincing the mobile
> operators?
> > I think the specifications are quite clear defined by ETSI NGP's KPI
> (https://www.etsi.org/deliver/etsi_gs/NGP/001_099/012/01.01.01_60/gs_NGP01
> 2v010101p.pdf ) so it must be 'easy' to determine if IP can or cannot do it.
> >
> >
> > SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM | The
> > Netherlands T +31 (0)26 352 55 00 | M +31 (0)6 12 45 00 11

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 17 Apr 2020 09:13:17 -0700

> TUBA/CLNS was an ISO effort. It is true that it does have a ITU number but nearly all OSI standards had both an ISO number and an ITU number. 

This is not true. 

We did all the TUBA work in the IETF. And we had multiple implementations running interoperability tests at the Amsterdam IETF in 1993. Ross Callon, Peter Ford and Richard Colella, among others were part of the effort.

I remember telneting from a cisco router using an NSAP address to telnet server implementations from Peter and Richard.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 17 Apr 2020 18:27:38 +0200

On Fri, Apr 17, 2020 at 02:08:28AM -0700, S Moonesamy wrote:
> IPv6 was promoted as "secure by default" as IPsec was part of it.  It took
> many years for the IETF to admit that the technology selected by its central
> planning department did not see widespread use.  It's a bit like "SEND".

Hahaha. Am i assuming correctly that "central planning department" is
intentionally written to sound dismissive, or am i just reading
that into your text ?

We do have an official IETF photographer. Why can't we have an official
IETF cartoonist ? I would love to see a rendering of the "central planning
department of the IETF". Also the whole discussion about IETF photography,
badges and datatracker mugshots  would take a real interesting turn if we 
changed over to cartoons.

Kidding aside: i think we need to be careful in not discouraging
innovation when it is ambitious. The sole reason why the IETF exists is to
create innovation that depends on multiple parties to become active.
And the primary place where IPsec IMHO failed to gain adoption is on
those parts IETF continues not to want to work in: host-stacks, APIs,
(policy) etc..

> Have you ever heard of FILTH [1]?

The reference seems to be more about depressing language barriers than
technical aspects. But sure, the London led collonialization of
the finance industry of this planet is coming to an end (sob ? hurray ? ;-)

> There are people who visit what is
> sometimes referred to as an undeveloped country.  Some of those people tout
> their affiliation with the IETF to convince entities in that country to
> deploy a technology on the premise that it is used in advanced countries.

I have only seen few bits and pieces about those IETF outreach programs,
but it was all from people i respect and activites i felt where useful,
so i have no example data points to be cynical about.

> The "one size fits all" rarely works.

In India, subsistence farmers get updates of different city market prices
realtime via SMS on their cell phones so they know where to sell their produce.
In Germany, Corona case tracking is delayed for days through a multi-stage
series or FAX between different bureaucracies that manually process and
propagate information.

Maybe IPv6 was specifically architected not to be too much better
than IPv4 to ensure that developing countries that can skip IPv4
and start with simple IPv6 greenfields can not leap ahead of 
"developed" nations with all their historic IPv4 baggage too much. 

Cheers
    Toerless

---

From: John Day <[email-masked]>
Date: Fri, 17 Apr 2020 14:03:25 -0400

thanks for the correction. Yes, the TUBA adaption of CLNP was done in the IETF.  However, CLNP was an ISO effort.

> On Apr 17, 2020, at 12:13, Dino Farinacci <[email-masked]> wrote:
>

---

From: Victor Reijs <[email-masked]>
Date: Fri, 17 Apr 2020 19:11:18 +0000

Together with Juha Hinanen for instance and many other NRENs in Europe and together the people in USA (I think a few people of MERIT plaid a large role in developing IS-IS and IDRP) and together with  Cisco we build and tested this large CLNS network on a multi-protocol network (partly KPN in Europe). 
We had printed a great T-shirt with the Tuba symbol on it, I still find it a pity I threw it away! It would have been a real collectors item.

We used the first IS-IS implementations (which is the only thing that is left of this project) and we were just in the middle of developing IDRP (the BGP in the CLNS environment), and then came the decision to go with IPv6😉.

I must have some EPROMs for cisco router with the early code somewhere. Would be nice to plan a reunion.

Victor Reijs

> Sent: Friday, 17 April 2020 20:03
> To: Dino Farinacci <[email-masked]>
> Cc: [email-masked]; Victor Reijs <[email-masked]>; Toerless
> Eckert <[email-masked]>; S Moonesamy <[email-masked]>
> >> TUBA/CLNS was an ISO effort. It is true that it does have a ITU number but
> nearly all OSI standards had both an ISO number and an ITU number.
> >
> > This is not true.
> >
> > We did all the TUBA work in the IETF. And we had multiple implementations
> running interoperability tests at the Amsterdam IETF in 1993. Ross Callon, Peter
> Ford and Richard Colella, among others were part of the effort.
> >

---

From: John Day <[email-masked]>
Date: Fri, 17 Apr 2020 15:48:55 -0400

Dave Katz, Dave Oran, Lyman Chapin, Sue Hares, those guys and some others. They were the ones who were doing CLNP, IS-IS, IDRP, etc. It was a top-notch crew.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Apr 2020 08:36:21 +1200

> I remember telneting from a cisco router using an NSAP address to telnet server implementations from Peter and Richard.

Also, we signed a peace treaty of sorts with the ISO people:
https://tools.ietf.org/html/rfc1888
Of course that led nowhere in practice, as I expected at the time.

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 17 Apr 2020 13:44:19 -0700

Don’t forget Yakov and Tony Li.

Dino

> On Apr 17, 2020, at 12:48 PM, John Day <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 17 Apr 2020 13:45:33 -0700

Victor, thanks for the stroll down memory lane!

Dino

> On Apr 17, 2020, at 12:11 PM, Victor Reijs <[email-masked]> wrote:
>

---

From: Tony Li <[email-masked]>
Date: Fri, 17 Apr 2020 14:09:11 -0700

And Dino.

T

> On Apr 17, 2020, at 1:44 PM, Dino Farinacci <[email-masked]> wrote:
>

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 Apr 2020 15:51:04 -0700

Hi Toerless,
>intentionally written to sound dismissive, or am i just reading

The point was to convey that such an approach in another context was 
not successful.

>changed over to cartoons.

That is a discussion for ietf@. :-)

>those parts IETF continues not to want to work in: host-stacks, APIs,

The innovation happens when the specification is implemented and 
widely deployed.  For what it is worth, there was some effort to 
assess that.  I don't remember what happened to it.

>the finance industry of this planet is coming to an end (sob ? hurray ? ;-)

The acronym is from Jane Gardam's novel: 
https://www.bbc.co.uk/sounds/play/w3csv2bp

>so i have no example data points to be cynical about.

Ok.

>"developed" nations with all their historic IPv4 baggage too much.

I am not trying to be dismissive.  I heard the greenfield argument 
being made around a decade ago.

Around two years' ago, I had an interesting discussion with some 
younger persons in the region about "why don't we use IPv6 to solve 
the problem".  As someone from the Internet Corporation of Assigned 
Names and Numbers discussed the topic with me a day earlier, I asked 
the person to explain the issues to them.  I left it to the younger 
persons to draw their own conclusions.

Regards,
S. Moonesamy

---

From: Victor Reijs <[email-masked]>
Date: Sun, 19 Apr 2020 18:05:38 +0000

And thanks John, Sue was the person of Merit who was in our group to make the CLNS/TUBA network in Europe and USA. By the way it was sponsored by the EC, Juha and I were the projectleaders...

Victor Reijs

> From: Dino Farinacci <[email-masked]>
> Sent: Friday, 17 April 2020 22:46
> Cc: John Day <[email-masked]>; [email-masked]; Toerless
> > Together with Juha Hinanen for instance and many other NRENs in Europe and
> together the people in USA (I think a few people of MERIT plaid a large role in
> developing IS-IS and IDRP) and together with  Cisco we build and tested this large
> CLNS network on a multi-protocol network (partly KPN in Europe).
> > We had printed a great T-shirt with the Tuba symbol on it, I still find it a pity I
> threw it away! It would have been a real collectors item.
> >
> > We used the first IS-IS implementations (which is the only thing that is left of
> this project) and we were just in the middle of developing IDRP (the BGP in the
> CLNS environment), and then came the decision to go with IPv6😉.
> >
> >> Cc: [email-masked]; Victor Reijs
> >> <[email-masked]>; Toerless Eckert <[email-masked]>; S Moonesamy
> >> <[email-masked]>
> >> thanks for the correction. Yes, the TUBA adaption of CLNP was done in the
> IETF.
> >> However, CLNP was an ISO effort.
> >>
> >> running interoperability tests at the Amsterdam IETF in 1993. Ross
> >> Callon, Peter Ford and Richard Colella, among others were part of the effort.
> >>>
> >>> I remember telneting from a cisco router using an NSAP address to
> >>> telnet server
> >> implementations from Peter and Richard.
> >>>
> >>> Dino
> >>>