Re: [spring] Question about SRv6 Insert function

[Robert Raszuk <[e-mail]>]

> what the current drafts do – is fundamentally rewrite the ipv6 protocol

I think you are giving small team of focused engineers way too much credit
here :)

What they tried to do is to merely make sure that if someone decides to use
IPv6 they have a chance to not only have functional parity with other
transports, but also could go a bit forward and turn v6 transport into more
innovation.

In that respect objectives of both SRv6 and SRv6+ are identical.

Now having seen stones being smashed at those who try to actually improve
IPv6 I am personally even more discouraged. It is now becoming even more
obvious why adoption of IPv6 in enterprise networks, enterprise compute
clusters or end users is so marginal after 25+ years ....

Cheers,
R.


On Fri, Sep 6, 2019 at 10:27 AM Andrew Alston <
[e-mail]> wrote:

> Robert, my problem here is – I believe that there could have been common
> ground found between various proposals except – what the current drafts do
> – is fundamentally rewrite the ipv6 protocol – the changes in the address
> semantics (twice over in incompatible ways between the programming draft
> and the uSID draft) – the violations of rfc8200 – etc – mean that – it
> becomes very hard to find a solution when there is a massive philosophical
> difference – where the philosophical difference is routed in – a v6 address
> is a 128bit identifier as defined by rfc4291 – vs – an address is well –
> insert a long list of other things on top of that.
>
>
>
> We spent the better part of 25  years getting IPv6 to what it is – and now
> – fundamentally – there is an attempt to rewrite the very thing that IPv6
> is – and therein lies one of my major problems – and no matter how many
> times I have raised the semantic issues – it seems to be an issue that is
> being blindly ignored.
>
>
>
> Tell me – how do you do aggregation of addresses in the network
> programming draft – aggregate – lose the function bits
>
> How do you do uSID in the network programming draft – shift – lose the
> function bits – or – retain the entire stack – and lose the entire point of
> uSID in the first place – to solve the overhead
>
> By rewriting the IPv6 specification in the way this does – it introduces
> draft after draft to cater for what is essentially no longer IPv6 – vs –
> finding a way to work within the IPv6 specification to produce the same
> functionality as is required in a compatible manner that is more efficient.
>
>
>
> Therein I believe lies half the root of this – on one side – you have an
> attempt to redefine an entire protocol that was 25 years in the making in
> the image of what one group of people believe it should be – on the other
> side – you have an acknowledgement of required functionality – and an
> attempt to provide it while not rewriting the entire protocol in the
> process.
>
>
>
> Andrew
>
>
>
>
>
> *From:* ipv6 <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* Friday, 6 September 2019 11:18
> *To:* Ron Bonica <rbonica=[e-mail]>
> *Cc:* Fernando Gont <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* Re: [spring] Question about SRv6 Insert function
>
>
>
> Ron,
>
>
>
> > They remind us that draft-ietf-spring-network-programming are far from
> maturity.
>
>
>
> To me it actually highlights something quite contrary. It is that some
> folks are pretty far from appreciating or even grasping the value of the
> proposal.
>
>
>
> In your other note you have extensively elaborated well on how to
> effectively kill innovation in IETF. If we would be following your advice
> there would be almost non documents which build on former work and update
> former work.
>
>
>
> But most importantly documenting something does not force anyone to
> actually use it if they choose so. This entire smoke about header insertion
> from what I have been told has some technical concerns about real source
> awareness about say MTU issues. Well for one if I am doing insertion in my
> network I better make sure I do not drop the packet based on the MTU. It is
> so basic ... of course I must clean up when I fwd the packet to other
> domain but this is basic network hygiene.
>
>
>
> In the same time folks are happy to encap + add EHs, DOs etc ... on the
> grounds that src of the encap will be in the packet. Is this sufficient ..
> even if ICMP is sent to such src (domian ingress) I bet such domain ingress
> will not notify the original packet src anyway. And with encap the packet
> gets much bigger anyway.
>
>
>
> But I was not part of v6 creators and I think I will keep it that way
> based on that little thread we had here :)
>
>
>
> Best,
>
> R.
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>