Subject: [spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets)

From: Toerless Eckert <[email-masked]>
Date: Tue, 26 Oct 2021 00:05:45 +0200

Dear Spring WG.

Through IntArea and other WGs, some of us started to invesstigate what
benefits it wouldhave to support variable long network layer addressing,
and assuming we had them, how to better encode the semantics we're 
interested in them.

I did propose at 111 via draft-eckert-intarea-functional-addr-internets one
such approach, and while i didn't have time so far to better highlight
in the draft itself in more details the applicability to the problems
i think SPRING is working on, i would nevertheless be very happy to
get feedback and thoght on it.

I'll ask the chairs if they might have 5..10 minutes to give a SPRING centric
presentation Q&A for IETF112 of the idea. The pitch is really:

-> If we are for spring trying to have more flexible and compact addressing
   to steer packets and call programs along the way, why do we want to
   constrain ourselves with rfc8200 encoding and addressing rules ?

   Sure, going beyond rfc8200 miht take a while, but its not as if
   we're in a hurry to plan a long term evolution now. We're not as
   pressured as we where by the Internnet in the 90'th to "quickly" come
   up with IPv6 (and leave a lot of IP-NG thoughts out of the picture).

-> If we would figure out a new base header to superceed/amend rfc8200,
   we could IMHO become better for the addressing we seemingly like to
   have in SPRING than what we could do under rfc8200 doctrine.   

-> For our subject proposal specifically, applied to SPRING, the idea is simply to
   have the destination address be simply a sequence of the steering hops
   (each with an address length as long or short as the network operator wants),
   followed by the hops instructions - again as short or as long as the
   network operator wants. Aka: no worries anymore to come up with bogus
   rason why we need 128 bits for a steering how when we don't need
   programmability, and no reason to be woried we might run out of programming
   addressing space when we want more. And no need to additional extension
   headers when it can all be as simple as putting it into a single
   address.

Cheers
    Toerless

P.S.: Of course, if/when we think we want to do something in that direction,
SPRING itself may not be the executing body of any work, but maybe
6man or somethin with more willingness to innovate than 6man, but thats
IMHO not the first step of discussion.

---

From: Andrew Alston <[email-masked]>
Date: Wed, 27 Oct 2021 12:41:52 +0000

Toerless,

I have one question - how you reconcile any of what is in the email below with the spring charter.

I would say - that if this line of thought were to be progressed - that the way forward would be to call a BOF - see if there was support - and form a working group - and at that point - if there was support to effectively introduce an entire new dataplane and everything it encompasses - it could go forward leaving ipv6 alone and in its original state for those that have absolutely zero interest in seeing ipv6 changed to the degree that seems to be being proposed here.

But irrespective of that - the spring charter is extremely clear  - if you wish to modify an existing data plane - it should be done inside the working group that owns that data plane - or at the very least - with the permission of that working group's chairs and the AD's of that particular area.  This is very far out of mandate in my view

Andrew

From: spring <[email-masked]> On Behalf Of Toerless Eckert
Sent: Tuesday, October 26, 2021 1:06 AM
To: [email-masked]
Subject: [spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets)

Dear Spring WG.

Cheers
Toerless

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>