Subject: Contractual Networking at IETF 112

From: Charlie Perkins <[email-masked]>
Date: Fri, 5 Nov 2021 12:55:10 -0700

Hello folks,

We have organized a side meeting on Contractual Networking for IETF 
112.  It is happening on Tuesday at 10am Pacific Time.

==== Contractual Networking ====

This session offers discussion about how to enforce agreements at the 
network layer between different parties in a communication. We could use 
in-band or out-of-band solutions, solutions at layer 3, 3.5, or layer 4. 
We would like to discuss the potential mechanism to provide/negotiate a 
contract. Should these be introduced as data within Internet packets to 
provide the contractual context to the flow, or should this be kept in 
the control plane? How should we ensure compliance? Is IP with some 
label option enough? Should IP be evolved?  Alternatively, should 
compliance mechanisms reside in the control plane, or in virtual 
network/network slices?

Contractual networking encompasses mechanisms to provide / negotiate a 
contract and to ensure that the terms of the contract are being met. 
Multi-party contracts are feasible but significantly more difficult.  
There may be multiple ways to enforce the terms of the contract, 
suggesting that enforcement may be considered separately from contact 
negotiation.  The necessary data could include accounting information, 
service level agreements, crypto material, QoS signifiers, etc., all 
according to the agreed upon terms of the contractual arrangement 
between the parties.  The terms of the contract are considered to be 
stable during the life of the contract.

Speakers will discuss various aspects of contractual networking, 
including network validation, service level objectives, intent-based 
networking, and access authorization for network resources. Exploring 
the suitability of various models of implementation is encouraged - for 
instance, segment routing or network service headers may be suitable to 
assure adherence to the terms of the contract.  Techniques for contract 
negotiation and data structures for efficient forwarding are of interest.

This session is not aimed at forming a working group.  If interest is 
expressed during the meeting, we will discuss next steps and try to 
identify whether the work fits within current working groups.

====================

Regards,
Charlie P.

---

From: Jared Mauch <[email-masked]>
Date: Sat, 6 Nov 2021 07:21:02 -0400

What peering negotiation staff will be at this meeting?

Sent via RFC1925 complaint device

> On Nov 5, 2021, at 3:57 PM, Charlie Perkins <charliep=[email-masked]> wrote:
> 
> Hello folks,
> 
> We have organized a side meeting on Contractual Networking for IETF 112.  It is happening on Tuesday at 10am Pacific Time.
> 
> This session offers discussion about how to enforce agreements at the network layer between different parties in a communication. We could use in-band or out-of-band solutions, solutions at layer 3, 3.5, or layer 4. We would like to discuss the potential mechanism to provide/negotiate a contract. Should these be introduced as data within Internet packets to provide the contractual context to the flow, or should this be kept in the control plane? How should we ensure compliance? Is IP with some label option enough? Should IP be evolved?  Alternatively, should compliance mechanisms reside in the control plane, or in virtual network/network slices?
> 
> Contractual networking encompasses mechanisms to provide / negotiate a contract and to ensure that the terms of the contract are being met. Multi-party contracts are feasible but significantly more difficult.  There may be multiple ways to enforce the terms of the contract, suggesting that enforcement may be considered separately from contact negotiation.  The necessary data could include accounting information, service level agreements, crypto material, QoS signifiers, etc., all according to the agreed upon terms of the contractual arrangement between the parties.  The terms of the contract are considered to be stable during the life of the contract.
> 
> Speakers will discuss various aspects of contractual networking, including network validation, service level objectives, intent-based networking, and access authorization for network resources. Exploring the suitability of various models of implementation is encouraged - for instance, segment routing or network service headers may be suitable to assure adherence to the terms of the contract.  Techniques for contract negotiation and data structures for efficient forwarding are of interest.
> 
> This session is not aimed at forming a working group.  If interest is expressed during the meeting, we will discuss next steps and try to identify whether the work fits within current working groups.
> 
> ====================
> 
> Regards,
> Charlie P.
> 
> 
> 
>

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 6 Nov 2021 08:22:22 -0700

Hello Jared,

We do not yet have any speakers scheduled that would fit your 
description.  However, such a viewpoint from the operational side would 
be very welcome.   Would you like to have some time allocated to present 
your insights from that point of view?

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 7 Nov 2021 10:23:42 -0800

Hello folks,

I have received requests for additional information.  I posted a file 
that includes the Agenda: IETF 112 - Contractual Networking - HedgeDoc 
<https://notes.ietf.org/s/NP-VkQGjB#>.  The webex link and other 
information is also on the IETF 112 side meetings wiki: 
https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings

By the way, this is the first time I have put anything on 
notes.ietf.org.  It's very nice to have that website available, and it's 
pretty easy to create meeting notices.  Thanks to whoever did that.

Naturally Yours,
Charlie P.

On 11/5/2021 12:55 PM, Charlie Perkins wrote:
> network layer between different parties in a communication. We could 
> use in-band or out-of-band solutions, solutions at layer 3, 3.5, or 
> layer 4. We would like to discuss the potential mechanism to 
> provide/negotiate a contract. Should these be introduced as data 
> within Internet packets to provide the contractual context to the 
> flow, or should this be kept in the control plane? How should we 
> ensure compliance? Is IP with some label option enough? Should IP be 
> evolved?  Alternatively, should compliance mechanisms reside in the 
> control plane, or in virtual network/network slices?
>
> the suitability of various models of implementation is encouraged - 
> for instance, segment routing or network service headers may be 
> suitable to assure adherence to the terms of the contract.  Techniques 
> for contract negotiation and data structures for efficient forwarding 
> are of interest.
>