Re: [Int-area] The small address use case in FlexIP

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

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F36C3A1207; Fri, 5 Feb 2021 06:46:27 -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 2obE4AmhVx6L; Fri, 5 Feb 2021 06:46:25 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 65F3D3A11EA; Fri, 5 Feb 2021 06:46:25 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id 190so6245404wmz.0; Fri, 05 Feb 2021 06:46:25 -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=HTmxIjM9eDD1AO0bbHdCt6tazotQzM7ght25QkLkTpo=; b=SEG9ORfNzl1Lf2QvRzt+NGLED+3GjX3I126+7TxkUa5QGbQbV6Lg0+0IPvUyjt64js UNLszW3jSSfxiyq3fJ45yc/kadRdfKGHXnZUt4JwSChSEMNZJy2rYcPWhO9zAqukR85m i1YvPE4yl0Y0sNlKJtZFvkSKeR6upUqonPi8IGBrUuwMi/Nw5XrtQcHt9cK0JXAUEFZO 2c7HTLqd4nCLiPva3aFRp5KAbILq5LLyvEgG4vhcItyHo2+FXoLi0Znchnm0Rrxvuv2c +QrAkTgmvU/53TjALsfJvo851h/q8flvKiLcxfvuaNLOeIMkYJXVGLk75NIwtyXVkwjp e/ig==
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=HTmxIjM9eDD1AO0bbHdCt6tazotQzM7ght25QkLkTpo=; b=jAFrWsqRGqk3c8JH+BImCRGArxXvAmX4T4rn4hHcJ9ahZsfkmXtV2dkNpUQTYCJMF2 f2PXooWgrqNAFhDkI1CSc29WhGHnq9OMlEmYlMoWrqBY3dmCEAJqPwA4g2gO+6I4VF6o XKFBciEKJU/iro7VVQeJOVlyKirKq1nKkpIhqdtmqbBStZ0M6fHBLQxJrvK4NTGStm0e F0hrgy8z9WiaHD6fr7+0ZM3AlQfzow0g8pKT6meHvCpAnVk2cBZKuRGB4pivTaU2hrYR tOtVuec9PekmUoD0cbhYLhVWdoF2wqbtGuCk4JjPvWnZPiLSbFcwGkojZaztQGgkrQZy r+pw==
X-Gm-Message-State: AOAM533tLRWWcNOrgNk3sJQ4i9zqDXoW8Rh5c38YWQvGxdquDDM2oi8a twUUFUma89Wq21Szk/+1OPA=
X-Google-Smtp-Source: ABdhPJxgy3Pat++bQmpXhZAy1U9a0V82POfTWGs/j+QHP9GAtLv0M05AWh4swrl/G4YyZ50yKJR8IQ==
X-Received: by 2002:a05:600c:22c8:: with SMTP id 8mr3840947wmg.11.1612536383654; Fri, 05 Feb 2021 06:46:23 -0800 (PST)
Received: from broadband.bt.com ([2a00:23c5:3395:c901:4405:51c9:cf5c:e431]) by smtp.gmail.com with ESMTPSA id d10sm12068042wrn.88.2021.02.05.06.46.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2021 06:46:23 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <58156BC9-6153-4C43-81B8-9E7F38AADE56@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B369B634-95A0-4FC1-B228-EA86842A1CFE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 05 Feb 2021 14:46:20 +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/int-area/_d9wXXXzG1ifEl9ICMO71TvjMr0>
Subject: Re: [Int-area] The small address use case in FlexIP
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2021 14:46:33 -0000


> On 5 Feb 2021, at 12:06, Jiayihao <jiayihao@huawei.com> wrote:
> 
>  
> - The header format could be described either in separate draft or be included in previous draft. The reason we have not provide a header format yet is that the address format itself is already a complex topic, so it's better for us to discuss the address first (as well as the problems and gaps), thus we can have a better understanding if a flexible address structure is a promising way to go.

Again I disagree, you cannot entirely divorce the discussions.

The problem has to be solved as a whole and decisions about the packet effect decisions about the address structure. For example if the new packet is much larger than IPv6  the case for short addresses becomes even weaker.

If I look at the address design that you have proposed this is dominated by the short address constraints. If short addresses (in the physical sense rather than a logical sense where they are the suffix of a larger address) turn out to be a trivial efficiency saving, then we would almost certainly use another address design.

For example <len><family><address> as used in ISO 8474 is an extremely extensible format at a cost of a two byte overhead, and would allow the address designers to proceed independently from the packet designers and develop new address types during the deployment lifetime of the protocol. This is unlike the approach in the drafts we are discussing where a lot of discussions are proposed up front and where the development of the address architecture is significantly constrained.

Best regards

Stewart