[Bier] Re: Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 23 May 2024 14:08 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF24C1C3D4C; Thu, 23 May 2024 07:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level:
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b="e6bTkraP"; dkim=pass (1024-bit key) header.d=juniper.net header.b="NQfLBt8C"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2WaWLjB18qw; Thu, 23 May 2024 07:08:34 -0700 (PDT)
Received: from mx0b-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 BB64AC1C3D73; Thu, 23 May 2024 07:08:33 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 44N4VPTA009122; Thu, 23 May 2024 07:08:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=PPS1017; bh=hrVItWP/f2y8KQXtUhY/zAaH67 Emz92YCY6u3enTdFA=; b=e6bTkraPWtagQeLT9FsVK5O1zHM1zz8/8cqd7L6kMp vA6TopvVr1XZbsWZuy6viXwZm8yK2IeHyaIQeWXjSDwrDVc5++8t3dRbsS0lLtr+ a26HpCrZrmDoMQld2JumK28g9UOA6tdowBArbkJVD8fDLFTMxiqJ+ScgD+gNZ2z3 gVW8YJX3pUtvxv45AiJTW/kuKrdyZrpX889ryodjOb4iiVYFUP49ZnfS7pO6KmA3 Bqsnj7SGWymS75CSdffEYjYjXd2EBxrQWiWZjIpZlaF2zr1cok+/9bDjxWbRymg0 Rg+h5iUJH7zzu8JCP8ta3ENlvb/hzj/vECCMoAZLQeAA==
Received: from sj2pr03cu001.outbound.protection.outlook.com (mail-westusazlp17010001.outbound.protection.outlook.com [40.93.1.1]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3y9xuk8vqg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 May 2024 07:08:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fYxt2jxf/2eySs7f0Bf307lvxvELeMDzEUdPIZ2qrkvq/wAsO+ryyR6cOi/8PdiCK+RcFjCfn6pG4iLZCmxvdhaLvx0Aee+FknMtN4Sh/bmvLkSxo+hcxKDv43eDvDHeNS+3zj1SODBaX0UFYLb/wqyv0SDToTqp0PXIuVlpvEYRptHOu56D+k9HLtH3KhPA3pDWlS10RA35OpARWs8OJ6E/U6Dbv58x1YxICo2EwK45G3wC/Q4INFYehQC/y9NUbogPxBVqXnjpSN3aNJ9mA2BsR/DnXJm4Hi4afyBGVCozWKcLK/mjYXng0ZVUFqIyLGlThmw02mMwNWKA6/pS6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hrVItWP/f2y8KQXtUhY/zAaH67Emz92YCY6u3enTdFA=; b=WBJDfKxTsu506/HybBUyYS+09sk8JdWzRx/l7aaXC31XUMxJPCFANuUAMl+vb0d37M7I7Ew12hGz2oykqGm0lTIYiDBrgS5obdIwqI1yhOShn88jtE2HxQHsp0QKjsA+iDMWSXegtbh2yx7lBW8B9REYOtytNgegs6eFj2mvGCsMaNg9aF0H/y4hBP14qTSD8zKYehqD9ZisTeHVbIkDh6HxYn3RaISZoxR2dAn5+JRjQ6exYQ1F6gd7j7G5FwW12QVPP/Ahboa9X7S53AakeLE8vYmlJ8ocdswus6CePTEGcMwC+bjNBVJtykxexowViNHlJvAPOm9tmLkS+y+Grg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hrVItWP/f2y8KQXtUhY/zAaH67Emz92YCY6u3enTdFA=; b=NQfLBt8CJSFHInLY5ge85UnMywOPjP6wPjYK7NgX9R5GJSlSahryATXr7Iw2vH8rP4E7YbdUFFb8FokXboBBikydL8/ZprhnJFBMbdHgHAnlayEadghDQ3OH6LVmZ+ILgjZvFqpPV2YjXDMXHbjDYna3SKfPGhAasSMqXIsZVVo=
Received: from IA1PR05MB9550.namprd05.prod.outlook.com (2603:10b6:208:426::16) by SJ0PR05MB9373.namprd05.prod.outlook.com (2603:10b6:a03:449::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7611.18; Thu, 23 May 2024 14:08:26 +0000
Received: from IA1PR05MB9550.namprd05.prod.outlook.com ([fe80::8a79:8839:570e:a429]) by IA1PR05MB9550.namprd05.prod.outlook.com ([fe80::8a79:8839:570e:a429%5]) with mapi id 15.20.7611.013; Thu, 23 May 2024 14:08:26 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "gunter.van_de_velde@nokia.com" <gunter.van_de_velde@nokia.com>
Thread-Topic: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard
Thread-Index: AQHaYBpl1eapNRcv90+6X05lREaQErFakyiAgAQfQZCAAC64AIA7hirAgAZfnYCAA5J40IAAMYuAgADo1gA=
Date: Thu, 23 May 2024 14:08:26 +0000
Message-ID: <IA1PR05MB9550B4F5415A9000AF269A97D4F42@IA1PR05MB9550.namprd05.prod.outlook.com>
References: <170800694057.2168.264514412767158496@ietfa.amsl.com> <BY5PR11MB433786495B233499026876BCC1032@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB95509197C56B33B6359783EED4002@IA1PR05MB9550.namprd05.prod.outlook.com> <BY5PR11MB4337B11B4CB33E0C73FB1A19C1002@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB9550565DA6093AED6DF29DB5D4ED2@IA1PR05MB9550.namprd05.prod.outlook.com> <BY5PR11MB4337608CF66B0BD1BD9E46D6C1E92@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB955056CC9F7D47CAB7AD11B0D4EB2@IA1PR05MB9550.namprd05.prod.outlook.com> <BY5PR11MB433714B6448C5E18AE1FC1FEC1F42@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB433714B6448C5E18AE1FC1FEC1F42@BY5PR11MB4337.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5953b05b-f2a0-487a-baaf-6bfc326abdee; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2024-04-08T13:33:14Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR05MB9550:EE_|SJ0PR05MB9373:EE_
x-ms-office365-filtering-correlation-id: a7f8a387-f900-485c-80b1-08dc7b31d0be
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230031|1800799015|376005|366007|38070700009;
x-microsoft-antispam-message-info: 8A8Ywohpktlz1/ovqx6GUlRcq1kRmrPWrnvaqea+yjVFLmiSZZ6h+sY2c0gEZDGFQ8UJqhpHTdkvw6CZuNhkddNb75jNfpXKvBrS0cMhQt0RW//kdX6Bq+uJk3MfBNv5BrbAYqpQ6T4E1spAcGcrHAGl9mQR5B7Aaiqh4ELUBejVLbpj6dY4s6SLqovVwnHsYr+rnA3rYyjkj3u3jag4qz9TNVCtRodgA3eEVOypD0q7Ukw9EqYmJXF+4DZvrjGatrqlfm0Dh20KCgbCLvYPK2TNleY3AqblRoRPlzE9+tCn7kZHRsNX/t+LJk8uMkoa/pqvJP+sDcbojcTwfJWYDPNsmr0RLQD8aRge0T8k8GoxoPoCxcaxcvC28rfiaV028ZOwHkdQNWdJJ/tNhA0ZGZgN3WllG4yAffWw4iIpj5/uwAleRzaLkjOYASoGpBhLC7Z9R3m+4k3IRjKZeF31aCWkLixFe1Gi0IgKAxnYQfDO2k1d4oKSyldBTCyvdYBZRzg+ucMtjIGonIU1beIdzVcNkC4q9oLI/fWJiE0ZxSJKPVv7Y6Ac0ayydx2gK5EFeRJUubH7hsz1qSgIBlqhI6jr3FzZxIcxJAJVTyc6x5C6JxnmQkNGwKXSdI015nE5gTtF0+wFXUi4WSPFabtnd8gAv7Z3vI76YCE4JEgzASrN92uvLxdKpYbuPnCg6BFb9+FlKUaAcF6mOzr+sJQr0SNVQMfL6zW+LYoSRgLIvOD29USVBJT8xvylicPf63o4lsn8lmcHzg8kagHjHBRWQKG45DlWRDyb8l/qLtOlVKfRFi+2mc4VSa5f42hWQihXrykyeKxwlS/Se4F+YWl/OhwXAUPtaI+2pVodQZ/BX6fH0W5kuL/eHMaDl5HQCDHrMXngFsi8DdQuZjlAu7KwqlJxP+B4J/jDgurlyxLFhkLM0F9Etk1KqiJFECivDPg4UovP6ssG439Su94hOdZ5Lacw6R7k8pLhOdQyDYX/bAIX7ONKPY+l9iK/aM1dVvVwkEM72eOOi+dwsTy2aeYXJqfmMBA56mssGJNd4YMaE+dv5WgakPv6t4tlPDj0KOm1AJyUyDCls3DEk/XtTt16qtGTuRvflc9jqGyqM8470yX9V/ap8C9VFiEWu/MLsQ9bHRTg5IiZuEvJsxJvql+zL+kL23T3ImD8SK1TLg/5ifKlMWzaOlmwbI6xtE8kbPVjI2Y6UNcPUycKbOPvV+XLdABBWbS3Uwgx2Hd+QCcCnTRLC/ZLXi+qYlzWyCBYHrL7NOd5M5mV+qu7UGxfNNHC87cx3BZDP+hjYeKuQ/83gRY=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR05MB9550.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(366007)(38070700009);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: dzmSpvyWRUUot6fC9+vFKXyK5tUpK1sdk4P3mPcq55lPj3vIPmTQpIHC04ButhyXKBSeOlct4KmV4EIG2gZxLz6lxiTPUTB5gB+G8c5lN0rGzsL3flrz1yauq7Kb6CG2aZIXHg8Y8V3MF3wl7xdCQXtGOaAWGRCDUj5kLPB0iwlIFKpewD0PzCxCoyv7TqKQuR4Yfw/7hZh8oxnhyGrARP6AiTpFmcnznBdREGn5XCB31TUEZVqaAR6VIJ8duyGw1pkUmvGzo2ZW4HcStDCfFTaYyjLUl4OYah+GbIDgZyurgaAPqiTUxMOug71J5hwW76nprBtaW/BU3hP00UyFJHlYc5bNERUtrv887z6gy/nDmfnRfikVD7eQVrhG1RGGiLlId3E56zpSdR0U9FDnMZRRP1NddL3RSVhltSRB0Fzco3XVKGdOmJJ8OIWM0AEaOhIWzcNq1O0StQ/DaV+1t/45EfHzyK9Kan9FYo8sXlvD6qr8916g+1H8B3/pxnZ6TwGRI9lLWOChm0gakDlTiDnWm5GLeoDuirLLZeyE8qIVDKBesWvcVjc9QYLkA/gbr1CAqULy13xK3VTut7TZwEktKlwc92sbLdCXQHJmGhNnBoEl8/mirr7dTSL1XjJ/fdzbK6FTObTxY4BMG1FrfxdEmgC0bosUEk9C7miGjePLXGapzigLSCMqrLKndDEGCT2CKY4XJROkN0CY0Vazh7cZ3LvvShjK5nSX+TKcZjxD7Nx4IJPngBJzJESBiCiNHaVEfDe5XI+JlXy2+GEeCPRO+3e+5Hq8Sfp91oVwtvwlWb5vSQ1HBH0vlIWPZ18LdSOgtbej2HDizVcBC93HyrHTFif1od/asCKcE+iPZVYp/8RlsM1PvWgVTWmy6XyXag/XhAAZ1eF1uxE3Pdj1pUNLit6HcZeoB8nZPc7DFksQEntWfj7O50PvzgziveVbUpyFA9cu/98YcRqOYODMDwYyXTi0LyflKeLk7SEi/kfbfqO2b9U0pUdF1KB37K1GqQynGqufrF7rCSXG1MVF1O5QDzTHcXbFX4BZmi+OFjkocp83bcMN1/40X4ByuRnS5muGR4mlqIgcrmaRwSJiKebJpGmU2MpQSu2EVCk+pn1E9IkSebjal2CkmIkWkApyXcX6oV7l4Rjti26O84WsMOtAvgtVUdkcPfA8mr5Z1thlfFbwAnmqP4qLKGUq1dTxyG+d5sIwnU7bDaseLa5VpfZ8zSyJ2LvVnoKZVzzx2KFnkqpBfOwDXoMoy0AKghm5yBQI72jdku3Hl3VtnVTkeJnjZz3vtnc8A0wVeLHGxcSiV2RC/PrFFNF8yZpAaNCU4HfGjqCXw+AgNS/oktiJQz+wPBMDbSnJmI+agE3QllaYL0EsuSFr4xzplELjcT8V2/7SHKi+7w6LPhKb13xZt9XBkqnzZrJXISza4cW4j0Alfx/1nS8gkuZ/4EZYiC0q3LpTApbTFutjsOZXpuv8rvrwZBqED4JYShU8NB2BYWwJ5s/X4IJoxvSjk7f2nRKcgYc7xXtY8oQHURpZ4wSRY9y6Woxr7XtmFD0QfGVer6XtXzCJn/YQyNcX2EBUM9Mi
Content-Type: multipart/alternative; boundary="_000_IA1PR05MB9550B4F5415A9000AF269A97D4F42IA1PR05MB9550namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR05MB9550.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a7f8a387-f900-485c-80b1-08dc7b31d0be
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2024 14:08:26.5165 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IesA/hRRqnR34zBuh4MRmdoW/OnsKkfvkACMhDM9Ho0WDTSAO6aKU0xytUgBmk5eMJcWoHTN2b6uv9Vb4CrssA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB9373
X-Proofpoint-ORIG-GUID: 9kODhBcmEuUYVAITb8-HPoUhZ3A-M9Qq
X-Proofpoint-GUID: 9kODhBcmEuUYVAITb8-HPoUhZ3A-M9Qq
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16 definitions=2024-05-23_08,2024-05-23_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 priorityscore=1501 bulkscore=0 phishscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 mlxscore=0 malwarescore=0 adultscore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2405010000 definitions=main-2405230097
Message-ID-Hash: KVZX5EVTVQ6X7XBB2FCSKX3G7A5XZO27
X-Message-ID-Hash: KVZX5EVTVQ6X7XBB2FCSKX3G7A5XZO27
X-MailFrom: zzhang@juniper.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bier.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "andrew-ietf@liquid.tech" <andrew-ietf@liquid.tech>, "bier-chairs@ietf.org" <bier-chairs@ietf.org>, "bier@ietf.org" <bier@ietf.org>, "chen.ran@zte.com.cn" <chen.ran@zte.com.cn>, "draft-ietf-bier-tether@ietf.org" <draft-ietf-bier-tether@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Bier] Re: Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Owner: <mailto:bier-owner@ietf.org>
List-Post: <mailto:bier@ietf.org>
List-Subscribe: <mailto:bier-join@ietf.org>
List-Unsubscribe: <mailto:bier-leave@ietf.org>

Hi Less,

We don’t need them to be routable. As I explained:


Zzh3> The information is used during the post-SPF process – if a child of the SPF tree root does not support BIER, we try to see if it has a helper that can be used. The LSA/LSP for the child has the router/system-id in it, and the ID can be used to look up the helper.



In an OSPF/ISIS network, each node has a router/system-id. When an operator provisions a helper to help a node that is not BIER capable, it is feasible and easy to enter the router/system-id of the helped node.

Thanks.
Jeffrey



Juniper Business Use Only
From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Sent: Wednesday, May 22, 2024 8:10 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>; last-call@ietf.org; gunter.van_de_velde@nokia.com
Cc: andrew-ietf@liquid.tech; bier-chairs@ietf.org; bier@ietf.org; chen.ran@zte.com.cn; draft-ietf-bier-tether@ietf.org
Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard

[External Email. Be cautious of content]

(Top posting)

Jeffrey –

Why don’t we want to use OSPF router id/IS-IS system id?
Because they are not routable IDs. Routers will not have forwarding entries for these identifiers – so it won’t be easy to determine whether these nodes are reachable.

The OSPF Router Address and the IS-IS TE Router IDs were invented precisely to provide stable routable addresses for a node.
They are now being used in numerous ways to identify the source of information e.g.,

https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7794.html*section-2.2__;Iw!!NEt6yMaO-gk!A9tsq_-gWYwF7KCZOhWKiZJoEiUtkcF43pnvONQQZpjzkZ60GGOCdqPKhsvOjqkhzbCOIzHO3pBmSehI$>
https://www.rfc-editor.org/rfc/rfc9084.html#name-prefix-source-router-addres<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9084.html*name-prefix-source-router-addres__;Iw!!NEt6yMaO-gk!A9tsq_-gWYwF7KCZOhWKiZJoEiUtkcF43pnvONQQZpjzkZ60GGOCdqPKhsvOjqkhzbCOIzHO3laP4ZS2$>

Your use case is best supported by using these identifiers.

   Les




Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Sent: Wednesday, May 22, 2024 2:31 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; last-call@ietf.org<mailto:last-call@ietf.org>; gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>
Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>
Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard

Hi Les,

Please see zzh3> beow.



Juniper Business Use Only
From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Sent: Monday, May 20, 2024 10:40 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; last-call@ietf.org<mailto:last-call@ietf.org>; gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>
Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>
Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard

[External Email. Be cautious of content]

Jeffrey –

Please find my responses inline.
Look for LES2:



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>
Sent: Thursday, May 16, 2024 7:24 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; last-call@ietf.org<mailto:last-call@ietf.org>; gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>
Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>
Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard

Hi Les,



Juniper Business Use Only
From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmarc.ietf.org>>
Sent: Monday, April 8, 2024 12:20 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; last-call@ietf.org<mailto:last-call@ietf.org>; IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>
Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>
Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard

[External Email. Be cautious of content]


Jeffrey -



Thanx for the prompt response. (Better than me. 😊)

Please see inline.



Zzh2> Well this time it took me more than a month to get back. Sorry about that. Lots of catching-up on the backlog from business/vacation travels.

Juniper Business Use Only
> -----Original Message-----

> From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang

> Sent: Monday, April 8, 2024 7:03 AM

> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; last-call@ietf.org<mailto:last-call@ietf.org>; IETF-

> Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>

> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>;

> chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>

> Subject: Re: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER

> Router To A BIER incapable Router) to Proposed Standard

