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

I think the draft should state how limiting the number of options
translates into forwarding rate improvement in the fast path versus punt to
slow path.

Thanks

Gyan

On Sun, Dec 6, 2020 at 6:28 PM Ron Bonica <rbonica=
40juniper.net@dmarc.ietf.org> wrote:

> Fernando,
>
> You have a point. I think that we need two global limits:
>
> - number of options
> - two size of the HBH options header.
>
>                                        Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Fernando Gont <fernando@gont.com.ar>
> Sent: Saturday, December 5, 2020 1:26 AM
> To: Ron Bonica <rbonica@juniper.net>; Tom Herbert <tom@herbertland.com>;
> Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> Cc: Haoyu Song <haoyu.song@futurewei.com>; Bob Hinden <
> bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
> Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are
> processed
>
> [External Email. Be cautious of content]
>
>
> Hi, Ron,
>
> On 4/12/20 13:52, Ron Bonica wrote:
> > 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.
> >
> > 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
>
> Agreed on all of the above.
>
> My questions are:
>
> 1) Does the number of options really matter?
>
> 2) Regardless of your response to #1, aren't we overlooking what's
> probably the bigger elephant in the room, which is the overall length of
> the IPv6 header chain?
>
> Thanks,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD