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 protected]> On Behalf Of Toerless Eckert Sent: Tuesday, October 26, 2021 1:06 AM To: [email protected] Subject: [spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets) 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
