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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
