Re: [Bier] draft-ietf-bier-ipv6-requirements-09

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Sun, 29 November 2020 15:02 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 8B20F3A0763; Sun, 29 Nov 2020 07:02:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=juniper.net header.b=x/Yjm6jm; dkim=pass (1024-bit key) header.d=juniper.net header.b=P36HZUcJ
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 o9nqbeq2p4Yp; Sun, 29 Nov 2020 07:02:53 -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 64F383A074E; Sun, 29 Nov 2020 07:02:53 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0ATExjZR031700; Sun, 29 Nov 2020 07:02:42 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=H/pi+GPwKZi55o4teFJdnollRVymjoJPDxOuN7fcd5c=; b=x/Yjm6jmJAhdsbhmt+QyLe8zi/nypQeO0adM/L1JhQwHj9cmx2XFfzW6JFfZ7d8PysSC /mjoKT4ki+jxQ+drginpwodn5OYXsGkNEFuFyF6qtfgT2kjVmK9mYyEvmggP6GQELwxu vGIBQfIJeKK28QJA0vMfBGIr7PzN5oHJvJ06/tdgPs/IiadtB+QnfIzk/ooWXj8JMy0X 982fI2N7DV/WdGAl22T7X9ctLmgVSVwT/j22qw4LQpNHNUBNQlTNYaNuh/5U7Ns3x15U maxw1OidRofzwfIfmRMBvMQfJKXQvJjXGBN6cNSnUSXiuw+hl1IRrhm8gD4AyrvdYRA9 6A==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2169.outbound.protection.outlook.com [104.47.59.169]) by mx0a-00273201.pphosted.com with ESMTP id 353k4ws5de-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 29 Nov 2020 07:02:41 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GXdpPXF657V1ztX5IFufwK1qwJDRdhys5k2lhOBMQSKk268Qk1GOUMi/FSiT8m/E4j8BhI0wn2ZZzWEeivG7LckfkPI2zPGC18mZlTZugjgfQKLc+LZ4z2FcGuJ3v1SgNHVuQkoQpQStt5YM5GTZ/gqAlfERkbgNseNiuE2400+oRpFvWNvRW2rCzn/TO8uOpOd3L0oCOOmz+OAxnjPN6t1FPGggRqjIoKfIygF/7/kFz9G9+RA0y1YIZasgoweo0tSk2p0McXqT32o5M7AMYeBWY1cS2ZIhj1lS4f3xR7EPJrFSg3Li/ZtvYwfIoHmstZQHqh08T6+Oq48YXZkV8w==
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-SenderADCheck; bh=H/pi+GPwKZi55o4teFJdnollRVymjoJPDxOuN7fcd5c=; b=VV3GQwDUfhqC5RMk2OsUeUjD7H4dyO+wWHODuMSnSlgO38O7f1Y8sREx6VDKncaY5lbboqSzSDf+2zd/7hbGuAHjQI6FiUwW1lcNoSTdUbo5OfB2CzUofi0dZmBLkHr06cfJyAxg9NRnKo63ecAqi045BP8cqrS5Cc/E/gD63hCMXf2TYXUzd3/g7i5e3OR4Exnu0Sfd3Van723egHleOGn3BF85bVEfjxIViTm1PjEkiaNGcx9LAWE9ZGhyppcOq+h7nSDHJnZRNkPwiHD8HcZi3OA/pivE2PmjEaH8jB/7r3LCX6b7yISUS15eIZDDMBOK2KUJuQy17BAw2P2/oA==
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=H/pi+GPwKZi55o4teFJdnollRVymjoJPDxOuN7fcd5c=; b=P36HZUcJhCWAh/M8ZdgxMolRufR9Mb13tAhQG0dj7aGFhYIf87EjujWuByQYdOLHFkqY+xqonkMJMt/FE8J9X5tVANl8viBydH2AUV7NJOovCU21YLSImh/OCrgrmTgVdPHpL59RaAabFP9+l6ML7hYKhIqgl58kp4G1uShbqA0=
Received: from MN2PR05MB5981.namprd05.prod.outlook.com (2603:10b6:208:c3::15) by MN2PR05MB6176.namprd05.prod.outlook.com (2603:10b6:208:c8::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.9; Sun, 29 Nov 2020 15:02:39 +0000
Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::2cd5:f786:c003:42c6]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::2cd5:f786:c003:42c6%7]) with mapi id 15.20.3632.009; Sun, 29 Nov 2020 15:02:39 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, "gjshep@gmail.com" <gjshep@gmail.com>
CC: Gyan Mishra <hayabusagsm@gmail.com>, Alvaro Retana <aretana.ietf@gmail.com>, BIER WG <bier@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, Tony Przygienda <tonysietf@gmail.com>, draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Thread-Topic: draft-ietf-bier-ipv6-requirements-09
Thread-Index: AQHWvb2JExcoEqV7rUqj331ceyYvFKnPtYOAgAG+jICAAXl8gIAAeTEAgADDhlCAAFMHgIAAEEPggAAhIgCAADmO8IAAIqoAgAAERyCAADn5AIAAaq7wgAZo9wCAAL23gIAAFHswgAAKsACAAACREIAAKUaAgAB62HCAAWNRgIAAOpVQ
Date: Sun, 29 Nov 2020 15:02:39 +0000
Message-ID: <MN2PR05MB5981A98BE6C6A86516E3CF33D4F60@MN2PR05MB5981.namprd05.prod.outlook.com>
References: <CABNhwV0aZRqXP2wAweEktsibTYpHqHhDB9OTPkO+1JmyOb7-gA@mail.gmail.com> <CABFReBoFMZwcPrROMB=RbE60TsP4uajUERbE7MVTQD9AjwJ4ag@mail.gmail.com> <CABNhwV3zOqmSetuB92M=8pFFgGmEyq3KvVWat87WfDoBH4j3bg@mail.gmail.com> <MN2PR05MB598132918AFF529C955B15D3D4FE0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV2KOCHCAnFG0P-9V9g4rsz4e=aZ1WEcNSR6bTLW9OCO_A@mail.gmail.com> <MN2PR05MB5981922D4BDC641F5CF3CD20D4FD0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV1NXz8NrEvP3GYLz2PKkGNOU__D7XOOZ6_tbM03xPcNSg@mail.gmail.com> <MN2PR05MB5981824AF7424761E656D36ED4FD0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV2nzBK7YDqBHrAt_3zAZiA7VDJmw-R=wOqTet6QS=Rg0g@mail.gmail.com> <MN2PR05MB5981AEC2E508A34919BBCE6AD4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV100P14rkQjqt-uNHLhcZCow6n2TL4CxReotkzVX=z-4g@mail.gmail.com> <MN2PR05MB5981E2599B59F35B6F880345D4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV25Aj3yQsa171+u=uVZ8fW5n8jWf2RyR_E1BcfZRfM9Pw@mail.gmail.com> <MN2PR05MB5981F0EE725D7C7C1F048462D4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABFReBoPR_KN66hh9s09AtHg5PVKJjKp7Uew6mV3Fe=nafj3MQ@mail.gmail.com> <55c68ce193ec43eea6368e00dca7082a@huawei.com> <MN2PR05MB59815A895999C8D91D5C1536D4F70@MN2PR05MB5981.namprd05.prod.outlook.com> <4c03dc526afc4720bc1da919c5c41c1d@huawei.com> <MN2PR05MB59819615C0F6846347B5BBB7D4F70@MN2PR05MB5981.namprd05.prod.outlook.com> <8a048602d3644dafa97bfb0ae9acbe4c@huawei.com> <MN2PR05MB598118ACB298AFA88F7AE728D4F70@MN2PR05MB5981.namprd05.prod.outlook.com> <723e0440617846fda0efe0635ed272d8@huawei.com>
In-Reply-To: <723e0440617846fda0efe0635ed272d8@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.5.0.60
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=92795b45-1d54-426b-b3a0-0fdaeab935bf; 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=2020-11-29T14:28:14Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f6e620c7-9502-44fe-7753-08d89477d071
x-ms-traffictypediagnostic: MN2PR05MB6176:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <MN2PR05MB617645D429038B83CD946DADD4F60@MN2PR05MB6176.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6MZ5QRbLcEokX+QfruiEw93SDnzvQpgxJILNbWzBboaBevUNKFHecs4TvaZYnV28KV7CXR04t/6L5GaUCUHJMtYcj/KAxDbNDbDp3alPx6flN5C76d1l7k6SQbT5V2bqlnkBwEL66/UpBX11BKbr4PK7tKTDQQs3DDzVnPKLuvVXpzoXSQ3dZ8Kwn5F50VF6UOD/L8TYBeBkKuE5C3MkJSirSogKBKFI/MFcTV8elp2aVOtjsLdO6PPzhiSYXsn+C4jTJLHtly5bypq66jSwnl3n3iOkb/Wq9KHixDx18yEXDv09ktyZqPvDddvTl9siZs8HFt4wk4xr9DIKI12aT3xEwZdXuYd4e1SKHsq3VlRAFQy152Kp9LxMCGmLG8ViYV3vo6y15XSNIin4eBZMqg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB5981.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(39860400002)(346002)(366004)(52536014)(33656002)(30864003)(316002)(54906003)(110136005)(4326008)(5660300002)(55016002)(8936002)(2906002)(66946007)(66446008)(8676002)(83380400001)(7696005)(66556008)(66476007)(966005)(478600001)(86362001)(186003)(9686003)(76116006)(64756008)(26005)(71200400001)(6506007)(53546011)(66574015)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?S2hTeDJqclM0dThVWENzUDJiYXhZMlBxNHY0TlpWdEtSSkoyK3U5blhhOW5S?= =?utf-8?B?TWdHV3VmNDVQOWU4dUlwUUJaSXE2L1BoUSs3bnZzQ2luVC8zMjJaTjJ4NmFv?= =?utf-8?B?ME1aTWIrMEZTMzlYNEJPMkp6QW80YUxkOXR3TzliMkEyeWh0eER1SHR2UTIr?= =?utf-8?B?SHRSeE9PT1pKRHQ4RTZud2U3NzZDNGZuK0UxUVVWNjNIV1ZUWFdjcjQ2NG5U?= =?utf-8?B?T0s5Z2N3QlAvaHRmNVNOd1hBaVR5OVNuT0RCSG9ZdWxoQXZUOVFCTkVQT2pO?= =?utf-8?B?NW9yMGF3aEZDc3NFblhCQ0t3Y1MxbDIrbnlRbEI1cExMR1k2LzFxL05vQURp?= =?utf-8?B?WDlNY0R2cFFiV0dTK1dVZE5mVFc5VHNPblkyWDRpMDd0V25OSy9ORitnek9L?= =?utf-8?B?TGJmREhoeGpja1FMSFVYa0d0aStsMmZNc3lYM2tPYSsxRndtVUkvcVFRZmdQ?= =?utf-8?B?Nk1heXl5WUpnTlUwS3pWZzVSMHh3N2xZaEhZV0pWdldYNVIxZnJPMW9YL2U4?= =?utf-8?B?SnFRanpQTnhaSFg1enNPdWpKaHNGeGlvUWdITW5CeVBrSjU3YWhwRjJVSnJo?= =?utf-8?B?a3hObXpsTlU5ZWFwZHh4QW9QMFJEQ21CdVFSbzVPRnc1TThwRVcyYU9keG9N?= =?utf-8?B?bmp3OGJGSGFwNUEzNkhueGgwUVpuZ0RBZTRGRTF1TFBVNi9LUlNnM1BGL3dB?= =?utf-8?B?MTd5ZE1vTVpXT0JwV01UcXFVK05yS2YySFMxaTFxUS9MdUZBWjJTYmFrMWNx?= =?utf-8?B?TjZzWXpkTGJIbGUxQk1OVDRFQXYvY1g1NGVoVWpybENRNU03V2VjT1dSWktv?= =?utf-8?B?dVMyb2VlVkdEWTF0VkZVMzByWEV4U09GdW8wQ0FBeVpRRWxKclZ6YVltTFg1?= =?utf-8?B?WFhUeDJFVUNsWWU4WG1FVjNyOGdMblB1U2c2V2Q2di9vYWtJUm56U255YmY0?= =?utf-8?B?R0lwYzB4c0hMMGhUZWxOMXFZbkI1M1FrYlh1b2NxTk9ib0htKzZyNDFkc25N?= =?utf-8?B?WjR1ZlBKa1F3aGpReFdqemhiLzc4blAvVXhRaW0xOGtsUnBYMDY4SHRsYzg0?= =?utf-8?B?K0sxdW1iV2JtbnkwaDV4SjRPa0s5Qy8zY2hZd01vVS81eXM0amZPcnJBdXBQ?= =?utf-8?B?TjZVYm5uM1FpbGg0d1RrRnpzSkJPaU16T2dJZmdkM2Fud1k4YnVLYjNHaWo4?= =?utf-8?B?NFBROXZmZjcrbjB6UXkxalB5K3pWYUU3dUQ0SytKcHdxVjBKL3cvc3ZIYW9i?= =?utf-8?B?V0tsWHJEdkI3V1R5OEpaYXpQSkxWbmt6QkdML0NiM29UMmMvUWpOSG9FVzhM?= =?utf-8?Q?crkBvvB00Oc6I=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB5981.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f6e620c7-9502-44fe-7753-08d89477d071
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2020 15:02:39.0622 (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: wGQ6zQV8bQZ+IrOqsOuFaOSJIz3XW9Vdvq7EA3/ZuK70F79KRRtbZ3HRy/SEIeTYwc0bbPiAHbPEUjQftoO4qQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6176
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-29_08:2020-11-26, 2020-11-29 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 bulkscore=0 suspectscore=0 clxscore=1015 spamscore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 malwarescore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011290102
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/u-0ev51LszBGndHpHeKH7BcQF90>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Nov 2020 15:02:57 -0000

Hi Xuesong,

Please see zzh3> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Sent: Sunday, November 29, 2020 5:59 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; gjshep@gmail.com
Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Jeffrey,

Please find the comments inline.

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Saturday, November 28, 2020 10:22 PM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>om>; gjshep@gmail.com
Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Xuesong,

Please see zzh2> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Sent: Saturday, November 28, 2020 1:27 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; gjshep@gmail.com
Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Jeffrey,

My point is quite simple: if there is extension capability in the protocol, use it; if there is not, make a tunnel over it. And IPv6 belongs to the first and Ethernet belongs to the second.

Zzh2> I bet people will disagree "Ethernet does not have extension capability in the protocol".
Zzh2> Any L2/tunnel protocol has extension capability to indicate the payload type - Ethernet or PPP (for the POS example that Jingrong provided) or others (perhaps I could add "modern L2/tunnel" to be safe 😊). For a non-Ethernet L2, adding a new code point in the L2 header (or IPv6 header when tunnel is used) to indicate that a BIER header follows is using the "extension capability in the protocol".
Zzh2> BTW, MPLS also has capability to indicate payload type - by assigning payload-dependent labels - but that's a side point.

【Xuesong】Let's properly distinguish between "a protocol's ability to extend itself " and a protocol's ability to "support a new upper layer".
In the hierarchical architecture of the Internet, each layer of protocol has the capability to indicate what the next protocol is supposed to be. A new code point is not for Ethernet extension, it is for new type of the payload or overlay protocols.
To be safe, please allow me to put it more accurately: Ethernet has the capability of extension but IETF is not the right place to do it 😊. So, in order to make BIER work over Ethernet, a L2 tunnel is defined in RFC8296.

Zzh3> "in order to make BIER work over Ethernet, a L2 tunnel is defined in RFC8296" - that is simply not true.
Zzh3> BIER non-MPLS over Ethernet does *not* use L2 tunnel. BIER header directly follows  Ethernet header, and we got an Ethertype 0xAB37 assigned for BIER.
Zzh3> In case of BIER over MPLS over Ethernet, that BIER label is not for a *tunnel*. That single label, which is not for the purpose of getting a packet from BFR1 to BFR2, serves the combined purpose of (0xAB37 + BIFT-id) in the case of BIER no-MPLS over Ethernet directly. If BFR1 and BFR2 are not directly connected, then a tunnel (L2, L2.5, or L3) tunnel is indeed needed, and that's still RFC8296 solution.

Even in BIER MPLS, BIER-MPLS label is newly defined to indicate BIFT-ID, using the scalability of MPLS. In IPv6, we use extension header.
BIER is not totally "transport independent", otherwise, there is no need to distinguish BIER in MPLS and BIER in non-MPLS in RFC8296.

Zzh2> The BIER-MPLS and BIER non-MPLS is actually a *perfect* example of "transport independence" - the same BIER header and forwarding (including overlay forwarding in case of BIERin6) are used whether it is over L2, over MPLS tunnel, or over any tunnel.
Zzh2> If you know the early history of BIER, you will understand how/why BIER-MPLS was designed that way, and in fact, that same design concept is inherited by BIER-non-MPLS. The only difference between BIER-MPLS and BIER-non-MPLS is whether the BIFT-id is treated as a label or not (ok plus that in case of MPLS, the BIER label also indicates that a BIER header follows while BIER-non-MPLS requires a code point in the outer L2/tunnel header).
Zzh2> Jeffrey

【Xuesong】The BIER-MPLS and BIER non-MPLS is actually a perfect example of BIER is "not" transport independence. I don't think it's even necessary to say more, because we could get this conclusion by the name itself: BIER encapsulation is different when it is in a MPLS domain or a non-MPLS domain.

Zzh3> Now we have totally opposite views so I will defer that to other BIER veterans.

Even if BIER-MPLS label is used only for indicating the next header, it will make more sense to claim that BIER MPLS is transport independence. But, BIER-MPLS label is used to indicate BIFT-id. It's encoding BIER information in a manner of MPLS, just like what we are trying to do with IPv6 extension header. I can't see why a new MPLS label for BIER is allowed but a new IPv6 extension header for BIER is denied, unless BIER WG has some special preference for MPLS.

Zzh3> The history is as following:
Zzh3> 1. BIER WG designed BIER-MPLS first and intentionally mandated that the <subdomain, bsl, set> is not to be directly encoded/decoded into/from the BIER header itself. It should be derived from the BIFT-id, which is actually the BIER label itself. I'll skip the reasons/advantages here.
Zzh3> 2. BIER non-MPLS was then designed, inheriting the BIER MPLS design. The BIFT-id is not called MPLS label, but the essence is the same (except that the BIER label serves two purposes: "next header" code point + BIFT-id).

Zzh3> The presence/future is as following:
Zzh3> Now BIERin6 just adds a new "next header" code point to IP just so that when an IP tunnel is needed for BIER, BIER non-MPLS can be used as is.
Zzh3> BIERv6 is not just new IPv6 DOH type. It requires changes in all three layers - BIER, IPv6, and overlay forwarding. That's why it needs further discussion.
Zzh3> Jeffrey

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Saturday, November 28, 2020 12:02 PM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>om>; gjshep@gmail.com
Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Xuesong,

I'll get back on the 6man's comments, but for the other two points, I have to say that you have not really understood BIERin6, or the basic concept of BIER over L2/tunnel.

Jeffrey

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Sent: Friday, November 27, 2020 10:57 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; gjshep@gmail.com
Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Jeffery,

Please find the comments inline.

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Saturday, November 28, 2020 11:32 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>om>; gjshep@gmail.com
Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Sent: Friday, November 27, 2020 9:06 PM
To: gjshep@gmail.com; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Greg,

I have followed the thread. And I don't there is consensus about BIER IPv6 requirement and BIERin6 in WG. Here are some my concerns that have been discussed in IETF109:
1. Why we need a new "next header" when the existing IPv6 extension header could satisfy the BIER IPv6 requirement;

Zzh> which existing IPv6 extension header? I hope it's not the DOH that encodes the BIER header as in BIERv6.
Zzh> Otherwise, the questions should be flipped around - since RFC8296 BIER over L2/tunnel works well (with just a new "next header" code point in case of IPv6 tunnel), why we need BIERv6?

【Xuesong】The answer is quite straight forward, because there is no extension header in Ethernet. IPv6 uses extension header for new functions/information. Based on the logic of BIERin6, some new next header code point should be allocated for Fragment Header, Authentication header and any functions that are supposed to be initiated with IPv6, which obviously violating RFC8200.

2. The comments raised by 6MAN WG and INT area are not addressed, which requests the document to be discussed in transport area;

Zzh> I am surprised to hear this brought up in this BIER session. I must have missed it in last IETF's 6man session. As we briefly talked about in this BIER session, it's strange that tunneling needs to be discussed in transport area, but I will dig into last 6man session's minutes and recording and report back.

【Xuesong】(It's interesting that BIERin6 authors brought the document to 6man in IETF 108 and received some comments but now I'm asked why it should be and what the comments are) please find the detailed discussion in https://urldefense.com/v3/__https://www.youtube.com/watch?v=_1MFLec7pSw__;!!NEt6yMaO-gk!TUCt_gogUCdssS5rDQb5S00pjbJzddnbLVDKBxLUbbXHgSchHxhcsmJxXs-bW94t$  and the minutes could be found in https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/108/materials/minutes-108-6man-05.html__;!!NEt6yMaO-gk!TUCt_gogUCdssS5rDQb5S00pjbJzddnbLVDKBxLUbbXHgSchHxhcsmJxXgxXw2LK$  .

3. BIERin6 is not an independent solution which uses BIER Ethernet when BFR nodes are connected directly.

Zzh> As have been repeated several times in recent threads, BIERin6 is about supporting BIER in IPv6 networks - it is appropriate and have become critical  given ongoing contention to have a spec to explicitly talk about how existing BIER over L2/tunnel can work nicely in an IPv6 network. With that, the above comment just does not make sense.
Zzh> Jeffrey

【Xuesong】I can't see why some solution is appropriate when it depends on other solutions. It seems like in an IPv6 network with other type of L2 link except for Ethernet, BIERin6 doesn't work.

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:gjshep@gmail.com]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thank you Jeffrey and Gyan for sticking with the thread of the conversation to advance the discussion. It's clear now that all of the requirements discussed so far can be addressed by the BIERin6 draft if we flesh out the discussed gaps.

