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

[Ron Bonica <[e-mail]>]

Good point. Worse than slow. Low bandwidth.

                                   Ron



Juniper Business Use Only

-----Original Message-----
From: Warren Kumari <[e-mail]> 
Sent: Monday, December 9, 2019 11:14 AM
To: Ron Bonica <[e-mail]>
Cc: [e-mail]; Tom Herbert <[e-mail]>; 6man <[e-mail]>
Subject: Re: What is necessity for SRH, and other EH, insertion/removal?

On Sun, Dec 8, 2019 at 9:26 PM Ron Bonica <rbonica=[e-mail]> 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 <[e-mail]> On Behalf Of Adrian Farrel
> Sent: Saturday, December 7, 2019 12:44 PM
> To: 'Tom Herbert' <[e-mail]>; '6man' <[e-mail]>
> 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 <[e-mail]> On Behalf Of Tom Herbert
> Sent: 07 December 2019 17:17
> To: 6man <[e-mail]>
> 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
> [e-mail]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!WzZKN3lbJ3IPeRv55moUERJbxW2t8ERi7n1WUHmRTQTT1SP56_ODQ
> LQ5_06G_k7T$
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!WzZKN3lbJ3IPeRv55moUERJbxW2t8ERi7n1WUHmRTQTT1SP56_ODQ
> LQ5_06G_k7T$
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!T9-gMf5yF_eHZ_kaa7MQrUDQvc9H0DBQ-LLbs9_TZO5xex3T0taI5
> WEiT-oTITeA$
> --------------------------------------------------------------------



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