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

[Stewart Bryant <[e-mail]>]

Any router that has interfaces of mixed type has to be able to re-write the datalink header. Changing the Ethertype is a trivial part of changing the Mac header and should therefore be considered a fundamental part of the IETF IP forwarding plane.

In reading this discussion I am reminded of very public statements made to other SDOs that if you want to diverge an IETF protocol from its standard definition you MUST either get the agreement of the WG that owns that protocol (in this case 6man) or get a new Ethertype and a new name for the protocol.

I think that those proposing that SRv6 and all its subvariants should get a new Ethertype are correct both from an IETF policy PoV and a pragmatic engineering PoV.

If we do not eat our own dog food here we will not be able to hold the line when other organisations propose incompatible changes to our protocols. As you can imagine if uncontrolled divergent changes happen that is unlikely to end well for the Internet.

Regards

Stewart

On 27 Mar 2024, at 1:05 pm, Andrew Alston - IETF <andrew-ietf=[e-mail]> wrote:



That still does not negate the point – if hardware is capable of stripping the mac address – and ethertype – and pushing such at the LER – I fail to see why you cannot push the mac addresses with a different ethertype.

 

Lets look at this:

 

Packet comes in unlabelled – we strip the mac addresses and the 0x0800 that identifies this as an Ipv4 packet.

We then – on egress – push mac addresses and a 0x8847 ethertype – and a label stack.

 

In the case of the srv6 stuff – Packet comes in – we strip the mac addresses and the 0x86DD type – on egress we push the mac addresses and 0xyyyy ethertype to denote as srv6.  Either way – perhaps my terminology was slightly off and I conceed that – but it does not negate the fact we are quite capable of pushing new ethertypes.

 

Andrew

 

 

Internal All Employees

From: Alexander Vainshtein <[e-mail]>
Date: Wednesday, 27 March 2024 at 15:55
To: Andrew Alston - IETF <[e-mail]>
Cc: Tom Herbert <[e-mail]>, Ron Bonica <[e-mail]>, [e-mail] <[e-mail]>, Alvaro Retana <[e-mail]>, Robert Raszuk <[e-mail]>
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew,

What you describe in is not an Ethertype re-write IMHO.

 

In your example the entire Layer 2 header (MAC addresses, VLAN tags and the Ethertype that identifies IPv4 or IPv6) are stripped after the packet is identified as an IP packet.

When the label stack is pushed onto the packet, a new Layer 2 header (MAC addresses, VLAN tags and the Ethertype that identifies MPLS with downstream-allocated labels is pushed on the packet.

 

Regards,

Sasha

 

 

Internal All Employees

From: Andrew Alston - IETF <[e-mail]>
Sent: Wednesday, March 27, 2024 2:34 PM
To: Alexander Vainshtein <[e-mail]>
Cc: Tom Herbert <[e-mail]>; Ron Bonica <[e-mail]>; [e-mail]; Alvaro Retana <[e-mail]>; Robert Raszuk <[e-mail]>
Subject: [EXTERNAL] Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

 

Errr

 

When unlabelled ipv4 traffic (ethertype 0x0800) gets pushed onto an LSP, the traffic is labelled – and the ethertype is switched to 0x8847 (MPLS). When the MPLS decap occurs – the ethertype is rewritten back to 0x0800.

 

Further more – when pushing VLAN tags – ethertype will move from 0x0800 to 0x8100 and back again when VLAN tags are stripped.  In both cases ethertypes are being rewritten.

 

Thanks

 

Andrew

 

 

 

Internal All Employees

From: Alexander Vainshtein <[e-mail]>
Date: Wednesday, 27 March 2024 at 15:30
To: Andrew Alston - IETF <[e-mail]>
Cc: Tom Herbert <[e-mail]>, Ron Bonica <[e-mail]>, [e-mail] <[e-mail]>, Alvaro Retana <[e-mail]>, Robert Raszuk <[e-mail]>
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew,

Can you please provide any details about re-write of MPLS Ethertype?  Why is it needed, what are the applications etc.

I am not aware of any such operations.

 

 

Regards,

Sasha

 

 

Internal All Employees

From: Andrew Alston - IETF <[e-mail]>
Sent: Wednesday, March 27, 2024 2:25 PM
To: Alexander Vainshtein <[e-mail]>; Robert Raszuk <[e-mail]>
Cc: Tom Herbert <[e-mail]>; Ron Bonica <[e-mail]>; [e-mail]; Alvaro Retana <[e-mail]>
Subject: [EXTERNAL] Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

 

Actually there are many reasons – which have been detailed in the ethertype document why various operators believe that this is insufficient.  It is still a fail open mechanism.

 

Irrespective of that – I do not believe that 6man-sids contradicts the ravioli draft – in fact I would argue they are complementary, and the implementation of both mechanisms would provide operators with more layers of security.  Considering that ravioli provides a mechanism that is opt-in for operators – and gives them a CHOICE to choose the level of the security, I fail to see the opposition here.

 

Adding an optional ethertype a.) Would not break things for peoplel who chose to run without it b.) Is an optional mechanism that would leave operators more comfortable should they want a fail closed mechanism c.) Is extremely simple to implement considering that ethertype rewrites are common place on almost all hardware (we already rewrite ethertypes for MPLS and for various other things)

 

So why fight against giving operators a choice that could end up enhancing deployment of a technology that been fought so hard for, for so many years?  That seems self defeatist to me.

 

Just my view point 😊

 

Andrew

 

 

 

Internal All Employees

From: Alexander Vainshtein <[e-mail]>
Date: Wednesday, 27 March 2024 at 15:18
To: Andrew Alston - IETF <[e-mail]>, Robert Raszuk <[e-mail]>
Cc: Tom Herbert <[e-mail]>, Ron Bonica <[e-mail]>, [e-mail] <[e-mail]>, Alvaro Retana <[e-mail]>
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew, Robert and all,

IMHO and FWIW Section 5 of the https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-06#section-5" rel="nofollow">6man-sid draft defines a simple security mechanism that can be easily deployed by the operators that have security concerns about SRv6 at the border of their network.

 

Regards,

Sasha

 

 

Internal All Employees

From: Andrew Alston - IETF <[e-mail]>
Sent: Wednesday, March 27, 2024 11:36 AM
To: Robert Raszuk <[e-mail]>
Cc: Tom Herbert <[e-mail]>; Ron Bonica <[e-mail]>; Alexander Vainshtein <[e-mail]>; [e-mail]; Alvaro Retana <[e-mail]>
Subject: [EXTERNAL] Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

 

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" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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.
>
>

_______________________________________________
spring mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spring