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.
Ron
Juniper Business Use Only
________________________________
From: Alexander Vainshtein <[email protected]>
Sent: Tuesday, March 26, 2024 4:24 PM
To: Ron Bonica <[email protected]>
Cc: [email protected] <[email protected]>; Andrew Alston - IETF
<[email protected]>; Robert Raszuk <[email protected]>; Tom Herbert
<[email protected]>; Alvaro Retana <[email protected]>
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<https://urldefense.com/v3/__https://aka.ms/AAb9ysg__;!!NEt6yMaO-gk!HzsbTKniUOi5O0qugOI9QjUV-fzv06TpsmjMD8x0wPbs0BnNdIEeTDk9KclC7sptgzH_T9K9VovsC9Zd7PIJMn92sw$>
Juniper Business Use Only
________________________________
From: Ron Bonica <[email protected]>
Sent: Tuesday, March 26, 2024 8:36:49 PM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected] <[email protected]>; Andrew Alston - IETF
<[email protected]>; Robert Raszuk <[email protected]>; Tom Herbert
<[email protected]>; Alvaro Retana <[email protected]>
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 <[email protected]>
Sent: Tuesday, March 26, 2024 1:56 PM
To: Ron Bonica <[email protected]>
Cc: [email protected] <[email protected]>; Andrew Alston - IETF
<[email protected]>; Robert Raszuk <[email protected]>; Tom Herbert
<[email protected]>; Alvaro Retana <[email protected]>
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<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9252*name-introduction__;Iw!!NEt6yMaO-gk!DKf6ASDKU-trvFQgfyiW5r89q7qSEz8h0gn2C_-Q7he3Yg3qXRdjuRstXBvEo179nWAGf2K3AYzqtmlWoAcNI2nRxQ$>:
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<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8200__;!!NEt6yMaO-gk!DKf6ASDKU-trvFQgfyiW5r89q7qSEz8h0gn2C_-Q7he3Yg3qXRdjuRstXBvEo179nWAGf2K3AYzqtmlWoAfT4HTjlw$>].
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.
And best-effort BGP-based SRv6 services would scale up much better than
best-effort BGP-based services on top of a SR-MPLS underlay because:
* With SR-MPLS, the forwarding HW of the ingress PE would have to maintain
at least one dedicated egress encapsulation information element for the local
representation of each service instance in each egress PE of this service (the
label stack that delivers the packet to the relevant egress PE and the label
that identifies the relevant service in this egress PE)
* With SRv6, the forwarding HW of the ingress PE would have to maintain
only a dedicated egress encapsulation information element for each local
adjacency of this PE.
IMHO and FWIW the flex-algo approach extends the above scalability
considerations to BGP-based SRv6 services that require some kind of traffic
engineering.
All these advantages would be lost if SRv6 were separated from IPv6. Such
separation would require, at the very least:
* HW (or FW) upgrades that would identify received SRv6 packets based on
their new Ethertype – across the entire SRv6 network
* SW upgrades supporting new/modified routing protocols dedicated for SRv6
– also across the entire SRv6 network.
From my POV, SRv6 should try to minimize its deviations from the “normal” IPv6
(e.g., the differences in the address architecture), clearly define them and
avoid all attempts to violate the IPv6 rules that do not belong to the
“deviated” area.
My 2c,
Sasha
Juniper Business Use Only
From: spring <[email protected]> On Behalf Of Ron Bonica
Sent: Tuesday, March 26, 2024 7:14 PM
To: Tom Herbert <[email protected]>; Alvaro Retana <[email protected]>
Cc: [email protected]; Andrew Alston - IETF <[email protected]>; Robert
Raszuk <[email protected]>
Subject: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
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 <[email protected]<mailto:[email protected]>>
Sent: Monday, March 25, 2024 3:40 PM
To: Alvaro Retana <[email protected]<mailto:[email protected]>>
Cc: Robert Raszuk <[email protected]<mailto:[email protected]>>; Andrew Alston
- IETF <[email protected]<mailto:[email protected]>>; Ron Bonica
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>; Joel Halpern
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
> ([email protected]<mailto:[email protected]>) wrote:
>
> On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana
> <[email protected]<mailto:[email protected]>> 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
Disclaimer
This e-mail together with any attachments may contain information of Ribbon
Communications Inc. and its Affiliates that is confidential and/or proprietary
for the sole use of the intended recipient. Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately and then delete all copies, including any attachments.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
