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

+1 Warren

TTL meltdown, remember?

Cheers,
Jeff
On Dec 9, 2019, 8:14 AM -0800, Warren Kumari <warren@kumari.net>, wrote:
> On Sun, Dec 8, 2019 at 9:26 PM Ron Bonica
> <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> >
> > Hi Adrian,
> >
> > If the destination node can process Routing headers on the fast path, but does not recognize the SRH, it SHOULD:
> > - skip over the SRH, because Segments Left is equal to zero (as per RFC 8200)
> > - forward the packet at line speed
> >
> > If the destination node cannot process Routing headers on the fast path, it will:
> > - punt the packet to the slow path
> > - skip over the SRH, because Segments Left is equal to zero (as per RFC 8200)
> > - forward the packet, albeit slowly
> >
>
> Wait, what?
>
> The slow path is not "slow" in the sense of it takes its time figuring
> out what to do with the packets, it is "slow" in the sense that it is
> a much lower bandwidth. My slow path is already sufficiently busy
> doing things like BFD, ICMP, TTL expired, and, depending which slow
> path you are meaning, things like routing updates and SSH and
> management and things like that.
>
> I suspect what actually happens is:
> If the destination node cannot process Routing headers on the fast
> path, it will:
> - punt the packet to the slow path
> - hit the control plane policer
> - throw away the packet
>
> Expecting the slow path (PFE or RE or ...) to touch transit traffic
> simply won't work at any kind of scale.
>
> W
> [0]: it also takes longer to figure out what to do with the packets,
> but that is a secondary concern
>
> > Ron
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Adrian Farrel
> > Sent: Saturday, December 7, 2019 12:44 PM
> > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WzZKN3lbJ3IPeRv55moUERJbxW2t8ERi7n1WUHmRTQTT1SP56_ODQLQ5_06G_k7T$
> > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WzZKN3lbJ3IPeRv55moUERJbxW2t8ERi7n1WUHmRTQTT1SP56_ODQLQ5_06G_k7T$
> > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
> ---maf
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------