IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 05 December 2020 20:03 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C4E3A0C4D for <ipv6@ietfa.amsl.com>; Sat, 5 Dec 2020 12:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H3pxx81ETYy for <ipv6@ietfa.amsl.com>; Sat, 5 Dec 2020 12:03:56 -0800 (PST)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624ED3A0C4E for <ipv6@ietf.org>; Sat, 5 Dec 2020 12:03:56 -0800 (PST)
Received: by mail-pg1-x531.google.com with SMTP id n10so5709586pgv.8 for <ipv6@ietf.org>; Sat, 05 Dec 2020 12:03:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qWrDJBqscNd4NPNCcIF/R/aM8PI+WV7E6r7uqyhIQk0=; b=Vye+Yo/66/DfmkGgEzDojp+5EBMF5aCbgaynk4A3RYSaWE7S4XWaaxD+J2+oCk23B+ I2CwXLXo1eEMIGJVWbZh0IhAVAfpcUa6o61lMshePEgL6bCJnAtqMpxPW2VJ8NTRy7Ex 9PiDs4C7YoZEqTBoVEMXnMnIL2p1S8HHg9WZy49FBWEaXB/ed9+xvp1xazFnycf/kesd hWnEZzvZph9adTqVlMx7YBBs/9hwASoBPIfFBCwUrXnFrR0HJd4abX+11Ka4X9wfSclc PphfhRhj6P9ERRX8M/0DonopFZAOrjiq0/pxBXUbrquZYEGwNOTH1gbx79iSNBuu0KnH TzaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qWrDJBqscNd4NPNCcIF/R/aM8PI+WV7E6r7uqyhIQk0=; b=NIRaYONFStZ1YCQr0tWlW6oJts2f+iMGZ+brg1vKXXY/dIkjLzRdxAq/slErH4sOov tBOmmOij8ORoc59U/l6eP4Q2UVYHMizmoMywshVPXY/GDxKH0liIegBSMO+5VMW8QlLx w+4up/DW3QP+X0jnFWQyRLqP3ZkgwpSqKi/KVVRO+COXSkVjxTYO0M1n8cRmIs2te5Aj JyRaTJVwBDjXZzn1E/R5UEYM7NVY/2UPm0bVRtHLYfu/ziBw3X6WJ88D4Rw/PvPPEXpR ir2NDnb51Jb/RhfRZz7hRX1FY4TGLS5jycvXLoBNM7XncxHycna1AuBJcaQBgngD0sLp v2xw==
X-Gm-Message-State: AOAM53246JnwyEOnrBrQidAx/kWsM4syz8qkemBBY5WoeSFOEiwtaoKH FYTIGFw/E/oTHH2vJXF4dDs=
X-Google-Smtp-Source: ABdhPJwFeYQDT/Jfr+a1506WNpFX08KE+KWfYEhXeYE5tq+jY5xUkd5lJ3uqHaXxGQyTWUWCGVs55w==
X-Received: by 2002:a63:506:: with SMTP id 6mr12504720pgf.307.1607198635686; Sat, 05 Dec 2020 12:03:55 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id u7sm8901021pfh.115.2020.12.05.12.03.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 12:03:54 -0800 (PST)
Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
To: Fernando Gont <fernando@gont.com.ar>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Tom Herbert <tom@herbertland.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Haoyu Song <haoyu.song@futurewei.com>, IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
References: <160703668657.9405.8891046478566468162@ietfa.amsl.com> <C573A554-9221-49C2-94AB-E552F1BA69E4@gmail.com> <8360e9919d46478cb471ccbafe923c7a@huawei.com> <DM6PR13MB27623A5EEB29F8294C3291C89AF10@DM6PR13MB2762.namprd13.prod.outlook.com> <a6c1a352-5f31-3c4b-9b75-50a64f82c925@erg.abdn.ac.uk> <CALx6S37zOXx5T=3wACpiif91dGnpykUEcpX9DhQ9cH2zD_jGFQ@mail.gmail.com> <DM6PR05MB6348F883A7D6076685001E90AEF10@DM6PR05MB6348.namprd05.prod.outlook.com> <753bd02e-4824-0067-9a42-9b2b3de629f9@gont.com.ar>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c6d23a78-de76-7f9a-0e6a-21526b662904@gmail.com>
Date: Sun, 06 Dec 2020 09:03:49 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <753bd02e-4824-0067-9a42-9b2b3de629f9@gont.com.ar>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PTeuD-2WkwPyYSTI3IXpKjUzetk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2020 20:03:58 -0000

On 05-Dec-20 19:25, Fernando Gont wrote:
> 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?

It's more than that. It's the *nature* of the header chain. It's a linked
list with different logical structures for each component of the chain.
It's something that by its nature can never be completely processed by
predefined ASICs or FPGAs; it cries out for an NPU. Not all routers have
NPUs.

It's well worth reading this:
https://datatracker.ietf.org/meeting/104/materials/slides-104-wgtlgo-forwarding-plane-realities-00

  Brian

v2.23.0 | Report a Bug | By Email