Subject: Re: [spring] Is srv6 PSP a good idea

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 14:48:50 +0100

Hi Robert,

> Regardless if folks agree or not with that SRv6 is a new data plane. SRv6 != IPv6 that's obvious. 
> 
> It also does not attempt to *extend* IPv6. It reuses some IPv6 elements and makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but that's it. With that in mind all of this going back and forth between SPRING and 6MAN to me is triggered by wrong positioning of SRv6 as a new transport. 

This is completely bogus. SRv6 is not a new L3 protocol that just happens to be compatible with IPv6. That is insane BS.

> Sure if SRv6 would be extending IPv6 then updates to RFC8200 would be needed - but here RFC8200 should at best be informative reference. I am not even sure why SRH needs to be 6MAN RFC. IETF is designed to build and improve prior art not be locked by it. 

Because you are building SRv6 on IPv6, plain and simple.

Cheers,
Sander

---

From: Andrew Alston <[email-masked]>
Date: Wed, 26 Feb 2020 14:15:22 +0000

+1 Sander.

Furthermore - if indeed that is the contention - then - I suggest you move the whole thing out of SPRING - I quote from the SPRING charter:

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).

Relevant portion in bold.

You can claim that SRv6 is a new routing header - you cannot claim that it is not part of IPv6 - the IPv6 base header is maintained - you are adding a routing header - done/done - no point even entertaining this line of thought any further

Andrew

From: spring <[email-masked]> On Behalf Of Sander Steffann
Sent: Wednesday, 26 February 2020 16:49
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; 6man WG <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

Hi Robert,

Cheers,
Sander

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: Andrew Alston <[email-masked]>
Date: Wed, 26 Feb 2020 14:24:48 +0000

Figured I'd add to this - as I continued to read the charter

SPRING WG should avoid modification to existing data planes that would
make them incompatible with existing deployments. Where possible,
existing control and management plane protocols must be used within
existing architectures to implement the SPRING function. Any
modification of -or extension to- existing architectures, data planes,
or control or management plane protocols should be carried out in the
WGs responsible for the architecture, data plane, or control or
management plane protocol being modified and in coordination with the
SPRING WG, but may be done in SPRING WG after agreement with all the
relevant WG chairs and responsible Area Directors.

