Re: What is necessity for SRH, and other EH, insertion/removal?

> - The destination node is not SRH-capable

In that case, how can the "destination" node be considered to be part of
the SR domain in any way? It won't even know that the outer header
is an outer header. As far as I can see, the "penultimate" node
is the exit node from the SR domain. So why is the "destination" node
even a thing? It's only meaningful in terms of the encapsulated
packet, not the encapsulating packet that includes the SRH.

Regards
   Brian Carpenter

On 08-Dec-19 06:49, Adrian Farrel wrote:
> Oh, I should have said...
> PSP, like PHP in MPLS, has an OAM cost associated with it.
> Adrian
> 
> -----Original Message-----
> From: Adrian Farrel <adrian@olddog.co.uk> 
> Sent: 07 December 2019 17:44
> To: 'Tom Herbert' <tom@herbertland.com>; '6man' <ipv6@ietf.org>
> Subject: RE: What is necessity for SRH, and other EH, insertion/removal?
> 
> Hi Tom,
> 
> Thanks for breaking the thread and focussing us back on technical questions.
> 
> I can see some small value in PSP just as there is in MPLS PHP. This arises
> in the combination of two circumstances:
> - The destination node is not SRH-capable
> - The source node and/or the node that determines the SR path is not aware
> that the destination is not SRH-capable
> In that case, the penultimate segment end point can know that its segment
> neighbour end point is not SRH-capable and can perform PSP.
> 
> Whether this is ever the case with a central controller is unclear.
> 
> I'm not sure that this is a big use case, although MPLS PHP has proven to
> have use cases as a form of "pop and go" especially when the next hop needs
> to process the payload as "native".
> 
> There may be other use cases, and I'd be keen to learn about them.
> 
> The principle of keep things simple yet extensible would suggest that if
> there are no substantial reasons to include a function it should be shelved
> until there is a use case, but that this should be done in a way that allows
> additions if necessary.
> 
> Cheers,
> Adrian
> 
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Tom Herbert
> Sent: 07 December 2019 17:17
> To: 6man <ipv6@ietf.org>
> Subject: What is necessity for SRH, and other EH, insertion/removal?
> 
> Pulling this out into a separate thread. Pertinent questions are:
> 
> Why is extension header insertion and removal at necessary?
> 
> Why isn't the proposed alternative of IPIP encapsulation sufficient?
> (where the encapsulating headers contain the extension headers that
> would otherwise be inserted)
> 
> Please note, I'm asking for the technical justification of the
> protocol design, saying that it's necessary because it's already being
> deployed isn't useful in this regard.
> 
> Tom
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 