Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 27/2/20 20:10, Robert Raszuk wrote: It does matter whether it happens at the IP source (origin host, tunnel ingress, etc.) or on the path of that header. It happens on tunnel ingress and tunnel egress nodes (egress = node listed in DA of the packet). That is obviously a lie. PSP

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 27/2/20 20:04, Robert Raszuk wrote: Joe, all, Just to clarify something Fernando purposely missed in his call for action: > All operations on the packets discussed in SPRING WG are happening NOT on the original (end to end) packet header. They are all defined to happen within new imposed

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 29/2/20 23:19, Joseph Touch wrote: On Feb 29, 2020, at 5:46 PM, Fernando Gont > wrote: I did look at the protocols involved here; the ingress does add headers but doesn’t appear to handle fragmentation. That’s a non-starter if you want your packets to

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

I raised the issue of the limitations imposed by RFC 7112 during the course of this saga – it’s on the list of things that were bluntly and shamelessly ignored without a single comment before this document mysteriously was declared to be moving forward out of last call on the basis of some

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 29, 2020, at 5:46 PM, Fernando Gont wrote: > >> I did look at the protocols involved here; the ingress does add headers but >> doesn’t appear to handle fragmentation. >> That’s a non-starter if you want your packets to traverse a network because >> people WILL hand you 1280-byte

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 28/2/20 22:55, Joseph Touch wrote: On Feb 28, 2020, at 12:18 AM, Robert Raszuk > wrote: >  I don’t care about what you WANT to do; I care whether it breaks what everyone else expects. I see many folks on this colorful thread simply forgot what networks are

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 28, 2020, at 12:18 AM, Robert Raszuk wrote: > > > I don’t care about what you WANT to do; I care whether it breaks what > > everyone else expects. > > I see many folks on this colorful thread simply forgot what networks are for. > To deliver packets in the most robust and

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> I don’t care about what you WANT to do; I care whether it breaks what everyone else expects. I see many folks on this colorful thread simply forgot what networks are for. To deliver packets in the most robust and resilient way to end user applications. As links and node fails there is

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 27, 2020, at 3:58 PM, Robert Raszuk wrote: > > > > What draft-ietf-spring-srv6-network-programming proposes is to remove a > > segment routing header (SRH) along the packet delivery path, before the > > packet arrives at the final destination. They call it PSP. > > That removal

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 27, 2020, at 3:54 PM, Mark Andrews wrote: > ... > Encapsulation doesn’t make the packet larger. Not strictly; it does make the unit of transfer larger. It’s the tunnel ingress’s job to adapt to that, e.g., using source fragmentation at the ingress. > It is no different to > talking

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On Thu, Feb 27, 2020 at 3:58 PM Robert Raszuk wrote: > > > > What draft-ietf-spring-srv6-network-programming proposes is to remove a > > segment routing header (SRH) along the packet delivery path, before the > > packet arrives at the final destination. They call it PSP. > > That removal as it

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Christian, Thanks for your response! In-line... On 27/2/20 21:43, Christian Huitema wrote: [] This may be a cynical point of view, but it matches what Bernard Aboba mentions in his description of "tussle space". Experience shows that if intermediaries gain benefits in messing around with

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Fernando, Your original question was "is IPv6 end to end". For me, the practical test of end to end is, can it be encrypted? A message is end-to-end if it can be sent from end point A to endpoint B using encryption services so that it cannot be modified in transit, only the intended destination

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On Thu, Feb 27, 2020, 4:27 PM Phillip Hallam-Baker wrote: > > > On Thu, Feb 27, 2020 at 5:44 PM Tom Herbert wrote: > >> >> >> On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker >> wrote: >> >>> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert wrote: >>> Fernando, I think we need to

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On Thu, Feb 27, 2020 at 5:44 PM Tom Herbert wrote: > > > On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker > wrote: > >> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert wrote: >> >>> Fernando, >>> >>> I think we need to be careful that IETF is labeled as a collection of >>> inflexible

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> What draft-ietf-spring-srv6-network-programming proposes is to remove a > segment routing header (SRH) along the packet delivery path, before the > packet arrives at the final destination. They call it PSP. That removal as it has been explained to you many times happens at the node which is

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On 28 Feb 2020, at 10:00, Tom Herbert wrote: > > On Thu, Feb 27, 2020 at 2:52 PM Joe Touch wrote: >> >> FWIW - there are separable issues here: >> >> - whether an IP header (or parts thereof) should be changed in transit >> >> AFAICT, the answer has always been yes, but limited to the

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Joe, What draft-ietf-spring-srv6-network-programming proposes is to remove a segment routing header (SRH) along the packet delivery path, before the packet arrives at the final destination. They call it PSP. Before, folks have also proposed to insert Extension Headers (EHs) while packets

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

