Re: Limited Domains:

[Toerless Eckert <[e-mail]>]

On Tue, Apr 13, 2021 at 08:38:06AM +0200, Tony Przygienda wrote:
> IME problem is deeper and I don't only see it on v6 either. There is a
> class of folks that are protocol designers and there is a (growing in last
> couple years?) class of folks saying, "oh, I see so many bytes, I can do so
> many things in those bits and damn' the torpedoes and semantics" or even
> worse "I can stick my stuff in somewhere in the packet header, worst case
> let's add TLVs to packet header". But generally it's been going on since
> time immemorial, DSCP, 8+8, BIER mask encoding in v6 address and so on.

Well. I think we had some good successes in actually making addresses more
useful by giving them more semantics than the IPv4 designers ever imagined.
Embedded-RP being one example. Not sure what the best example would be
for eg: SRH programming bits in addresses. 

Would i have choosen to do these functions he way we do them now in IPv6 ?
Probably not, but i think there was and still is no way to to go
through the learning experience. Similarily, we didn't know how to
interconnect two quite similar protocols IPv4/IPv6 in the 90th. SO now
we have a mess of 16++ 4<->6 'NAT' solutions, but we are a lot more knowledgable.

And we have certainly and still try to do things that as you rightfully say
have or should be rejected by strong contributors/WG-chairs. But in many
cases, that real or intended "abuse" is becaue our current protocol IPv6
is just not flexible enough for sane extensions. And given how our hardware
does improve not only in speed but also flexibility over the decades, it is
just sad to see that we do not try more to get the additional value ou of
our hardware by thinking about a more flexible new packet headers.

Yes, variable lengths is a big step. Trust me, i had to fight tooth and nails
to even get it into control plane ca. 15? years back in mLDP FEC addressing,
but it did open a lot of things we couldn't do before with PIM. And
we are now 50 years away from the point in time when we thought fix lengh
is reqired.

I think in hardware we did start to support more and more variable length
with things like MTRIE lookups or as bad as it is waste in IPv4 for IPv6
centric TCAM designs/setup. So i think we are rally at an inflecion
point that would allow us to do better variable length packet header
designs. Whether those would be TLV (like IPv6 extension headers) or
different is something i think we're going to discuss a lot in the MPLS DT.

> Thankfully we still have strong WGs/chairs in many places that try to keep
> the finger in the dyke (mostly) but it's frustrating for people with line
> speed silicon to see lots folks pushing for those things who have no
> understanding of limitations of header pipelines, impact of shifting
> offsets, huge security filters etc on the ultimate power consumption, size
> and finally price of the very electrons delivered to carry the bit that
> writes those emails ;-)

I think the few vendors who make all the money with high-speed silicon
based routers not only deserve the pain of more and more users/researchers
wanting to get more easily built innovation out of those chips, i think
even more so, that supporting that direction is a core part of avoiding
to be commoditized by the white box chip designers. To me router land
still looks as if Intel tried to be successful without allowing any
not-in-house developed software to run on their CPU. 

Yes, opening up his proprietary HW stack will likely not work in the
same way as it would for general-purpose CPU, but more easily "programmable"
packet headers plus third-party programmable control plane would go
a long way in exploring and supporting new market opportunities and
business models. Especially for the wide variety of limited domain
networks.

Cheers
    Toerless
> my 2c


> 
> -- tony
> 
> On Mon, Apr 12, 2021 at 11:01 PM Brian E Carpenter <
> [e-mail]> wrote:
> 
> > On 13-Apr-21 06:13, Tom Herbert wrote:
> > > On Mon, Apr 12, 2021 at 10:50 AM Ron Bonica
> > > <rbonica=[e-mail]> wrote:
> > >>
> > >> Toerless,
> > >>
> > >> You say that "we simply should look into new, more flexible, extensible
> > base header, backward compatible to IPv6/Internet (but with code points
> > assigned to functionality, as we do with extension headers for example)."
> > >>
> > >> The idea is intriguing, but it leads to the following questions:
> > >>
> > >> - How do you make this new base header backwards compatible with
> > IPv6-classic?
> > >> - Is draft-filsfils-6man-structured-flow-label an example of this new
> > base header?
> > >>
> > > Right, it's hard to imagine that a new base header could be used
> > > without creating a new IP version which is at least twenty years just
> > > to get off the ground. I suppose the idea might be to have special
> > > value in the next protocol that indicates an extension to the base IP
> > > header, but then doesn't that just degenerate to to be another
> > > extension header?
> >
> > Yes. And while we're at it, let's use Huffman coding for IP addresses.
> >
> > Whatever we do, we won't get away from actual line-speed implementations
> > being constrained by current integrated circuit technology. So every few
> > years, with a new generation of technology, the constraints change, just
> > as the Strowger switch revolutionized telephony in 1891.
> >
> >    Brian
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


-- 
---
[e-mail]