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

[Tom Herbert <[e-mail]>]

On Thu, Feb 27, 2020 at 3:58 PM Robert Raszuk <[e-mail]> 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 has been explained to you many times happens at the node which is explicitly listed as DA of the packet.
>
> >  Before, folks have also proposed to insert Extension Headers (EHs) while
> > packets are en-route to their intended destination, etc.
>
> That has been moved to a separate draft to move fwd with the rest of the work.
>
> Yes this is still useful for TI-LFA (as example).
>
> We need to ask ourselves what is more important ... quality of data plane for end users with 10s of ms of connectivity restoration times upon failure or keeping original IPv6 dogmas in place where folks never envisioned such needs or technologies to be invented.
>
Robert,

To me, security, robustness, and interoperability are more important
than performance for end users. We obviously want everything, and
IETF's part in this seems to be ensuring those sort of attributes in
standard protocols.

There's a lot of history here. If you go back through the 6man
archives, you'll find there was substantial technical discussion on
extension header insertion. There were specific concerns raised
particular concerns about the loss of attribution of packet contents.
The extension header proponents did not adequately address those
concerns. I don't believe there was ever consensus in 6man that
outright rejected the idea, but neither there wasn't much effort by
the proponents to establish consensus for the proposal. It was their
impetus to do that (frankly, publicly saying "regardless of any
discussion in IETF, the protocol is going to go forward" hurt the
cause). To say that the proponents have only been met only with dogma
would be a mischaracterization of what actually transpired.

Tom

> Rgs,
> R.
>
>
> On Fri, Feb 28, 2020 at 12:37 AM Fernando Gont <[e-mail]> wrote:
>>
>> 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 are en-route to their intended destination, etc.
>>
>> Thanks,
>> Fernando
>>
>>
>>
>>
>> On 27/2/20 20:21, Joe Touch wrote:
>> > 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, 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 change in transit
>> >>>
>> >>> I see no reason why it can't become smaller, but if it can become
>> >>> larger then PMTUD and PLPMTUD don't work.
>> >>
>> >> Besides AH (which obviously breaks), hosts typically try to validate
>> >> that the error messages they receive correspond to something they
>> >> actually sent.
>> >>
>> >> EH removal breaks that.
>>
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: [e-mail]
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>