>

> Hi Les,

>

> Thanks for your comments. Please see zzh> below for clarifications.

>

>

> Juniper Business Use Only

> -----Original Message-----

> From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>

> Sent: Friday, April 5, 2024 6:36 PM

> To: last-call@ietf.org<mailto:last-call@ietf.org>; IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>

> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>;

> chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>

> Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER

> Router To A BIER incapable Router) to Proposed Standard

>

> [External Email. Be cautious of content]

>

>

> This draft is at a minimum underspecified and has some technical errors in the

> encoding which should be addressed prior to publication.

>

> There is no discussion as to what the "address" should be in the proposed

> "BIER Helped node" sub-sub-TLVs.

> I would presume that what should be used is the "Router-ID" as specified in

> the various protocols - but there is no mention of this and I think there should

> be.

>

> Zzh> The draft does say the following:

>

>    The Type is TBD1 (in the case of ISIS), TBD2 (in the case of OSPFv2),

>    of TBD3 (in the case of OSPFv3).  The Value field starts with a one-

>    octet Priority field, followed by a one-octet Reserved field, and

> * then the Address of the Helped Node (X).  The Length is 6 for IPv4

> * and 18 for IPv6 respectively.

>

> Zzh> I can add "4 or 16 octets" to the following figure to make it explicit:

