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

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