EH isn't a HBH option or extension. Joe On 2020-02-27 15:06, Fernando Gont wrote: > On 27/2/20 19:52, Joe Touch wrote: > >> FWIW - there are separable issues here: >> >> - whether an IP header (or parts thereof) should be changed in transit >> >> AFAICT, the answer has always been yes,

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> Is something else being proposed? No. What you said below is exactly what is proposed. Thank you, r. On Fri, Feb 28, 2020 at 12:13 AM Joe Touch wrote: > On 2020-02-27 15:10, Robert Raszuk wrote: > > > > It does matter whether it happens at the IP source (origin host, tunnel > ingress,

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 2020-02-27 15:10, Robert Raszuk wrote: >> It does matter whether it happens at the IP source (origin host, tunnel >> ingress, etc.) or on the path of that header. > It happens on tunnel ingress and tunnel egress nodes (egress = node listed in > DA of the packet). Ingress can create

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> It does matter whether it happens at the IP source (origin host, tunnel ingress, etc.) or on the path of that header. It happens on tunnel ingress and tunnel egress nodes (egress = node listed in DA of the packet). ___ Int-area mailing list

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 27/2/20 19:52, Joe Touch wrote: FWIW - there are separable issues here: - whether an IP header (or parts thereof) should be changed in transit AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers.

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Hi, Robert, It doesn't matter on what IP header this occurs. It does matter whether it happens at the IP source (origin host, tunnel ingress, etc.) or on the path of that header. The former is allowed exactly because it is where source fragmentation can occur (in IPv6, and preferably the

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 2020-02-27 15:00, Tom Herbert wrote: > On Thu, Feb 27, 2020 at 2:52 PM Joe Touch wrote: > >> FWIW - there are separable issues here: >> >> - whether an IP header (or parts thereof) should be changed in transit >> >> AFAICT, the answer has always been yes, but limited to the hopcount/ttl

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Joe, all, Just to clarify something Fernando purposely missed in his call for action: All operations on the packets discussed in SPRING WG are happening NOT on the original (end to end) packet header. They are all defined to happen within new imposed outer encapsulated header (IPv6 in IPv6 to be

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On Thu, Feb 27, 2020 at 2:52 PM Joe Touch wrote: > > FWIW - there are separable issues here: > > - whether an IP header (or parts thereof) should be changed in transit > > AFAICT, the answer has always been yes, but limited to the hopcount/ttl in > the base header and hop-by-hop options in the

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 2020-02-27 14:50, Fernando Gont wrote: > ... > I'm not being purist. I'm just arguing that we probably can do better than > simply rubber-stamping any hacks a vendor with big pockets may bring up. That's a refreshing perspective. Refreshing, but confusing - given you promoted

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

FWIW - there are separable issues here: - whether an IP header (or parts thereof) should be changed in transit AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers. - whether an IP header length can

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Philip, On 27/2/20 19:26, Phillip Hallam-Baker wrote: On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert > wrote: Fernando, I think we need to be careful that IETF is labeled as a collection of inflexible architectural purists. We know that standards

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker wrote: > On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert wrote: > >> Fernando, >> >> I think we need to be careful that IETF is labeled as a collection of >> inflexible architectural purists. We know that standards conformance >> is voluntary and

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

This below note deserves to be printed and framed ! Spot on. On Thu, Feb 27, 2020 at 11:26 PM Phillip Hallam-Baker wrote: > On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert wrote: > >> Fernando, >> >> I think we need to be careful that IETF is labeled as a collection of >> inflexible

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert wrote: > Fernando, > > I think we need to be careful that IETF is labeled as a collection of > inflexible architectural purists. We know that standards conformance > is voluntary and we haven't seen the last time that someone, possibly > even a major

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Fernando, I think we need to be careful that IETF is labeled as a collection of inflexible architectural purists. We know that standards conformance is voluntary and we haven't seen the last time that someone, possibly even a major vendor, will circumvent the system for their own purposes. IMO

[Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Folks, If you haven't been following recent developments in the Spring WG, you may be surprised about some of the work that is being pursued (or was being pursued)- Such work has included proposing that some IPv6 routers insert and remove routing headers en-route to the final destination.