>

[LES:] MY confusion is not with the size of the addresses - it is with what addresses for a given node should be used.

I would think you want to use advertised Router IDs - just asking for that to be mentioned.

Otherwise, I do not know how you expect the various helper nodes to advertise the same address(es) for the same helped node.



Zzh2> Good point; and I do need your advice on this one.

Zzh2> For OSPF, it’s always 32-bit. For ISIS, I see three possibilities: system-id, IPv4 router-id and IPv6 router-id.

Zzh2> The router-id concept is introduced into ISIS with TE. Is it a common practice now to always advertise an IPv4 and/or IPv6 router-id, w/ or w/o TE? Should I simply advertise the system-id in the helped-node sub-TLV?



[LES2:] For IS-IS you should use the TE Router ID as defined in RFC5305, RFC6119

For OSPF you should use the Router Address as defined in RFC3630, RFC5329.



Zzh3> What about using the 32-bit router-id for OSPF, and the 48-bit system-id in the ISIS case?

Zzh3> The information is used during the post-SPF process – if a child of the SPF tree root does not support BIER, we try to see if it has a helper that can be used. The LSA/LSP for the child has the router/system-id in it, and the ID can be used to look up the helper.

Zzh3> What do you think?

Zzh3> Thanks.

Zzh3> Jeffrey