If SRv6 is not IPv6 - as is the contention - (which in my view is an absolutely false contention designed to step around a specification because it simply doesn't suite what you want) - well - then what exactly are we doing here - because by that claim - we are inventing a new control plane, a new data plane, and well, it's a new protocol - so - do we have the agreement of the relevant WG chairs, Area Directors etc - to invent an entirely new everything.

Didn't think so....

Andrew

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 11:24:25 -0300

On 26/2/20 11:15, Andrew Alston wrote:
> +1 Sander.
> 
> Furthermore – if indeed that is the contention – then – I suggest you 
> move the whole thing out of SPRING – I quote from the SPRING charter:
> 
> /The Source Packet Routing in NetworkinG (SPRING) Working Group is 
> the////home of Segment Routing (SR) using MPLS (SR-MPLS) *_and IPv6 
> (SRv6)._*/*/__/*
> 
> You can claim that SRv6 is a new routing header – you cannot claim that 
> it is not part of IPv6 – the IPv6 base header is maintained – you are 
> adding a routing header – done/done – no point even entertaining this 
> line of thought any further

The fact that this is still going on is at least alarming.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tom Herbert <[email-masked]>
Date: Wed, 26 Feb 2020 08:37:58 -0800

On Wed, Feb 26, 2020, 6:26 AM Andrew Alston <[email-masked]>
wrote:

> Figured I’d add to this – as I continued to read the charter
>
>
>
> *SPRING WG should avoid modification to existing data planes that would*
>
>
>
>
>
>
>
>
> * make them incompatible with existing deployments. Where possible,
> existing architectures to implement the SPRING function. Any modification
> of -or extension to- existing architectures, data planes, or control or
> management plane protocols should be carried out in the WGs responsible for
> the architecture, data plane, or control or management plane protocol being
> modified and in coordination with the SPRING WG, but may be done in SPRING
> WG after agreement with all the relevant WG chairs and responsible Area
> Directors.*
>
>
>
> If SRv6 is not IPv6 – as is the contention – (which in my view is an
> absolutely false contention
>

+1

> designed to step around a specification because it simply doesn’t suite
> what you want) - well – then what exactly are we doing here – because by
> that claim – we are inventing a new control plane, a new data plane, and
> well, it’s a new protocol – so – do we have the agreement of the relevant
> WG chairs, Area Directors etc – to invent an entirely new everything.
>

That's already happened. SRH has reinvented both protocol options, TLVs, in
the network layer, as well as header authentication.

Tom

>
>
> Didn’t think so….
>
>
>
> Andrew
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Feb 2020 20:44:52 +0100

Hey Sander,

No worries ... three IPv6 musketeers have already presented themselves well
to this discussion. This was just one more demo of it. No need to apologize
- at least me :)

And while you can call someone's opinion the way you like - the fact that
SRv6 builds on top of IPv6 does not make it automatically IPv6 extension.

My perhaps subtle point was that while politically it has been sold like
minor IPv6 extension from technical point it does not need to be
positioned like one. The sole fact that it reuses the same ethertype does
not make it an extension.

Now as I have already been through my round of circular explanations in the
previous months - now I just sit and watch how it goes round and round
again.

Best,
R.,

On Wed, Feb 26, 2020 at 8:22 PM Sander Steffann <[email-masked]> wrote:

> Hi,
> >> It also does not attempt to *extend* IPv6. It reuses some IPv6 elements
> and makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but
> that's it. With that in mind all of this going back and forth between
> SPRING and 6MAN to me is triggered by wrong positioning of SRv6 as a new
> transport.
> >
> > This is completely bogus. SRv6 is not a new L3 protocol that just
> happens to be compatible with IPv6. That is insane BS.
>
> I have been told by good friends that my language was inappropriate. It
> probably is, but I'm not going to apologize for it. I and others have tried
> the polite way unsuccessfully and are still ignored by the authors. This
> has been going on for far too long, and if it's necessary that someone
> stops being polite and call it out then I'll be the one to do it.
>
> Cheers,
> Sander
>
>
>

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 21:07:44 +0100

Hi Robert,

> No worries ... three IPv6 musketeers have already presented themselves well to this discussion. This was just one more demo of it. No need to apologize - at least me :)
> 
> And while you can call someone's opinion the way you like - the fact that SRv6 builds on top of IPv6 does not make it automatically IPv6 extension.

Yes it does. It uses the IPv6 header with IPv6 extension headers with IPv6 addresses. SRv6 packets are IPv6 packets, and therefore have to follow IPv6 semantics. If you want to create an exception to that, then RFC8200 is the place to be.

> My perhaps subtle point was that while politically it has been sold like minor IPv6 extension from technical point it does not need to be positioned like one. The sole fact that it reuses the same ethertype does not make it an extension.

Oh yes, it also uses the IPv6 ethertype. I almost forgot that one. SRv6 is still based on an IPv6 *Extension* Header.

> Now as I have already been through my round of circular explanations in the previous months - now I just sit and watch how it goes round and round again.

Happy to hear you're giving up on pushing a draft that violates RFC8200 by claiming that SRv6 doesn't have to follow the RFC that it is based on because SRv6/NP is special, SRv6/NP is not really IPv6, IPv6 addresses as used by SRv6/NP aren't really IPv6 addresses etc.

Instead of trying to squeeze your way through with all these excuses, why not simply acknowledge the comments that PSP violates RFC8200, and either work on updating RFC8200 or removing PSP (whose benefits have been questioned on their own)? Work with this community and the operators to gain actual consensus, not some parody of consensus by trying to bend the rules when you don't like them.

You could easily get my consent by removing PSP from the draft. It violates RFC8200 and for what? What makes PSP so important that the draft would be unworkable without it? Why do you rather play these games than adjust the draft based on honest feedback? What hidden agendas are there? Because based on everything I have seen PSP is a minor feature that is implemented in a very controversial way. Why is it worth all this nonsense? (and I mean nonsense in the literal way: it really doesn't make sense to me)

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 17:09:47 -0300

On 26/2/20 16:44, Robert Raszuk wrote:
> Hey Sander,
> 
> No worries ... three IPv6 musketeers have already presented themselves 
> well to this discussion. This was just one more demo of it. No need to 
> apologize - at least me :)
> 
> And while you can call someone's opinion the way you like - the fact 
> that SRv6 builds on top of IPv6 does not make it automatically IPv6 
> extension.
> 
> positioned like one. The sole fact that it reuses the same ethertype 
> does not make it an extension.

Yeah, it's not an extension: it's a major surgery to IPv6, and a major 
change to the IPv6 architecture (nobody would even call it "IPv6 
maintenance").

A number of us wonder how many milliseconds it would have taken for this 
proposal to be shot down if it wasn't being pushed by a big vendor.

Thanks,

---

From: "john leddy.net" <[email-masked]>
Date: Wed, 26 Feb 2020 15:22:02 -0500 (EST)

I would suggest that people read RFC 7282 - "On Consensus and Humming in the IETF"...

My question is: How do you reach Consensus when the complaint is about how many milliseconds it takes to shoot down a proposal?

Is this about the proposal or the vendor involved?

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 21:24:31 +0100

Hi John,

> Is this about the proposal or the vendor involved?

Definitely the proposal. That a vendor seems to have an inappropriate amount of influence on the IETF process is just an additional concern.

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 21:27:52 +0100

> Definitely the proposal. That a vendor seems to have an inappropriate amount of influence on the IETF process is just an additional concern.

PS: that the vendor is Cisco in this instance is not relevant. Any vendor doing this would be equally bad. Any major vendor has played inappropriate games using the IETF. This is just what is currently on the table.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 17:40:27 -0300

> My question is: How do you reach Consensus when the complaint is about how many milliseconds it takes to shoot down a proposal?

This document proposes a *major* change to IPv6. This group has been way 
overly conservative even for very minor modifications to the IPv6 specs, 
well within 6man charter.

Given that, I would have expected that a long time ago, a long queue of 
folks (including the relevant AD) had made it crystal clear that this is 
an update to RFC8200, and given the depth of the change, outside of the 
charter of 6man.

It is in a way unbelievable the amount of energy we spend on polishing 
maintenance updates to IPv6, but then fail to even recognize that what's 
being proposes by this document is a major update to IPv6, out of the 
scope of 6man (which stands for "IPv6 maintenance", and not for "IPv6 
major surgery").

The amount of nonsense we have had to deal with, including this proposal 
not violating RFC8200, this proposal being something else other than 
IPv6, etc., has also been pointed out by others.

> Is this about the proposal or the vendor involved?

It is about the proposal, indeed. I have sent dozens of emails 
expressing technical concerns for this proposal. And the only reference 
to "vendors" has been about the conjecture regarding why it has been 
acceptable for us being fooled around.

Full disclosure: You didn't ask, but I don't mind being very open about 
it: I don't work for any router vendor, or OS vendor, nor do I have any 
kind of ongoing, past, or future contract with any of them, or any other 
party involved in a competing technology.

I have technical concerns about the proposal (expressed ad nauseam), and 
also concerns about how this process has been going on.

Thanks,

---

From: "john leddy.net" <[email-masked]>
Date: Wed, 26 Feb 2020 16:02:44 -0500 (EST)

So you are saying that other than the PSP issue, you support moving the document forward?

> On February 26, 2020 at 3:40 PM Fernando Gont <[email-masked]> wrote:
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 18:18:45 -0300

> So you are saying that other than the PSP issue, you support moving the document forward?

A number of us had repeatedly expressed their concerns with the 
document. Please check the mailing-list archives.

I haven't argued in favor or against the document. I simply asked the 
existing specifications be complied with.

It's a waste of time to be rehashing the same discussions all the time.

Thanks,

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 22:20:41 +0100

Hi John,

> So you are saying that other than the PSP issue, you support moving the document forward?

Yes. As long as it doesn't violate existing RFCs and with that potentially causes trouble for implementations that expect those RFCs to be followed I'm fine with it. It's not something I would deploy, but I'm not going to stand in the way of those who want it if it's not going to hurt others.

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 18:26:02 -0300

> Yes. As long as it doesn't violate existing RFCs and with that potentially causes trouble for implementations that expect those RFCs to be followed I'm fine with it. It's not something I would depl…

Indeed, that's the underlying principle: don't violate existing specs, 
and if you mean to, propose a formal update of RFC8200.

(I don't remember of the top of my head if PSP was the only part of the 
document violating RFC8200, hence my general comment).

---

From: Mark Smith <[email-masked]>
Date: Thu, 27 Feb 2020 08:30:43 +1100

> No worries ... three IPv6 musketeers have already presented themselves well to this discussion. This was just one more demo of it. No need to apologize - at least me :)

You realise that the 3 musketeers were heroes in that story?

> And while you can call someone's opinion the way you like - the fact that SRv6 builds on top of IPv6 does not make it automatically IPv6 extension.

SRv6 is not building on top of IPv6 when it is proposing fundamental
changes to the way IPv6 packets are processed.

SPRING WG charter:

"SPRING WG should avoid modification to existing data planes that would
make them incompatible with existing deployments. Where possible,
existing control and management plane protocols must be used within
existing architectures to implement the SPRING function."

Regards,
Mark "Athos" Smith.

>> I have been told by good friends that my language was inappropriate. It probably is, but I'm not going to apologize for it. I and others have tried the polite way unsuccessfully and are still ignored by the authors. This has been going on for far too long, and if it's necessary that someone stops being polite and call it out then I'll be the one to do it.
>>
>> Cheers,
>> Sander
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Feb 2020 01:29:23 +0100

> You realise that the 3 musketeers were heroes in that story?

Oh I do.

And I want to sincerely congratulate three of you to be very effective to
discourage touching IPv6, its dogmas and principles. If this is good for
the industry, time will tell.

To me I got even more assurance now that IPv6 with its 40 octet fixed
header is a broken concept and deserves to be obsolete very soon -
especially for intra-domain use cases.

Btw new data plane much more efficient can be easily made compatible with
all existing and deployed v6 capable data plane hardware. If I would work
for a vendor perhaps I would have some cycles to propose it, but otherwise
it is just impossible to get sufficient support and get through with new
technology.

Kind regards,
RR.

PS. @Fernando ... you keep forgetting in your post and your errata about
RFC2473. I recommend you take a new read of it including section 3.1 and
match it against your IPv6 end to end principle. It is roto operational
principle behind SRv6.