No Robert,
There are operators that have legitimate security concerns and concerts
about layer violations – and those operators are entirely in their rights
to have such concerns and act on them accordingly. What this means is that
unless those concerns are addressed (with a fail closed
solution/ethertype/whatever) those operators will err on the side of
security and choose to forgo srv6 entirely no matter what it offers.
This may well not be the case if SRv6 did diverge from Ipv6 and take
appropriate measures to become a fail closed system, giving the operator
the ability to run srv6 as they see fit, in either fail-closed mode (with
its own ethertype) or in open mode (without its own ethertype) – or in a
hybrid mode (though when we wrote the raviolli draft we chose not to
discuss the semantics of hybrid operation because of complexity and because
it probably would be a bad idea – but it CAN be done)
Thanks
Andrew
Internal All Employees
From: Robert Raszuk <rob...@raszuk.net>
*Date: *Wednesday, 27 March 2024 at 12:28
*To: *Andrew Alston - IETF <andrew-i...@liquid.tech>
*Cc: *Tom Herbert <t...@herbertland.com>, Ron Bonica <rbon...@juniper.net>,
Alexander Vainshtein <alexander.vainsht...@rbbn.com>, spring@ietf.org <
spring@ietf.org>, Alvaro Retana <aretana.i...@gmail.com>
*Subject: *Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
Andrew,
because there are operators out there that will never run srv6
So for the operator who will never run SRv6 what exactly is the problem ?
How is he going to be affected by any SRv6 extensions ?
Isn't such an operator acting like coast guard of selected IPv6 extensions
defending its day one "purity" even if people living further on the land
find it useful ? Or is there some cherry picking going on at the "Gates to
IPv6 Land" ? You can enter pls come in but you Sr. ohhh sorry No - pls go
away ?
As mentioned I did observe those operators fighting when 6man allowed SRv6
to be IPv6 and they lost the battle badly including fired appeals.
RFC8754 is a clear example of this. It is IETF STD track RFC and published
by 6man WG. So at this point any discussion on new ethertype for IPv6
should first start an effort to first obsolete all RFCs already approved in
this space.
Best,
R.
On Wed, Mar 27, 2024 at 7:24 AM Andrew Alston - IETF
<andrew-i...@liquid.tech> wrote:
Tom,
I believe a number of the differences are highlighted in
draft-ietf-6man-sids.
Though that does not go as far as to say they ipv6 and srv6 are not the
same thing – it does highlight that there are key deviations between srv6
and rfc4291 for example.
(I hit discuss on this when I was still an AD as seen here
https://datatracker.ietf.org/doc/draft-ietf-6man-sids/ballot/#draft-ietf-6man-sids_andrew-alston
because
as I said in the discuss I believe that the sids document was attempting to
have it both ways – and I don’t believe you can do that)
I also point out that if we do agree to diverge between srv6 and ipv6 –
this can be done without creating further complexity – and by allowing for
an **optional** ethertype as per
https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6/
this also would allow operators the choice to run srv6 in a way that makes
them comfortable or not – without complexity and actually **enhance** the
deployment of srv6 – because there are operators out there that will never
run srv6 while we continue to insist its ipv6 but violate the ipv6
standards – at the expense of security and other aspects.
I have never understood the vendor resistence to giving operators this
choice though – especially when it would actually help get their stuff
deployed in more networks potentially.
Andrew
Internal All Employees
From: Tom Herbert <t...@herbertland.com>
*Date: *Wednesday, 27 March 2024 at 02:52
*To: *Ron Bonica <rbon...@juniper.net>
*Cc: *Alexander Vainshtein <alexander.vainsht...@rbbn.com>,
spring@ietf.org <spring@ietf.org>, Andrew Alston - IETF
<andrew-i...@liquid.tech>, Robert Raszuk <rob...@raszuk.net>, Alvaro
Retana <aretana.i...@gmail.com>
*Subject: *Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica <rbon...@juniper.net> wrote:
Sasha,
At the moment when SRv6 diverges from IPv6, the two evolutionary
branches are identical. If SRv6 needs link locals, it can use them.
However, SRv6 now has the freedom to evolve in ways that IPv6 cannot.
Hi Ron,
That assumes that SRv6 is forked from IPv6? It might be nice for
someone to write up an I-D to really clarify the relationship between
SRv6 and IPv6.
Tom
Ron
Juniper Business Use Only
________________________________
From: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Sent: Tuesday, March 26, 2024 4:24 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: spring@ietf.org <spring@ietf.org>; Andrew Alston - IETF
<andrew-i...@liquid.tech>; Robert Raszuk <rob...@raszuk.net>; Tom Herbert
<t...@herbertland.com>; Alvaro Retana <aretana.i...@gmail.com>
Subject: Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
Ron,
I am not sure you can separate just the forwarding plane of SRv6 and
IPv6.
E.g., what would happen to all the IPv6 mechanisms that use link-local
IPv6 addresses?
Replicating these mechanisms does not make much sense to me.
My 2c,
Sasha
Get Outlook for Android
Juniper Business Use Only
________________________________
From: Ron Bonica <rbon...@juniper.net>
Sent: Tuesday, March 26, 2024 8:36:49 PM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Cc: spring@ietf.org <spring@ietf.org>; Andrew Alston - IETF
<andrew-i...@liquid.tech>; Robert Raszuk <rob...@raszuk.net>; Tom Herbert
<t...@herbertland.com>; Alvaro Retana <aretana.i...@gmail.com>
Subject: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
Sasha,
Good point. In my previous email, I didn't mean suggest that we should
divorce SRv6 from the entire suite of Internet protocols. I only meant that
we should divorce the SRv6 forwarding plane from the IPv6 forwarding plane.
BGP could continue to distribute SIDS exactly as is distributes MPLS
service labels today.
You bring up another good point about the parallel evolution of SRv6 and
IPv6. Yes, this is an engineering trade off. If you divorce SRv6 from IPv6,
and IPv6 develops a useful new feature, SRv6 might need to develop that
feature, too. However, if you bind SRv6 to IPv6, SRv6 must strictly adhere
to IPv6 standards, both now and in the future.
Which is more painful?
Ron
Juniper Business Use Only
________________________________
From: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Sent: Tuesday, March 26, 2024 1:56 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: spring@ietf.org <spring@ietf.org>; Andrew Alston - IETF
<andrew-i...@liquid.tech>; Robert Raszuk <rob...@raszuk.net>; Tom Herbert
<t...@herbertland.com>; Alvaro Retana <aretana.i...@gmail.com>
Subject: RE: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
Ron and all,
I respectfully disagree with the proposal of separation of SRv6 from the
existing IPv6.
IMHO and FWIW the most important added value of SRv6 is its ability to
provide BGP-based overlay services without any changes in the P routers as
described in Introduction of RFC 9252:
To provide SRv6 service with best-effort connectivity, the egress PE
signals an SRv6 Service SID with the BGP overlay service route. The ingress
PE encapsulates the payload in an outer IPv6 header where the destination
address is the SRv6 Service SID provided by the egress PE. The underlay
between the PEs only needs to support plain IPv6 forwarding [RFC8200].
To me this means that SRv6 services can benefit from incremental
deployment when new forwarding capabilities (implementation of SRv6
Endpoint Behaviors) would be initially available just in the relevant PEs