>         0                   1                   2                   3

>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>        |    Type       |   Length      |    Priority   |   Reserved    |

>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>        |    Address of the Helped Node  (4 or 16 octets)       |

>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>

>

> As there is provision for IPv4 and/or IPv6, this suggests that a given router

> could send two such sub-sub-TLVs - one for each address-family. But there is

> no discussion as to whether this is allowed nor is it discussed what would

> happen if a given node advertised multiple such sub-sub-TLVs for the same

> address family.

>

> Zzh> The draft does say the following, which should be clear?

>

>    ...  The helper node (BFRx) MUST advertise

>    one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in

>    the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in

>    the case of OSPF, one for each helped node:

>

[LES:] So, what Helper Nodes are advertising is really a list(sic) of the nodes for which they can act as helper.

Your encoding is not optimized for that use. More on that below.



Zzh2> That is a good point.



> The name as defined in the IANA section is "BIER Helped Node" - but I would

> think this was meant to be "BIER Helper Node". (I could argue that a more apt

> name would be "BIER Tether Node".)

>

> Zzh> It is indeed "Helped Node". The Helper node advertises one sub-sub-TLV

> for each helped node.

[LES:] Ack - after a more careful reading I agree.



I tend to think "helped node" is better than "tether

> node" or "tethered node" for three reasons:

> Zzh> a) the document uses "helper/helped" node throughout.

> Zzh> b) seems to me that with "tether node" and "tethered node" it is not as

> clear on which one is the helper

> Zzh> c) somehow to me the wording "tether" implies directly connected;

> though the document started with that scenario, it has been expanded to

> include remote helpers.

>

>

> The encoding defined in Section 3.1 needs to be made protocol specific. OSPF

> typically pads things to a four byte boundary, but IS-IS does not - which means

> the "Reserved" field should not be present for IS-IS.

>

> Zzh> It is for possible future extension purposes instead of padding. If you say

> it is important to save bytes in ISIS signaling, I can remove it but otherwise I'd

> like to keep it. Please let me know.



[LES:] First, reserving space for possible expansion means we send more bytes than needed. I am not a fan. And since you don’t indicate what the reserved field might be (flags, op code of some sort, ...) the probability that you can add information w/o backwards compatibility issues may be low.

The more flexible way of adding extensions would be to support sub-TLVs.



Zzh2> I will remove the reserved field.



Second, if what you are advertising is really a list of helped nodes, one can imagine a more efficient encoding where you can advertise multiple addresses in a single sub-TLV.

To do that what you need is an AF indicator (so that the address length can be inferred) and then have a list of addresses.

The AF indicator could either be done by having a flag in the encoding - or assigning separate code points for each address family.



