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 <andrew-i...@liquid.tech> 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 <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. > > > > > > > > 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 <spring-boun...@ietf.org> On Behalf Of Ron Bonica > > Sent: Tuesday, March 26, 2024 7:14 PM > > To: Tom Herbert <t...@herbertland.com>; Alvaro Retana < > aretana.i...@gmail.com> > > Cc: spring@ietf.org; Andrew Alston - IETF <andrew-i...@liquid.tech>; > Robert Raszuk <rob...@raszuk.net> > > 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 <t...@herbertland.com> > > Sent: Monday, March 25, 2024 3:40 PM > > To: Alvaro Retana <aretana.i...@gmail.com> > > Cc: Robert Raszuk <rob...@raszuk.net>; Andrew Alston - IETF > <andrew-i...@liquid.tech>; Ron Bonica <rbon...@juniper.net>; > 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] > > > > > > On Mon, Mar 25, 2024 at 12:31 PM Alvaro Retana <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) > wrote: > > > > > > On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana <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 > > > > > > > > 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
