Re: [Flexip] The small address use case in FlexIP

Stewart Bryant <stewart.bryant@gmail.com> Fri, 05 February 2021 14:58 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: flexip@ietfa.amsl.com
Delivered-To: flexip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA36B3A1213; Fri, 5 Feb 2021 06:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 rzd4azr1COSz; Fri, 5 Feb 2021 06:58:45 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 9456C3A1221; Fri, 5 Feb 2021 06:58:45 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id l12so6274919wmq.2; Fri, 05 Feb 2021 06:58:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hCa1OqCFwa/Nl30dTiTMusqwDLxkIyw3iEWPP9gotGA=; b=ORawHo/FNvcIQFC4V4CxHC0VLFLXyZuV6EvnK5705bwc3iz3DCeobpN5kSmQ1AMrRX htQXlRhVsj4PN46yxuSHXV3L9FSnYYT66++a+v79ZHKyismGgv9WCKwKvOwSsRuaW6P4 SniJENb3npR96b/WQC09UnkmwovlK0Kwt0j6RyzYTdQ6t+sjit60ea5LuZYi0WHxOJNd qFqA8OLLPtRk7Ha0hU3EzagTiuc1iFUD9B6a8snGqV4ROmHrfKWrprb7+j0o9Auen2EY TrWE2XhaE68/wMwFuum+6/UvFSOT9eF2TYPCBXjNGBj5GsVyawTcSuEt9anyqKLImeKB arzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hCa1OqCFwa/Nl30dTiTMusqwDLxkIyw3iEWPP9gotGA=; b=MMb7bBi8g1l89u54uoWJQGq2Yc1SaNJLLDd0zDYqcKhGUPvzEiFZaZDLH9bEfB/2+8 i73s5vek6HhlRUVQ5wN8RWvFQbEHAvxnAC7vnbgRDRI1SGTQ9JS4v0NQ1lD2lGAfmHe+ 5YPyWrHetXfCXlXMVZvfE8xoe+9EXZfGZyu89LopF+9/6JLj5XhcmxfNy4oC+DwyycAM UgpNCxHSyxSKAXe2fgNcQNWKUqcy6mexCEJbXECxCAY9JXELiJDrx69rF2C2hnAX/kg5 i8I11Ydw1dSkpI0DMxwgx/lf5g8gABNmaAqNfn+h1xbkLcyYbCPe4r4lsuDyCKHqmPLO Xuvg==
X-Gm-Message-State: AOAM532VE4ntoL0mjPIBnUucFjEl7WB9ZWjtzHF52PABjyPnGaBVWS+N HsrO2CnOOsD/fVPd//N8AVc=
X-Google-Smtp-Source: ABdhPJynMCwRrXeCppI5BGTMifCtxtbrGgVHK9UEbwP+IPbxbv7JLhUbzSCpZdpi7+9uLXwnIqZAsQ==
X-Received: by 2002:a1c:8083:: with SMTP id b125mr3927349wmd.188.1612537124073; Fri, 05 Feb 2021 06:58:44 -0800 (PST)
Received: from broadband.bt.com ([2a00:23c5:3395:c901:4405:51c9:cf5c:e431]) by smtp.gmail.com with ESMTPSA id j14sm14452612wrd.36.2021.02.05.06.58.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2021 06:58:43 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <B697AF2A-8B98-4CB8-ACDC-688058276F43@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B40EF36E-B1A2-4BCE-81B0-5DC71B9798C0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 05 Feb 2021 14:58:42 +0000
In-Reply-To: <727cfc33b0cb41acaeacc21a33c39d4d@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, int-area <int-area@ietf.org>, "flexip@ietf.org" <flexip@ietf.org>, "draft-jia-flex-ip-address-structure@ietf.org" <draft-jia-flex-ip-address-structure@ietf.org>, "draft-jia-scenarios-flexible-address-structure@ietf.org" <draft-jia-scenarios-flexible-address-structure@ietf.org>, "sarikaya2012@gmail.com" <sarikaya2012@gmail.com>, Lin Han <lin.han@futurewei.com>
To: Jiayihao <jiayihao@huawei.com>
References: <727cfc33b0cb41acaeacc21a33c39d4d@huawei.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/flexip/eiMnJWel2nFVWNpgIN-G3Ui-tTY>
Subject: Re: [Flexip] The small address use case in FlexIP
X-BeenThere: flexip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Flexible Internet addressing and Flexible routing <flexip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/flexip>, <mailto:flexip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/flexip/>
List-Post: <mailto:flexip@ietf.org>
List-Help: <mailto:flexip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/flexip>, <mailto:flexip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2021 14:58:50 -0000


> On 5 Feb 2021, at 12:06, Jiayihao <jiayihao@huawei.com> wrote:
> 
> - Indeed, the network scale of limited domain is supposed to be less that IPv6, but it doesn't mean the address space should be strictly less than 128-bit. If the space of the address is abundant enough, the public key could be embedded without truncation (compare to CGA in IPv6) for certain security purpose.

Interesting, what are the advantages in adding the signature of the address in the address as opposed to carrying it in a different field?

The disadvantage is that you bind the address to the signature algorithm which you would not want to do since you would expect to change the signature algorithm during the lifetime of the protocol.

Also would you really want to feed the signature into the longest match engine? Of course you could and there are some advantages in that you look up both the address and it signature, but I think you loose longest match capability and you significantly increase the size of the TCAM or other FIB design memory, and that memory is very expensive as it determines the line rate of the forwarder.

So this points back to the need for a holistic discussion of what we are trying to achieve, the extent to which modifying existing protocols satisfies that need, and whether (given the presupposed need for a gateway) we should be looking for a single protocol, a family of protocols, or an adaptable protocol.

I don’t think we can design the addressing system in the absence of a discussion on those points.

Best regards

Stewart