Zzh2> One helper helping multiple nodes is not a common situation. Still, I will take your advice to pack multiple ones into a single sub-TLV.

Zzh2> We don’t need an AF indicator for OSPF (since the router-id is always 32-bit) or ISIS if we advertise system-id instead.

[LES2:] I assume you will revisit this answer based on my reply above regarding the addresses to be used.





As an aside, I am wondering what the push is for publishing this as an RFC. Have there been early deployments?

I ask because if you do consider encoding changes, this would obviously impact any existing POCs - but given you did not have early allocation of code point I am wondering if that is a practical issue.

Maybe move forward w an early allocation of code point, get some deployment experience, and then push for an RFC with better experience.



Zzh2> While there is no deployment yet, the solution is sound and it is just a small extension to the Section 6.9 procedures in RFC8279. If I can get past the reviews by Chris, you, and Gunter, I will still prefer to proceed.

Zzh2> I am happy to have a conference call to discuss the solution in more details.



[LES2:] The hallmark of the IETF is that we define solutions which actually work.

The way that is achieved is that we implement the proposed solutions BEFORE documents progress to RFC.

This is not meant to imply that your idea cannot work. But how do we know if it works and if the encodings defined to support it are both sufficient and optimal?

This is knowledge that we want to gain BEFORE standardization. Otherwise, we are likely to end up with early deployments which can constrain corrections in the encodings due to backwards compatibility considerations.