I would like to see Jeffrey and Gyan take over as primary authors of
BIERin6 to include the gaps discussed here so that it fully encompases the requirements so far described, for WG adoption.

Thanks,
Shep

On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Hi Gyan,
>
>
>
> Great that we reached consensus on BIERin6.
>
> Now there are two lingering points alluded to in this thread, but
> given it’s been such a long and deeply nested tread, I’ll start a new
> thread about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Monday, November 23, 2020 1:32 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <
> tonysietf@gmail.com>gt;; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>gt;; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> That’s the last of my questions related to BIERin6.
>
>
>
> I thank you for taking the time to go over the BIERin6 draft in detail.
>
>
>
> We have reached consensus as well as are in sync,  and I now have a
> better understanding of BIERin6.
>
>
>
> During the discussions I did mention that maybe in BIERin6 optional
> IPv6 tunneling should be removed, as it seemed to create some
> confusion, but now I am clear and as both the L2/tunnel and IPv6
> L3/tunnel encapsulation single hop or multi hop tunnel both have the
> clean BIER layering and complement each other I agree they belong together in the same draft.
>
> Even though L2/tunnel exists today as part of RFC8296 it makes sense
> to be part of the overall BIERin6 solution.
>
>
>
> I am clear on the two IANA code points requests required for the
> optional
> IPV6 encapsulation option.
>
>
>
> Over the course of this thread we did touch on some technical reasons
> why
> IPV6 encapsulation is necessary which I you mentioned in some of your
> responses.
>
>
>
> Overall throughout the discussions I agree that BIERin6 IPV6 tunnel
> option and BIERv6 are not transitional and are long term solutions and
> there are reasons why that we can add to the requirements draft as to
> why IPV6 encapsulation is necessary below:
>
>
>
> - Operator requirement for IPV6 encapsulated packets  and not L2
> encapsulation.
>
> -FRR
>
>
>
> I think we are all set to start updating the Requirements draft.
>
>
>
> In-line Gyan6>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
> Gyan,
>
>
>
> Please see zzh6> below.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 9:49 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <
> tonysietf@gmail.com>gt;; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>gt;; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Agreed we have reached a consensus.
>
>
>
>
>
> Few more questions to iron out understanding.
>
>
>
> In line gyan4>
>
>
>
> Zzh6> Apparently there are still disconnects 😊
>
>  Gyan> Thank you for all the detailed responses.  We are in sync now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
> Hi Gyan,
>
>
>
> Yes I believe we’ve reached consensus.
>
>
>
> Please see zzh5> below about some details.
>
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Sent:* Sunday, November 22, 2020 4:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <
> tonysietf@gmail.com>gt;; draft-ietf-bier-ipv6-requirements <
> draft-ietf-bier-ipv6-requirements@ietf.org>gt;; gjshep@gmail.com
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> This has been a very informative exchange and extremely helpful for
> all of us to get onto the same page from a basic understanding POV.
>
>
>
> Much appreciated all your help and feedback helping clarify my confusion.
>
>
>
> I am answering in-line but now connecting the dots how is in today’s
> RFC
> 8296 Non MPLS BIER Ethernet going to transport IPv6?
>
>
>
> From your answers below it cannot work as we need two IANA code point
> one for IPv6 next header type and ICMPv6.
>
>
>
> Zzh5> The existing model/concept works except that we need to two code
> points if IPv6 tunneling is used for either getting over non-BFRs or
> for FRR. One may deem non-BFR as a short-term scenario but FRR will be
> here for the long run.
>
>
>
>     Gyan4>I am a little confused here with the code points.  For
> BIERin6 “L2” BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether type 0xAB37.
>
>
>
> Ethernet -0xAB37 l BIER | IPv6 | payload
>
>
>
> Zzh6> Note that IPv6 header is not needed – it should be Ethernet
> Zzh6> -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6
> header may be inserted between BIER and payload, only for the SRv6
> style VPN purpose.
>
> Gyan> Understood
>
> Ethernet -0xAB37 l BIER l ICMPv6 | payload
>
>
>
> Zzh6> ICMP was mentioned not for encapsulation but for the following:
>
>  Gyan6>Understood
>
> Zzh6> 2.1.  IPv6 Options Considerations
>
>
>
>    For directly connected BIER routers, IPv6 Hop-by-Hop or Destination
>
>    options are irrelevant and SHOULD NOT be inserted by BFIR on the
>
>    BIERin6 packet.  In this case IPv6 header, Next Header field should
>
>    be set to TBD.  Any IPv6 packet arriving on BFRs and BFERs, with
>
>    multiple extension header where the last extension header has a
> Next
>
>    Header field set to TBD, SHOULD be discard and the node should
>
>    transmit an ICMP Parameter Problem message to the source of the
>
>    packet (BFIR) with an ICMP code value of TBD10 ('invalid options
> for
>
>    BIERin6').
>
>
>
> In this particular scenario where adjacent BFRs support Ethernet link
> layer in an IPV6 environment and  IPv6 or ICMPv6 encapsulation and the
> need for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
>    Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet
>
>    header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc5332__;!!NE
> t6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ84s
> sHlj$>].  IEEE
>
>    has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
>
>
>
>
>
> In the case of BIERin6 optional encapsulation option, in case where
> operators requires packets forwarded in IPv6 or tunneling over Non BFR
> packet format below:
>
>
>
> IPv6 outer header l BIER l Data
>
>
>
> So here the next header is BIER so corresponding next header code point.
>
>
>
>
>
> So below is for both cases IANA code point allocation for “L2” next
> header where next header is IPv6 or ICMPV6, and then the optional IPv6
> encapsulation option where the next header is BIER.
>
>
>
> Would those be two separate IANA code point requests I what I see from
> the packet format.
>
>
>
> IANA L2 scenario:
>
> 2 code point requests for L2 for next header IPv6 and ICMP
>
>
>
> Zzh6> I don’t follow what you’re talking about. If BIER header follows
> Zzh6> L2
> header directly, no new code point is needed. It’s just “Ethernet
> 0xAB37 | BIER | payload”.
>
>
>
>     Gyan6> Agreed.
>
>
>
> IANA optional IPv6 scenario:
>
> 1 code point request for IPv6 for next header BIER
>
>
>
> Zzh6> If IPv6 encapsulation is used, either on between directly
> Zzh6> connected
> BFRs or indirectly connected BFRs, a new “next header” code point is
> needed for BIER.
>
>  Gyan6>Understood
>
>
> 5
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zhang-bier-bierin6-07*section-5__;Iw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH$>.
> IANA Considerations
>
>
>
>
>
>    IANA is requested to assign a new "BIER" type for "Next Header" in
>
>    the "Assigned Internet Protocol Numbers" registry.
>
>
>
>    IANA is requested to assign a new "BIERin6" type for "invalid
>
>    options" in the "ICMP code value" registry.
>
>
>
>    IANA is requested to assign a new "BIER IPv6 transportation
> Sub-sub-
>
>    TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV"
>
>    Registry.
>
>
>
>    IANA is requested to set up a new "BIER IPv6 transportation
> Sub-sub-
>
>    sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV"
>
>    Registry.
>
>
>
>
>
> My point is that the IANA allocation is different as the next header
> is different for the L2 scenario where next header is IPv6 or ICMPV6,
> and IPv6 encapsulation scenario where the next header is BIER.
>
>
>
> Zzh6> If BIER header follows L2 header directly, BIER Ethertype is
> Zzh6> used
> (assuming Ethernet is the L2).
>
>  Gyan>Understood
>
> Based on this point I am making could we just do a RFC8296 bis version
> and add the IANA code points for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the confusion/contention that have happened in the last
> Zzh6> two
> years, it is much better to specifically have a spec dedicated to
> supporting BIER in IPv6.
>
>  Gyan6> I think now looking at it holistically speaking I can now see
> parity between the L2/tunnel and L3/tunnel both also having the clean
> layering.  So I can see why adding existing L2/tunnel to BIERin6 even
> though it already exists made sense to bundle into BIERin6 total
> solution

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only