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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> 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. 

Rgs,
R.
 

On Fri, Feb 28, 2020 at 12:37 AM Fernando Gont <fgont@xxxxxxxxxxxxxxx> 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: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux