Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

From: Toerless Eckert <[email-masked]>
Date: Thu, 8 Apr 2021 02:24:22 +0200

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-masked]> a écrit :
> 
> ???
> 
> On 1 Mar 2021, at 20:08, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> 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-masked]
> https://www.ietf.org/mailman/listinfo/int-area

-- 
---
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Apr 2021 15:49:02 +0000

Hello Toerless

I'm not the right person to discuss this, one needs to be close to hardware implementation to wee what's easy what's not. Still I'm curious what you have in mind.

The backward-compatible piece is the core thing isn't it? 
SRv6 flies over a legacy IPv6 network between SR-capable nodes. I believe it is quite a selling point.

Do you intend to make addresses larger than 128bits and then encode network programming in there?
If so, and speaking of 40 years-old networking, I'd be tempted to encode the program as an address extension as opposed to within the address, and to leave the address as is - like good old phone number extension. Arguably one could define a SRH that is composed of {address_extension, next_address} where the extension applies to the previous address (the destination in the IP header for the first entry in the SRH.

For shorter-than-128bits addresses in a limited domain like an IoT network, yes we've done quite a bit in the IoT space, with a degree of freedom that 6MAN seems exempt. SCHC could give you almost anything you want, provided that you can configure the right state everywhere. 6LoWPAN can exclude a well-known prefix from the packet on the wire so you can have shorter local addresses. What the IoT art does not give you is network programmability.

Keep safe;

Pascal

> -----Original Message-----
> From: Toerless Eckert <[email-masked]>
> Sent: jeudi 8 avril 2021 2:24
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Stewart Bryant <[email-masked]>; Brian E Carpenter
> <[email-masked]>; draft-jia-flex-ip-address-
> [email-masked]; int-area <[email-masked]>; Jiayihao
> <[email-masked]>; draft-jia-scenarios-flexible-address-
> [email-masked]
> Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible
> addresses
> 
> 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.
> 
> 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.
> 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
> 
> > 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.
> >
> > On 1 Mar 2021, at 20:08, Brian E Carpenter
> <[email-masked]<mailto:[email-masked]>> 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.
> >
> >
> > 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
> >
> >
> >
> >

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Apr 2021 23:29:03 +0200

On Thu, Apr 08, 2021 at 03:49:02PM +0000, Pascal Thubert (pthubert) wrote:
> Hello Toerless
> 
> one needs to be close to hardware implementation to wee what's easy what's not.

Indeed. And we have not tried to formalize this understanding
(whats appropriate, what not). Instead we have contiuously done
one-off discussions about what type of TLV encoding, seuqencing
of headers and so on is appropriate and what is not. Meanwhile,
we have come up with such formalizations for management (YANG) and
control (CBOR) plane. I think we should staert thinking of formalizing
this understanding for forwarding plane. P4 and beyond is a great basis
to start from.

> I'm not the right person to discuss this,

Given how ASIC HW has come closer and closer to general purpose CPU
over the last two decages (still a good way away), its just a matter
of time untill all your low-power CPU experience will equally be
valid for high performance ASIC ;-)) (yeah, i know, blunt simplification,
but hopefully some truth in it).

> Still I'm curious what you have in mind.

IMHO we should generalize the approach we introduced (not 100%
completely, but pretty well) with MPLS:
Define the encoding independent of semantic. That lets us 
introduce semantics much easier over time without having to
argue over and over if the choosen encoding is feasible or not.

> The backward-compatible piece is the core thing isn't it? 

At the functional level, yes. Not at the encoding level. I can always
do a bidirectional transltion of packets headers if needs be to
come up with a new encoding that more future proof.

But yes, at the functional level i do not want to repeat the
problems of IPv4 to IPv6 transition or 20 years of 16++ NAT.
I would just like to add on functionaly to IPv6 and all the
add-on options can start in controlled networks, and we can
determine later on if/how those extensions would be applicable
to "The Internet".

> SRv6 flies over a legacy IPv6 network between SR-capable nodes. I believe it is quite a selling point.

Except that IPv6 implementations has been a lot less successful
to ensure that extension headers that are not supported by a forwarder
are to be ignored at full HW forwarding speed. I am not sure if
there have been tests to that end: e.g.: attempt to pass SRH
across internet paths. Obviously thats not too important for
SRH intended use, e.g.: its sufficient for SRH to just pass through
< 5 high-speed router vendor HW forwarding planes.

> Do you intend to make addresses larger than 128bits and then encode network programming in there?

I think longer and shorter would be highly valuable, yes.
Shorter already because it would be the easiest way to
optimize SRv6 (IMHO).

> If so, and speaking of 40 years-old networking, I'd be tempted to encode the program as an address extension as opposed to within the address, and to leave the address as is - like good old phone number extension.

Definitely. But why would you want to use 128 bit addresses inside a
controlled network ? If IPv6 would support shorter addresses, i am
sure many SPs would choose to use such an option inside their
network. Sure, there are _some_ interprovider Inter-AS solutions,
but even those can IMHO easily be solved with a lot shorter addresses.

> For shorter-than-128bits addresses in a limited domain like an IoT network, yes we've done quite a bit in the IoT space, with a degree of freedom that 6MAN seems exempt. SCHC could give you almost…

True, but its AFAIK (correct me if i am wrong) still is based
on the basic IPv6 architecture of only 128 bit addresses.

And the 128 bit addresses length is (IMHO) not the only career limiting
issue with IPv6. The 64/64 split for hosts too is hurtful IMHO.
We have been able to ignore this forever on routers, but we can't
seem to agree that we should be able to do for "normal" hosts as
well.

> Keep safe;

You too

Cheers
    Toerless

-- 
---
[email-masked]