RE: Proposal for changing how IPv6 Hop-by-Hop Options are processed

[Ron Bonica <[e-mail]>]

Tom,

Signaling MSD is different from signaling the maximum number of options in an HBH header.

SR paths are confined to SR domains that have SR signaling capabilities. By contrast, IPv6 delivery paths can span many domains whose signaling capabilities are unpredictable.

                                       Ron



Juniper Business Use Only

-----Original Message-----
From: tom petch <[e-mail]> 
Sent: Monday, December 7, 2020 7:46 AM
To: Ron Bonica <[e-mail]>; Tom Herbert <[e-mail]>; Gorry Fairhurst <[e-mail]>
Cc: Haoyu Song <[e-mail]>; Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

[External Email. Be cautious of content]


From: Ron Bonica <[e-mail]>
Sent: 04 December 2020 17:30

Tom,

When you say MSD, do you mean the SPRING Maximum SID Depth? Or are you referring to Bob's MTU Option?

<tp>
Ron,

Apologies for the ambiguity.  I meant the SR usage as signalled by OSPF, BGP-LS and such like.  I should have remembered how many different meanings that the RFC-Editor finds for this abbreviation!

Tom Petch
                                                                            Ron


Juniper Business Use Only

-----Original Message-----
From: tom petch <[e-mail]>
Sent: Friday, December 4, 2020 12:03 PM
To: Ron Bonica <[e-mail]>; Tom Herbert <[e-mail]>; Gorry Fairhurst <[e-mail]>
Cc: Haoyu Song <[e-mail]>; Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

[External Email. Be cautious of content]


From: ipv6 <[e-mail]> on behalf of Ron Bonica <rbonica=[e-mail]>
Sent: 04 December 2020 16:52

Folks,

The following are a few things we can all agree on:

- The maximum length of an HBH Options header is 2,048  bytes.
- A source node can encode hundreds of options in 2,048 bytes.
- Given today's technology, it would be impractical to design an ASIC that can process hundreds of options.
- When an ASIC encounters a packet with more options than it can process, the best thing it can do is to drop the packet

Having established that hundreds of options are too many, we are left with the following questions:

- Should each node determine the maximum number of options that it can process, or should there be a global maximum?
- If there should be a global maximum, what should that maximum value be?

If we leave each node to determine the maximum number of options that it can process, source nodes will need to discover the maximum number of options that can be used on each path. This should remind us of PMTU Discovery. We have all seen that movie. It has  a very sad ending.

<tp>
On the other hand, I have been surprised at the enthusiasm for signalling MSD.  I do not know what the deployment is like but my sense is that it will become widespread so a different approach to PMTU Discovery might have succeeded, as might  a different approach here, one which does not open up scope for DoS attacks.

Tom Petch

If we can agree that each node should support at least a global maximum number of HBH options, we are faced with the following dilemma:

- If we pick a constant that is too small, we may not be able to support future use-cases
- If we pick a constant that is too large, low-cost processors may not be able to support it

I think that even low-cost processors can handle 2 or 3 options without blowing their processing budgets. Maybe we should consider a global maximum value somewhere between 1 and 4?

                                                                                               Ron



Juniper Business Use Only

-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Tom Herbert
Sent: Friday, December 4, 2020 10:55 AM
To: Gorry Fairhurst <[e-mail]>
Cc: Haoyu Song <[e-mail]>; IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

[External Email. Be cautious of content]


On Fri, Dec 4, 2020 at 2:34 AM Gorry Fairhurst <[e-mail]> wrote:
>
> I see lots of thoughts - all of which might help see us through 
> towards some conclusions.
>
> Just on (1). Whether one HBH option si enough, might depend on the 
> use-case.
>
Gorry,

-----------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Rd8Iqrir3dTnmgearoikghlTU2xxSWui2yCSEkmM856ZZ_DVSF8dkDKtbXMZIKL6$
--------------------------------------------------------------------