Subject: [arch-d] IETF standards: think inside the box (re: draft-arkko-iab-internet-consolidation)

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Oct 2018 23:14:19 +0200

> draft-arkko-iab-internet-consolidation:
> It is also surprising that in the age of software-defined everything,
> we can program almost anything else except the globally provided,
> packaged services.  Opening up interfaces would allow the building
> of additional, innovative services, and better match with users'
> needs.

One key problem in this is the blinders IETF traditionally puts on in
designating Internet Standards stamps only to what IETF considers to be
relevant interoperability: IPC (protocols) between componts across some
(even if imaginary) wire. 

To create more innovation, opportunity and agility of technology
evolution in the network itself, we need to encourage a framework we we
get interoperating software components inside network devices. Yet none
of that can be Internet Standards,  as seen in typical examples like all
the layer APIs we're doing that must all be informational (TAPS etc.). 

Aka: "Think inside the box" wrt to IETF's scope of standards track
interoperability. Lets not have us convert everything that needs to
interoperate inside a box into protocols that look like they could be
happening on an outside wire just to be able to become Internet
Standards.

And interoperability is just one part. Overall SW inside the box designs
could become much more of an encouraged topic for the IETF.

Cheers
    Toerless

---

From: Jari Arkko <[email-masked]>
Date: Sat, 27 Oct 2018 09:22:01 +0300

> happening on an outside wire just to be able to become Internet

Yes, agreed.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Oct 2018 08:24:11 +1300

>> happening on an outside wire just to be able to become Internet

Yes, and this resonates with the analysis in draft-carpenter-limited-domains-04,
especially https://tools.ietf.org/html/draft-carpenter-limited-domains-04#section-6
and https://tools.ietf.org/html/draft-carpenter-limited-domains-04#section-7
Our conclusion is that we need to define the box properly and securely.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Oct 2018 07:28:12 -0700

> On Oct 26, 2018, at 11:22 PM, Jari Arkko <[email-masked]> wrote:
> 
> 

I’m not sure I understand.

Behaviors that are “inside a box” don’t interact with anything and should be up to the implementer.

The interface is what needs to be designed - based on externally visible behavior, whether on-host or off-host.

We need to get beyond this incorrect notion of “on the wire” as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Oct 2018 15:54:53 +0100

Joe:

What is external ? Two VM/container inside a PC each one representing a router ?
How about i want to give up the silly notion that i have to pass some
virtual-link represenations of packets but instead pass pointers to
cross-VM shared memory ? I want to be able to sell these VMs as i
sell physical devices and enable customers to interoperate them inside
a physical box. RTT=0, loss=0, why would i need TCP between these
VMs ?

Interoperability is based on the unit of products we want to enable to
be plugged together into a network. I think we need to look more into
what markets we can better enable by looking more into software as those
units. We're starting to do that IMHO more and more north/southbound
with netconf/yang/PCE and the like to enable centralized controller SDN
network evolution, but the closer we get to the software components that
likely only need to interoperate in a single physcial box, the more we shy
away and stifle modular, multi-vendor interoperable on-box software.

Cheers
    Toerless

On Mon, Oct 29, 2018 at 07:28:12AM -0700, Joe Touch wrote:
> I???m not sure I understand.
> 
> Behaviors that are ???inside a box??? don???t interact with anything and should be up to the implementer.
> 
> We need to get beyond this incorrect notion of ???on the wire??? as defining anything other than message syntax; semantics and behavior are never defined merely by looking at messages.
> 
> Joe
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
---
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Oct 2018 08:03:39 -0700

> On Oct 29, 2018, at 7:54 AM, Toerless Eckert <[email-masked]> wrote:
> 
> Joe:
> 

If you are forcing that implementation, you don’t. It you admit that the real power of virtualization is that those boxes can be anywhere, you do.

What you really want is a two level spec in that case - one that defines the inter operation based on info sharing or exchange, and one or more others that explains how to do that sharing or transfer over a variety of mechanisms.

> away and stifle modular, multi-vendor interoperable on-box software.

The more you assume is inside one box the less options the you give the implementer.

That isn’t networking anymore, and I agree that if that is your goal, you don’t want to use network protocols.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Oct 2018 17:07:02 +0100

On Mon, Oct 29, 2018 at 08:03:39AM -0700, Joe Touch wrote:
> If you are forcing that implementation, you don???t. It you admit that the real power of virtualization is that those boxes can be anywhere, you do.

I am not forcing anything, but this type of communication inside boxes
will become more and more important and should considered to be in scope
of interoperability scenarios for the IETF. 

Also consider your VMs L2s are RDMA/RoCE domains. Your subnets all
just have shared memory, no message passing. 

All i am saying is that IETF shouldn't counter requests to standardize
interoperating components with the historic notion of what those
components must be (physcial boxes and wires/radio).

> What you really want is a two level spec in that case - one that defines the inter operation based on info sharing or exchange, and one or more others that explains how to do that sharing or transf…

In this specific transport protocol example thats probably right as long
there is only an end-to-end (not segmented) transport architecture.

> The more you assume is inside one box the less options the you give the implementer.

Indeed. Because i want to enable multi-vendor interoperating SW
components on boxes for more agility and innovation. Because the market
may want to buy software and whiteboxes.

Sometimes its also just common sense from experience even if just a
single vendor may implement the modules: It took IP Multicast in the IETF
something like 10 years before it was permitted to talk about terms
like MRIB/MFIB. And only because implementations that didn't come up
with this internal modularity and software interfaces didn't work 
correctly.

Aka: multiple arguments why this is beneficial/desirable.

Heck, why are abstract APIs from e.g. TAPS not permitted to be standard ?

Cheers
    Toerless

> That isn???t networking anymore, and I agree that if that is your goal,
> you don???t want to use network protocols.

-- 
---
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Oct 2018 09:36:54 -0700

> On Oct 29, 2018, at 9:07 AM, Toerless Eckert <[email-masked]> wrote:
> 

If you an define these in an OS-independent way, sure. 

> Heck, why are abstract APIs from e.g. TAPS not permitted to be standard ?

They are already in that track. I think that’s a mistake - they’re experimental at best st this point. 

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Oct 2018 18:32:46 +0100

On Mon, Oct 29, 2018 at 09:36:54AM -0700, Joe Touch wrote:
> They are already in that track. I think that???s a mistake - they???re experimental at best st this point. 

Great. Status changes of the two key documents seem to have been
recent, wasn't aware of it.

Re. experimental vs. standard on those: These do not have the
traditional (network protocol) risks and missing experience data
points that we use to select experimental. All the functionality
(AFAIK) exists across existing APIs, just fragmented across OS,
IP version, transport proto and so on. So i think we don't know what
we don't yet know and therefore we should be bold and go for standard.

I am sure we will learn what aspects of future API standards specific to APIs
would need to be added to the rules guiding experimental vs. standard
track selection.

Toerless

-- 
---
[email-masked]