Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Robert Raszuk <[e-mail]>]

Andrew,

It is so cool IETF is about rough consensus ...

Dear SPRING chairs,

WGLC on this doc started Jan 22nd - Today we have March 27th - was the
result of the working group's last call announced and I missed it ? Looking
at the list it seems this draft got pretty overwhelming support already.
Why are we not progressing ? What is holding us ?

Many thx,
Robert





On Wed, Mar 27, 2024 at 10:36 AM Andrew Alston - IETF
<[e-mail]> wrote:

> 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 <[e-mail]>
> *Date: *Wednesday, 27 March 2024 at 12:28
> *To: *Andrew Alston - IETF <[e-mail]>
> *Cc: *Tom Herbert <[e-mail]>, Ron Bonica <[e-mail]>,
> Alexander Vainshtein <[e-mail]>, [e-mail] <
> [e-mail]>, Alvaro Retana <[e-mail]>
> *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
> <[e-mail]> 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 <[e-mail]>
> *Date: *Wednesday, 27 March 2024 at 02:52
> *To: *Ron Bonica <[e-mail]>
> *Cc: *Alexander Vainshtein <[e-mail]>,
> [e-mail] <[e-mail]>, Andrew Alston - IETF
> <[e-mail]>, Robert Raszuk <[e-mail]>, Alvaro
> Retana <[e-mail]>
> *Subject: *Re: [spring] Chair Review of
> draft-ietf-spring-srv6-srh-compression-11
>
> On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica <[e-mail]> 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 <[e-mail]>
> > Sent: Tuesday, March 26, 2024 4:24 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: [e-mail] <[e-mail]>; Andrew Alston - IETF
> <[e-mail]>; Robert Raszuk <[e-mail]>; Tom Herbert
> <[e-mail]>; Alvaro Retana <[e-mail]>
> > 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 <[e-mail]>
> > Sent: Tuesday, March 26, 2024 8:36:49 PM
> > To: Alexander Vainshtein <[e-mail]>
> > Cc: [e-mail] <[e-mail]>; Andrew Alston - IETF
> <[e-mail]>; Robert Raszuk <[e-mail]>; Tom Herbert
> <[e-mail]>; Alvaro Retana <[e-mail]>
> > 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 <[e-mail]>
> > Sent: Tuesday, March 26, 2024 1:56 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: [e-mail] <[e-mail]>; Andrew Alston - IETF
> <[e-mail]>; Robert Raszuk <[e-mail]>; Tom Herbert
> <[e-mail]>; Alvaro Retana <[e-mail]>
> > 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.
> >
> >
> >
> > 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 <[e-mail]> On Behalf Of Ron Bonica
> > Sent: Tuesday, March 26, 2024 7:14 PM
> > To: Tom Herbert <[e-mail]>; Alvaro Retana <
> [e-mail]>
> > Cc: [e-mail]; Andrew Alston - IETF <[e-mail]>;
> Robert Raszuk <[e-mail]>
> > 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 <[e-mail]>
> > Sent: Monday, March 25, 2024 3:40 PM
> > To: Alvaro Retana <[e-mail]>
> > Cc: Robert Raszuk <[e-mail]>; Andrew Alston - IETF
> <[e-mail]>; Ron Bonica <[e-mail]>;
> [e-mail] <[e-mail]>; Joel Halpern <[e-mail]>
> > 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 <[e-mail]>
> 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 ([e-mail])
> wrote:
> > >
> > > On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana <[e-mail]>
> 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.
> >
> >
>
>