From nobody Fri Feb 5 06:46:39 2021 Return-Path: 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 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 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, 5 Feb 2021 14:46:20 +0000 In-Reply-To: <727cfc33b0cb41acaeacc21a33c39d4d@huawei.com> Cc: Stewart Bryant , int-area , "flexip@ietf.org" , "draft-jia-flex-ip-address-structure@ietf.org" , "draft-jia-scenarios-flexible-address-structure@ietf.org" , "sarikaya2012@gmail.com" , Lin Han To: Jiayihao References: <727cfc33b0cb41acaeacc21a33c39d4d@huawei.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 14:46:34 -0000 --Apple-Mail=_B369B634-95A0-4FC1-B228-EA86842A1CFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 5 Feb 2021, at 12:06, Jiayihao wrote: >=20 > =20 > - 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
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 --Apple-Mail=_B369B634-95A0-4FC1-B228-EA86842A1CFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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



= --Apple-Mail=_B369B634-95A0-4FC1-B228-EA86842A1CFE--