Re: Other use cases for header insertion (was Re: Header Insertion and TI-FA)

Toerless,

No one said here that such change would be bound to contain only two new
relaxed rules related to routing header processing.

Cheers,
R.

On Tue, May 12, 2020 at 7:48 PM Toerless Eckert <tte@cs.fau.de> wrote:

> I would love to hear i am wrong, but i am sure a new IP version number
> would introduce
> more need for HW-upgrades. While i appreciate architectural cleanlyness, i
> really would love if
> we would reserve the need for such fundamental HW changes to more
> fundamental improvements
> to our IPv6 networkinging layer.
>
> For example: IPv6++ could support different adress spaces of different
> address sizes, one
> of which could be Internet/IPv6, another one Internet/IPv4 and many more
> for various address
> sizes for the probably millions of private IP networks on the planet,
> including the "transport"
> layer "network" of most SP networks with likely << 128 bit address sizes
> or even smaller IoT networks.
> Interop between different address spaces/sizes is designed upfront instead
> of 28+ IPv4/IPv6 transition
> solutions.  Addresses would not have to be (ab)used for every path
> processing function because the
> header provides ways to define better alternatives and those are correctly
> MUST requirements in the
> spec, and steering would not be constrained to the concepts of a 40 year
> old source-routing design.
> Oh, and QoS would get more than 8 bits so we would not have to fight over
> semantic of 1 ECN bit.
>
> To me, that would be evolution goals for which it would be worth to
> consider mayor HW upgrades and
> assigning a new IP version codepoint. Would be nice if more IPv6
> supporters would think about
> these type of now well feasuble and understood long-term innovation
> options instead of only
> trying to stick to the status quo in the hope of increasing adoption.
>
> Cheers
>     Toerless
>
>
> On Tue, May 12, 2020 at 02:45:27PM +0000, Ron Bonica wrote:
> > Robert,
> >
> > I realize that you are joking, but it might actually be a good idea for
> SRv6 to move onto another protocol number. This would solve the following
> problems:
> >
> >
> >   *   SRv6 could do whatever it wanted, without regard for RFC 4291,
> RFC 8200, or anything else that 6man produces
> >   *   6man could evolve IPv6 as it sees fit, without having to consider
> the sensitivities of SRv6
> >
> > It would only mean changing the first four bits of every SRv6 packet.
> That would probably take much less time than converging the SRv6 and IPv6
> architectures.
> >
> >                                                          Ron
> >
> >
> >
> >
> > Juniper Business Use Only
> > From: Robert Raszuk <robert@raszuk.net>
> > Sent: Monday, May 11, 2020 4:43 PM
> > To: Brian E Carpenter <brian.e.carpenter@gmail.com>
> > Cc: Tom Herbert <tom@herbertland.com>; Ron Bonica <rbonica@juniper.net>;
> 6man <6man@ietf.org>
> > Subject: Re: Other use cases for header insertion (was Re: Header
> Insertion and TI-FA)
> >
> > [External Email. Be cautious of content]
> >
> >
> > I'm not sure this is feasible without changing the IP version number.
> >
> > How about IPv6+ ?
> >
> > Thx,
> > R.
> >
>
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
> --
> ---
> tte@cs.fau.de
>