Pascal,
Yes, the low-power world in IETF invented a lot of concepts that SRv6 then
reinvented, but
heck, late in the process they managed to at least acknowledge some of that
prior work through
references ;-) nd not, the logic around compact alternatives to SRH also
started with the premise that
those shorter representations are compressed versions of IPv6 addresses (if i
still understand it right).
This is all great and fine if we think that the only future we can think if is
one where we try
to fit everything we want to innovate on into the tight box of rfc8200. And
while i agree
tht there may be good short-term reasons for such options, i just don't see
this as a viable
long-term option to significantly evolve our network layer protocol benefits
beyond the original
esign of 40 years ago. At least not without incurring a lot of technology dept
that makes it more
and more difficult to deploy and expand with.
To me the much more interesting question to ask than "how can we make
innovation fit rfc8200"
is how we could provide the most backward compatible superset of network layer
functionality
that does allow us to carry forward what we need (e.g.: IPv4/IPv6 semantic),
but also allows us
to extend semantics (especially addressing) in the most
cost-effective/performance/least-obfuscated way.
And i don't think it is hard.
The mayor stumbling block IMHO is to recognize that unlike maybe 25 years ago
when
ISO8473 was around, we nowadays IMHO do NOT have any issues high-speed hardware
forwarding
anymore to have headers with different length address, but using a unified
forwarding plane logic
and hopefully even much more shared control plane as eventoday acros IPv4 and
IPv6.
If we just had those variable length adddresses, all the discussions about SRH
alternatives
would go away because each address element could have a forwarding component as
short/long as
necessary for the network and as many programmabiliy bits behind it as desired
- for this element.
Likewise, i would venture to guess that a lot of the low-power network
solutions would become much simpler
and efficient by aleviating the need to compress addresses.
Cheers
Toerless
On Wed, Mar 03, 2021 at 11:05:42AM +0000, Pascal Thubert (pthubert) wrote:
> Hello Stewart, Brian and Toerless:
>
> Interestingly RFC 8138 took one step in that direction. Yes you???re going to
> need a new Ethertype but it???s still IPv6 I. That is is expressed as a
> compression not a modification of IPv6.
>
> In the compressed form the header starts with the next hops, the destination
> and SRH being indiscriminated, the destination is just the first of the list.
> The size is variable but each hop is at most 128 bits. Because the SRH could
> encode SRv6 you can already go a long way with this.
>
> If that can help you do what you want, I m happy to explain more...
>
> Keep safe.
>
> Pascal
>
> Le 2 mars 2021 à 13:33, Stewart Bryant <[email protected]> a écrit :
>
> ???
>
> On 1 Mar 2021, at 20:08, Brian E Carpenter
> <[email protected]<mailto:[email protected]>> wrote:
>
>
> It would take but a minute to design a longer-address mechanism for IPv6,
> although I don't have space to include it in the margin of this email**. But
> it would take many years for it to be widely implemented and deployed, during
> which time the Internet would be opaque to such addresses.
>
>
> ** Basically, use a prefix such as fb00::/8 to indicate an extended address.
>
> Hi Brian
>
> Basically I think that this fails the backwards compatibility text.
>
> It is perfectly legitimate to write an IPv6 forwarder as follows:
>
> If MACaddress == me and MACtype == IPv6 pass packet to IPv6 forwarder
>
> In IPv6 forwarder:
>
> If version == IPv6 and Hop Limit not exceeded send bytes 24 to 39 to address
> lookup engine
>
> Wait for address result and forward packet accordingly
>
> Except that this forwarder would have sent a bunch of random junk to the ALE
> consisting of some of the SA and maybe some of the DA depending on their
> sizes.
>
> So to stop an old and legitimately designed parser being fooled you really
> have to use a new MAC type and a new version and as soon as you do that you
> might as well design the packet optimally for the job at hand.
>
> If the IPv6 designers had followed the strategy of both the Ethernet
> designers and the ISO8473 designers and put DA before SA then the elegant
> approach that you and others have proposed at various times would have
> worked nicely.
>
> Best regards
>
> Stewart
>
>
>
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
--
---
[email protected]
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