I take your point (made in response to Gunter’s review) that performant BIER implementations depend on new ASICs. But this does not mean that we cannot implement POCs which operate at low scale but still allow us to refine the specification based on actual testing.

I really think you should take the inputs received, focus on implementation, and come back to the WG with feedback based on the experience gained. No need to standardize an unproven solution prematurely.



   Les



Zzh2> Thanks!

Zzh2> Jeffrey



   Les



>

> I am not enamored of this technology - but at this time I will refrain from

> commenting further as the WG seems to have decided to go forward.

> But please address the comments above.

>

> Apologies for the lateness of these comments.

>

> Zzh> Thanks!

> Zzh> Jeffrey

>

>    Les

>

>

> > -----Original Message-----

> > From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of The IESG

> > Sent: Thursday, February 15, 2024 6:22 AM

> > To: IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>

> > Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>;

> > chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>

> > Subject: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering

> > A BIER Router To A BIER incapable Router) to Proposed Standard

> >

> >

> > The IESG has received a request from the Bit Indexed Explicit

> > Replication WG

> > (bier) to consider the following document: - 'Tethering A BIER Router

> > To A BIER incapable Router'

> >   <draft-ietf-bier-tether-04.txt> as Proposed Standard

> >

> > The IESG plans to make a decision in the next few weeks, and solicits

> > final comments on this action. Please send substantive comments to the

> > last-call@ietf.org<mailto:last-call@ietf.org> mailing lists by 2024-02-29. Exceptionally,

> > comments may be sent to iesg@ietf.org<mailto:iesg@ietf.org> instead. In either case, please

> > retain the beginning of the Subject line to allow automated sorting.

> >

> > Abstract

> >

> >

> >    This document specifies optional procedures to optimize the handling

> >    of Bit Index Explicit Replication (BIER) incapable routers, by

> >    attaching (tethering) a BIER router to a BIER incapable router.

> >

> >

> >

> >

> >

> > The file can be obtained via

> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-iet>

> > f-bier-tether/__;!!NEt6yMaO-

> gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S

> > 8Qz44ePY-vB12NTqD4fHt9pgsqPZaldvVYKmMJLu2$

> >

> >

> > The following IPR Declarations may be related to this I-D:

> >

> >

> > https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3331/__<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/3331/__>;!

> > !NEt6yMaO-

> gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12NTqD4

> > fHt9pgsqPZaldvVYC2HqNh0$

> >

> >

> >

> >

> >

> >

> > _______________________________________________

> > BIER mailing list

> > BIER@ietf.org<mailto:BIER@ietf.org>

> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>

> > __;!!NEt6yMaO-

> gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12N

> > TqD4fHt9pgsqPZaldvVYLcO-qjO$

>

> _______________________________________________

> BIER mailing list

> BIER@ietf.org<mailto:BIER@ietf.org>

> https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!BIfUCpxrA0AT2jNR8bR1jM2-oGiTE9sVzQNnWu0D0-059h4vwGobm758B_07PC9Q2PDcNDkNPSdqPJedUY6hKDSpNA7pbN8N$>