Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Eric C Rosen <erosen@juniper.net> Tue, 20 February 2018 19:43 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4352B12DA1A; Tue, 20 Feb 2018 11:43:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
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 w9aVocrWgoRA; Tue, 20 Feb 2018 11:43:22 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674631241F5; Tue, 20 Feb 2018 11:43:22 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1KJeRkR014447; Tue, 20 Feb 2018 11:43:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=PPS1017; bh=OMaMfCbwHtejYvdVEcF6mCqtcTdJ5avJrEfPxoAMskI=; b=phH6tabbKO/tGBk0vU6UnuC9ZCrGF8yOtcMTw1ztTeNAxmLlma1PG5CrZjJ3b1AWM1C1 IHzHGmZ3saR41Q82TKs+HLzgywieQ3gzt4vYJ5jI4Tszml1ehNaol1gww5PKiMKWir/l JXpxUlnI6bAEb3aekQ7Cy1YcomtzI9STmuC8GvhdUCJYuyqoUxGfBTJZjWMTsWavuLtg kRinXx6euOisJTeyyocb58K3bXCfllAEUzOo/9qVuVZpFL05nNqs915ZpP5acb7p4yhs cgOLgmCiS56NOgEIuALQTgBMo79puv5BmNEe7bnDoejiK5kdXSfXKudZ4oySQGXKY0vz eQ==
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0018.outbound.protection.outlook.com [207.46.163.18]) by mx0a-00273201.pphosted.com with ESMTP id 2g8sj8r265-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Feb 2018 11:43:21 -0800
Received: from [172.29.33.82] (66.129.241.11) by BY2PR05MB2295.namprd05.prod.outlook.com (10.166.112.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Tue, 20 Feb 2018 19:43:14 +0000
To: arkadiy.gulko@thomsonreuters.com, akatlas@gmail.com, bier@ietf.org
Cc: isis-wg@ietf.org
References: <CAG4d1remdUKutEdc2DU6Gaan3z63CAZVo1D-L0GXg_=eHJxffw@mail.gmail.com> <9778B23E32FB2745BEA3BE037F185DC4A5BA61A3@BLREML503-MBX.china.huawei.com> <CAG4d1rc8=2gnEj4vTjjAja5SPfezBT+hBKRg219uLgndvA78Kg@mail.gmail.com> <CA+wi2hPoTA0u2rx0f5eoBsoOAH+m1uN0ggr=P7sSYFcX=1qQxw@mail.gmail.com> <CAG4d1rf_mphexVqMv20HQbd=px5koH5c_+VW_5TTfgjWq4EtSA@mail.gmail.com> <B94D11DC-F46A-4F8C-873F-6F4A21BC4071@thomsonreuters.com>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <14dca8e9-9afd-b5ff-c753-3554b911d753@juniper.net>
Date: Tue, 20 Feb 2018 14:43:01 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <B94D11DC-F46A-4F8C-873F-6F4A21BC4071@thomsonreuters.com>
Content-Type: multipart/alternative; boundary="------------0269CDB0E18277A57612A68B"
Content-Language: en-US
X-Originating-IP: [66.129.241.11]
X-ClientProxiedBy: HE1PR09CA0086.eurprd09.prod.outlook.com (10.174.50.158) To BY2PR05MB2295.namprd05.prod.outlook.com (10.166.112.145)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 78c3830a-1140-4123-9fca-08d5789a30ab
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:BY2PR05MB2295;
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2295; 3:3hYqDoQWLQbU6/HrjVkOlHT/K2Zp9rDoJ6tKdTZ3byj4IvGxIBleDAqNqGXe9U3qjGZuo5DYOgvsDiCIH7kqWlbK4CF9DRN6J1DOaOBYEySK5f13tRXO0AqjBLEES2y2sxs6w6CBJn+SQr3AVrEBlsuMnfdcKigVdvdL1rH3hAQiVLGR8GTYGc3x6vADgVYgtcq2zFl7izeqJDNUf4ueZhmPi3YU/aitdURrUvHMgWX6rKAbzditbQqnPfn9LNm3; 25:4wMHjajgaZjDfOIGTH8bTpHcqECMM5VEzBIDapXqjB8j7quWyIGfySnYRoKzZlf4LJkdjQZRKdr8n56n7hvCvsA8+GuClBHyipqkYin1A6TOnuiTkZmBWjtcTHtdlU0AePiHQQXP15Hc9X06pJGunvLO09kQk+t63MYvWe1IkvERjlHd6CrvMUFTcoWuEpkVK2McndKzcvif12xkDWid4fBOiOF4c/86J0sAJg2ClKrfM3oY2JnzwLn0p7eQbUrJaQrgxmUnZorhPKoB9D+4GX29Y6vPqS1ntCDn8b+kpLW96YM7x7eryvx+JIYIiaA9GH8IL7cJ4V4VOUWF9Mvdlw==; 31:BXtXOL+vj+3qq59OJWjh8MlPliBLLajjqb71E1N4XW+E10sxkIv5dWjiY5u9PsdEX5fuOom2JjGLRZJAZGgHSGuRFIEcxSDK73Npsun+4EcWZBYKeGs+kXm3deQfsNf3jBp/0jlKB1Bnvq6lf+7v01+CGQ+jSwWhL6voS2NHeWos9Wx4kCbPlF+k1SBZR7lKTs/uiXBrDqx4+PSa676mHmLUzYz8QMsPUOHQ+JNqCB8=
X-MS-TrafficTypeDiagnostic: BY2PR05MB2295:
X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2295; 20:ieh0pL3shwiPxEJdfEn8JT7ZziGy4Xq7Xmz1hedYfL5iyfDcbQvSrcG4gC0K1LHm7zYXBv1s+RSklZ4SRpz5h/esbk+vdx5y9I7abX+1BrRXWSeW5RFQ2eLVwJDDCtP//2Te3Wt/YDSlEGI0hPNAIvqZsrSf36jMu9UEfATVhGg2pR+870YL4VdMqa5jZnhyBCz91CBAer/SMpFNPbEUoUCjbA46vCzqfWmMbdpmfmQJB6nPR1rJnvD78xVx5Lv4tHRzIrPdJ6/6suJ+FedwIXxGhKqwj0XGNPXnWIA1vbIe5INJfucojmE4eW7pnSR7im+R4Dnb8+f76uPtDR/p8SNjl5S9U9GlbL80mgntLmP8Ac2wJ9e7p0GOclxX5KCbjlcSfcfBqi5Cp5cPf4gKHGuZUYpMn5BUn7WHwYCG1sEdrFggIJ/q1qUJU9VNBdIufENLaiMonFI9hKNW6cMFM6nlN323H+XKDxXlmJvOY4Xrq7UmeEzbgtwlzeR8HyTiBQ5W/vabLoDAGRcmgC2f7vgd4KucsqgrqhHXxA7h0d/fFJFk7ApRNgFgwMa8LAma4rJygVXE9b4ugo2JCQAKqBnHcnhP2BYhv/KKeT7rRQQ=; 4:oNGXzPCJJrccUzn+tl/cTM5xijAbdo1WkZjLxxbJnSl3s+L/rV7zJNF6q8npEQjBI+pYi1T+8bSdJZyMbfPpbSNPEJ6tE8HScjtyMXRrHu9uyPz/MRq8CRpyeNv+qzfXtY8X8cDbeXDA5QN72OanqxoXT4q5ajXHwXvBawA9R8shq3AA3WAlAgiB1AAycYZiwAYvsku1HfuHERNCfpL7AXTgD6Ei3ocgVbflFFSKiqNtJT+mJJx+RbNnX8cq6M+wn+MHHhw/1PtxPGaIYBPFdoF67nkyvQlPcfMkhOoojFaTc23Ksv/bSgmRRXc8gOsn
X-Microsoft-Antispam-PRVS: <BY2PR05MB22957056601133C091734A3DD4CF0@BY2PR05MB2295.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(206530554354550);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(944501161)(3002001)(10201501046)(6055026)(6041288)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BY2PR05MB2295; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2295;
X-Forefront-PRVS: 05891FB07F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6049001)(366004)(39380400002)(396003)(376002)(346002)(39860400002)(189003)(199004)(6666003)(33964004)(66066001)(8656006)(65826007)(65806001)(65956001)(7736002)(37036004)(2906002)(105586002)(97736004)(8676002)(81166006)(31696002)(386003)(53546011)(8936002)(86362001)(84326002)(68736007)(2950100002)(77096007)(26005)(229853002)(81156014)(478600001)(52116002)(76176011)(31686004)(106356001)(64126003)(36756003)(561944003)(236005)(54896002)(5660300001)(58126008)(93886005)(16576012)(16586007)(39060400002)(6246003)(25786009)(6486002)(316002)(90366009)(3260700006)(53936002)(4326008)(16526019)(3846002)(6116002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2295; H:[172.29.33.82]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2295; 23:bh2RtjFZFIU+oZYYxIJf+sn3906bhiP+fHghpwg4mdkZ7Y+dGhD3wsfhAXAKADpAkX8+RZRFrb+ovI2eaAZ7UC1YDtYkSRoOvY4+4GQRO5qT9b8LKolxh7uLx0iBL+LXfkiSRifQaviNFeTw7qHfQb4VVfxSCsrRLKctNdsSeY2Gon1HjE6eGb9WmKGF4mrTHYIb58sO+CMKKWOxcse8Py8+7S/XvkDwdy6FMtxzJmH9ZhBhXUr1kj2QiLI3T6kNhTIER8c/Bhx4OoamsSAR7lxv0wjUpJ1aZg5xcOHqkSKWsUwAPrjn/zilNO41RcE8mET9tPADzYZItND3k4GEj58XCr4zxOiyrQeuLuS93o6dcCRkTxh9WfjXYXp6e8pOEmyuvmZpQrNc6Jt6iKL+u9pu0Nb5H25lWWG5sQzfKSQ28XJgMifxzAkebK5rimuVILS/+mzGtqdcGzB0CWcGL8EM2n9dexCOvG3JGcZ1O5ph57Vlfz8TQLy5wuAOrC/G8mlFIX2G+84MdIjEpIqj6l0qrLxnp8fGLGm+lOelFXKS+MouWlU74ANSJhdcAGPwTzgVF1ETVlEkHwfZKPydFh180ORaLoavDhBBpuFxn7iRXoSufQvjxkfeJEtcQPLcl8+Aw6dTENfclw32vyO2p1gv7qVXqKnjhf1PVtYWhE+xBDjgw46Tvru4oSi/NBWnA+y2Efm9wnYFe+cvGccMpTl8/52p37F4aQiI6PpHSWyWV+CfN74LbDXK/C1O2YKEKp9su8CTBHeQfZt3Hioc1votRq/T39TrwnWtdzdIYFn6KEbn7cRyb4cNl/4TbT0Ln1TlA3NerOLVjSqBXFz+jh5aZuvDwhVbMfMU+wzGZ8F6oETf543BHbEuKJtT1UqZ1cPvqB7yZBryfElWCZr8ZL5Hbi9+hFt+gjAkW8IzprSZsfQX2peXYbu0Ghqc5fmSsKVRmISx0z+Z/iQFvPG6Zz/SUNd7qO3AAylgduO4U0+SKmqHBZVlBBE/7Q90GtOYzen2u/Lzc1m6sE9/CbpjKjmXnnbtC/vDpDDvBuFkxDTwNxxFA6bXHrBH5vVRLTx3H5xmjXIf6HjKgIuTSt2u+qSrSjAZNzi4reBpFuG1UcIib93rSpV4FKdR9FTKtmXSLtiyoHxLIuRVLThr/03e1iPrQ0efGRFHjCPu7WNrVouP8WnZMYO372y5pXMpI6rPpRhc+wfYv17RhIRyOMG7JK1byovRDN2wfgyjPxcWwoEkmLXo81T1WajitDj7sFcZKZh3/QCILpxmQ64KZf7dm9CQAhx5ZPvUVXUUKHZgigLzELNL9vDPNWRRlJp8XU25iPBZq56e1t8zVno7PPBOw4uYtFWd/QCikmKiWB9Rc37DX4XOCWHWbWtuB0KXMTjZBtBc8/3jDPKXMiDRc+PEEarTVI24kcP7mk0u0GmvfrVOvbbcBdNVf5GJiFMluTaZAJIW92jQqXU/iGlevF3apS13QGYM71sLaflnyyCwBcU=
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2295; 6:Qxi3EHMUKBF0vNeYbRf0wDdxJmyng+DFVOkxJ4nYyxXjaGMrOyTTZM5tMPikLw6LsaCaLa2PMP2aOCO0OWkVQXO1ROX/0Wkar6wLaHRtpfCNYwOIO4NCL/zUzc4kEDvdRwFM94NdS7GAlgyBhfZpJVgjD2TtAA7TgV73DLXJuchwYb7GEptJG4UJdQ5whLS6ntEiEWjCvlQr0edfoveXzbyf9kj2PBZypwriOMrK/f+a+EiJXQPhbsrOc4CpkcWA184n1cU+cl7Vj+QJR30FuvrnDsR0IA6UTQ0odbcuRpShEGrQy27pXvi4/ZRALL03BqJ6byk7UluXPVj4A8uDppVjktVDmYfbk+WH48jPd9A=; 5:z62mt58U8ByGBNjeVhOr2Ta/Jlz2ODWh8Qz+zzOVC3a2a2jFNaNGRAjAbqiQJeC4CPFisFUHJZqjazH4RtS2n++vkONLqDbNyP7CmuA+KaWAhtUb2q2eZAjMbD9J11NLNB9+cUlY9T4QXVAcCMNS35JgmQTeL+74AdfbupWDKt4=; 24:AweImhl0NXI3FhQTqMKxLft2F7aMxcR92lGC6raS/G6LdXy9nJiAuZDvXnoFwXDYDzd+ezun6aHn53v7TRd1zFSKWu9xAz4UU9LA/byIt5U=; 7:SRM7ZfHFS7X8Ji0e3bVq7ZQytPTgkqyeIT+gocBAr2clObDwotOpTNaxKma7VhLTbrN0GkBGDDYd1Zks41piHsDQv7xYyrRJTA8I4VD3L3+nuAshE66CBedwQGiWXyzeBfCnfxhW8p364rqesaKCjOoqWk/C33gVQEfgCG2690nwUXg+B1zWJP+j34vwpZ9eNAvlwY3ji/Ic0pE2ECRc+22MvmC1ZcxziSC+my/kxVnu8jZgg3P7mm/zYO23z7sC
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2018 19:43:14.3079 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 78c3830a-1140-4123-9fca-08d5789a30ab
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2295
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-20_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802200236
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/COgmW4ZQudLW03aO5yTdSWQfiKk>
Subject: Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Feb 2018 19:43:24 -0000

On 2/20/2018 12:56 PM, arkadiy.gulko@thomsonreuters.com wrote:
>
> I personally like Eric proposed option -two independed 1Byte filed one 
> for IGP Algo and another one for BUAM : the "BIER Underlay Algorithm 
> Modifier" registry.  The way the underlay paths are computed for a 
> given BIER sub-domain is determined by the pair of codepoints: <IGP 
> Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.
>
> Not sure why it is not in a list of proposed options since I saw a lot 
> of support for it on the WG.
>
> It sort of Option-B but allow more independence between BAR(BUAM) from 
> IGP Algo
>

I'm also wondering what's wrong with this proposal as a way of moving 
forward.  The only real change I'd make to it is that the first 
one-octet field would either be a codepoint from the IGP Algorithms 
registry or a Flex-Algo codepoint.  Since the former are in the range 
1-127 and the latter in the range 128-254, no ambiguity is possible.

With regard to the question of why it makes sense to use an IGP 
Algorithms codepoint, I think the argument is the following.  Per the 
architecture, BIER relies on a routing underlay to tell it the next hop 
for a given BFER.  Per the architecture, the routing underlay may use 
the exact same decision procedure applied to the exact same topology as 
can be applied for unicast routing.  One way of identifying a unicast 
routing decision procedure  is with codepoints from the IGP Algorithms 
registry and/or Flex-Algo codepoints.  Thus it makes sense for the IGP 
signaling to use these codepoints as a way of providing the BIER layer 
information about the routing underlay.

With regard to the question of why it makes sense to have a second 
one-octet BIER-specific field, I think the argument is the following.  
The architecture does not require BIER to use a routing underlay that 
applies a decision procedure that is useful for or even applicable to 
unicast packets.   In such a case, there might not be a way to identify 
the decision procedure with a codepoint from the IGP Algorithms registry 
or even with a Flex-Algo codepoint.   So it's useful to have a codepoint 
that does not have to hold values from the IGP Algorithms registry and 
does not need to have Flex-Algo codepoints.

There is also some worry that there may in the future be a lot of 
arguments about populating IGP Algorithms registry, and it would be good 
to have a way to extend BIER by allocating codepoints that help identify 
the routing underlay, but that might not be useful for unicast applications.

To some extent, this is all a tempest in a teapot, because the 
extensible TLV structure can be used, as Alia points out, to work around 
any codepoint problems.  Of course, continually adding TLVs to modify 
the interpretation of other TLVs can becomes a problem in itself.

I think the most compelling argument for adding the second codepoint 
field is that it provide more options for exploring the issues that 
might arise as production deployments begin.

I don't believe that any field containing a codepoint should ever be 
created without an association to a registry.  That makes squatting and 
future codepoint clash inevitable.
Thus I think the current documents, which have a one-octet field that is 
not associated with a registry at all, are not really acceptable.  So I 
don't see any way to move forward now other than with a compromise like 
the one I suggested.  This is not exactly Alia's option B, because the 
second codepoint is not properly thought of as a sub-type of the other.