Robert,
I wish we had accepted your initial proposal, all those years ago. Now that we
have begun deployment, changing direction is more difficult. But experience
teaches us that proceeding with a questionable decision because deployment has
begun frequently contributes to the accumulation of architectural debt.
The incremental deployment problem that you mention was solved many years ago.
Tunnel SRv6 over something else (IPv4, IPv6, MPLS, whatever.)
Ron
Juniper Business Use Only
________________________________
From: Robert Raszuk <rob...@raszuk.net>
Sent: Tuesday, March 26, 2024 1:24 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: Tom Herbert <t...@herbertland.com>; Alvaro Retana <aretana.i...@gmail.com>;
Andrew Alston - IETF <andrew-i...@liquid.tech>; spring@ietf.org
<spring@ietf.org>; Joel Halpern <j...@joelhalpern.com>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
Ron,
While I did suggest the use of new Ethertype for SRv6 in the very early days
the killer and valid argument against it was ease of deployment. An equally
valid argument was built in the extensibility of IPv6 protocol.
So we see the latter is an interesting one, but let's zoom on the former.
In a 1000 node network, if I want to enable SRv6 only on subset of nodes (which
in many cases is sufficient for a lot of TE purposes) I need to upgrade only
those affected nodes leaving all other nodes just doing basic vanilla IPv6.
If for SRv6 encapsulation new Ethertype is used all 1000 nodes need to be
upgraded. It will be worse then transition to IPv6 as you will then say - Oh
Mr. Customer ... do you really need to upgrade your entire network and spend
millions doing it - just stick to SR-MPLS :) And I know you would love to do
that.
So I think like others say .. The ship has hit the waters. You have a choice to
jump on it or stay on the shore.
Cheers,
Robert
On Tue, Mar 26, 2024 at 6:14 PM Ron Bonica
<rbon...@juniper.net<mailto:rbon...@juniper.net>> wrote:
Working Group,
Might SRv6 progress much more quickly if we did the following:
*
Divorce SRv6 from IPv6
*
Give SRv6 its own ethertype
*
Let SRv6 progress along its own evolutionary trajectory, unencumbered by IPv6
restrictions
At very least, this divorce would end the long and painful debates regarding
IPv6 compliance. And would it give SRv6 more degrees of freedom as it evolves,
As far as I can see, the only benefit of binding SRv6 to IPv6 is in the
expectation that IPv6-enabled hardware won't have to change too much to support
SRv6. This benefit might still be realized if SRv6 doesn't deviate too much
from IPv6.
My question is not rhetorical. Maybe I am missing something, but is there any
real benefit in continuing to bind SRRv6 to IPv6?
Ron
Juniper Business Use Only
________________________________
From: Tom Herbert <t...@herbertland.com<mailto:t...@herbertland.com>>
Sent: Monday, March 25, 2024 3:40 PM
To: Alvaro Retana <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>
Cc: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Andrew Alston
- IETF <andrew-i...@liquid.tech>; Ron Bonica
<rbon...@juniper.net<mailto:rbon...@juniper.net>>;
spring@ietf.org<mailto:spring@ietf.org>
<spring@ietf.org<mailto:spring@ietf.org>>; Joel Halpern
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
On Mon, Mar 25, 2024 at 12:31 PM Alvaro Retana
<aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>> wrote:
>
> Tom:
>
> Hi!
>
> I understand your point.
>
> I put the option out there because it came up at last week’s spring meeting
> and it should be discussed.
Alvaro,
This seems to come back to the fundamental question: is SRv6 still
IPv6 or is it a new protocol. If it's IPv6 then it should adhere to
all the requirements and expectations of IPv6, if it's a new protocol
that is going to diverge from the standard IPv6 then maybe it needs
its own EtherType and standards development path.
Tom
>
> Thanks!
>
> Alvaro.
>
>
> On March 25, 2024 at 2:58:48 PM, Tom Herbert
> (t...@herbertland.com<mailto:t...@herbertland.com>) wrote:
>
> On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana
> <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>> wrote:
> >
> > FWIW, I agree with most of what Joel wrote. ;-)
> >
> > I see another path forward: Given that the issue is constrained to an SR
> > domain, the draft could also point out the issues as operational/deployment
> > considerations. Operators can then make an informed decision on whether
> > they want to/can use C-SIDs without an SRH in their network. This path
> > forward (or leaving it out of scope, as Joel suggests below) is something
> > the spring WG can reach consensus on by itself (i.e., without needing to
> > consult or agree with other WGs).
>
> Alvaro,.
>
> This wouldn't be robust and would seem to violate the "be conservative
> in what you send clause". Punting this to the operators doesn't seem
> practical either, in an even moderately large network they wouldn't be
> able to know all the potential problems they might hit in devices.
> They're about one misconfiguration away from having to debug a rather
> unpleasant problem. For instance, if operator gets a packet trace from
> a router they would see a whole bunch of packets with bad checksums,
> but they would have no way of knowing if these were cases of segment
> routing or actually corrupted packets.
>
> Tom
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
