Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Fri, 05 March 2021 19:53 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 B73813A0B20 for <bier@ietfa.amsl.com>; Fri, 5 Mar 2021 11:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.246
X-Spam-Level:
X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, 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, 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=PYJqGq2U; dkim=pass (1024-bit key) header.d=juniper.net header.b=ftD2XWb/
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 jXmwvnfSpk2r for <bier@ietfa.amsl.com>; Fri, 5 Mar 2021 11:53:07 -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 890073A0B17 for <bier@ietf.org>; Fri, 5 Mar 2021 11:53:07 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 125JiNXa024808; Fri, 5 Mar 2021 11:52:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=tQbs1+0DnbdDQU1HYCpTNn0mafCgCRhqEwXRO4XIvqw=; b=PYJqGq2UrOqhuyIVfrhYNkXZzp8v4BslRMSBrgV8rxmiaU66LB+7CP2ZlN11IKZ9Ids1 R94AN5kXlYDh7vrITOZrs5Kra8qADcBzArp4HrsPkPEUlAPcJ5tsZJyC8ErzGAJBo1uk Lw9InI/813LItRyV+M/x45PbzXkxkPzLr3u1rcNkV5tJXwwW1nkRGHrq+RoCPgHygZSU /OCvG5/CAC15fOJoL0e/oAI5fRhHMphoKXfsK1ps7/eZsiGYkaYMOYBn0IFXoGZ/l3/1 gUDN5ZRTugmjA6y71DqKF1/ThJxmZenuFL63usFFyVvVEYNovV8uG5i5QG5YNv47nrfb qg==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) by mx0a-00273201.pphosted.com with ESMTP id 373hf1h3ts-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 05 Mar 2021 11:52:58 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ga71J/I7E+6betKfud7fE0u6cKB2SN2rvrVX1IVx5bJrujmF9ePRPlGpIsE5SwoCb6DAI7XSbsS9AILC9ePzyFCgso3RYKs7GwuORSMPJ2a0iEVPCia+IiVcHcV8tkSlb+12VSWZqJU+HJtFHZfYm8fPcPqze+PwTQ4n5j5KABWkGrCTpncOstCRHBiOLLdMn3Kr30A5KIPijPIz38Orfo5J1Ge+KkVH5AHeomodG5oSMfBxus4JnKo1N4TwNkmYE9yLEHN9oSsMmdmnShbjyOI1Ty9a528wbnPeNpCtzLVAePeJRK+DTK9hdlnYMBSmbHWSraDBVbbVCY5tFM9GJg==
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=tQbs1+0DnbdDQU1HYCpTNn0mafCgCRhqEwXRO4XIvqw=; b=S7WVAaJuu9yMDVAwY8HnzQLQT8cpxgFsXOMRLJWosdNUyooPJeuLBUfgbGMSwpSrm8J9c9HIyI8yBK/hAlCdPc/Bg5G59CWhltHODiy4D/9riHnGLukDTLfIhpKEHLtjymMKSgSlANRCYPlj9pXi/Iv3RZ9RwUuAAupp7ofPmA9b0Y3JhFuVVR+tEgbMAeAc/wEX4KCHOznscBeHYlDMqb0BHYxOR+YpzhH704voMIsIWRkVba1miWuBLFk1JL+3zUoAWSBRs9rjJWdcdLlIB+0C2PAylQrWeofXVXy9H7Xw8wNEnV20Ug8w1msPtwqPQKv9EoeoYXbSmgPOHXdkcg==
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=tQbs1+0DnbdDQU1HYCpTNn0mafCgCRhqEwXRO4XIvqw=; b=ftD2XWb//LRg23MkU7J6WVistpT90gldZG/I/p/4Bf+tT3ss+uwinZeVykkdVxyXHIns+CRHdGOEDtD/RCOIBBSY4InuB1f78xWvA8mjfGAUzgMkqHOx80LiJKkYOppArJqGiRbug3i81sl9V+CAtJcVJhd/ruwlOMa3CPT8ovg=
Received: from BYAPR05MB5974.namprd05.prod.outlook.com (2603:10b6:a03:d6::11) by BYAPR05MB5109.namprd05.prod.outlook.com (2603:10b6:a03:9e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Fri, 5 Mar 2021 19:52:54 +0000
Received: from BYAPR05MB5974.namprd05.prod.outlook.com ([fe80::7575:751b:cd8a:a80b]) by BYAPR05MB5974.namprd05.prod.outlook.com ([fe80::7575:751b:cd8a:a80b%2]) with mapi id 15.20.3912.022; Fri, 5 Mar 2021 19:52:54 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: duanfanghong <duanfanghong@huawei.com>, "gjshep@gmail.com" <gjshep@gmail.com>, BIER WG <bier@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, "Rishabh Parekh (riparekh)" <riparekh@cisco.com>
Thread-Topic: [Bier] Call For Adoption: draft-zhang-bier-bierin6
Thread-Index: AQHXC5TKt8NALInKcUizaE35nWOSI6pv7hKAgAASLsCAAJu+AIAAcTEggAFCW4CAAEY+gIAA9DqAgABF45CAAXmvAIAAj+Uw
Date: Fri, 5 Mar 2021 19:52:54 +0000
Message-ID: <BYAPR05MB59744D2727CDE7B27BC2F0FFD4969@BYAPR05MB5974.namprd05.prod.outlook.com>
References: <CABFReBodz5ko0wAZ_8vKgreWMLnCE_6O_qhKS_RGUbSAowEwfQ@mail.gmail.com> <81971eb65f8848a693d9863d7e8cd6f0@huawei.com> <MN2PR05MB598120A402A23CCE9C1397F8D4999@MN2PR05MB5981.namprd05.prod.outlook.com> <399a9abe217242f585ce72e95307c789@huawei.com> <MN2PR05MB598109D5B639C2228036335BD4989@MN2PR05MB5981.namprd05.prod.outlook.com> <22dd68c9496c4214b59ff755d60f7b50@huawei.com> <MN2PR05MB598148E3D6F5184FABA9D783D4989@MN2PR05MB5981.namprd05.prod.outlook.com> <7bf39a8df86540b28d26ec4b1455d51f@huawei.com> <MN2PR05MB5981784D2E2CEE26263103A2D4979@MN2PR05MB5981.namprd05.prod.outlook.com> <24f9a7e89cf24e219edf1685b51d1974@huawei.com>
In-Reply-To: <24f9a7e89cf24e219edf1685b51d1974@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.6.0.76
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=6b375c3e-749f-4546-87d7-85793f909812; 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=2021-03-05T19:47:05Z; 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: [71.248.165.31]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ba62be43-c940-4e7a-53ab-08d8e010445e
x-ms-traffictypediagnostic: BYAPR05MB5109:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <BYAPR05MB5109B0A16650A323F5425936D4969@BYAPR05MB5109.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: TfeNR9hvYGRZDg9Zbh0Q7G6Hb+mh1kTfo+YySm/xFLgOVq4oQvtr51CXvuAXxf+po1cmlK+AWrjog+qiPsUbe8RoYOFgXdVexx4KFxjmpzhKuV6wPihdj3Abt7KFCHYAT+NR1i0J//Q28K6Rq+fcZxUaspJ8GFtjFHSJFMfy4igs7AE8GXMrTO3xFONm1qFf1oIqk8V3yL9hMh2BFv/RPN+/Mff6w+dyznw9WdJZ7xDkaOJuKhg4Ak0DOB5GMijpN+GmUcIIKcYHxwWkdy4OZY2dRia3uhZ39F6Jsf5PWBtFH17j4/LGCbAq/JN6ZYic3G3Y5vbyRJCKATKGk6zIz2xE3tJ6zImz7QLBQDkUwUeyAgGdCSNVFup5neiBDzE4kcKELPlcWDJx0QTIXM7dHPcoCnOAd1m8N08qbP8N9Cnf1Yxt0Ahqifpe1HxIjlDa65JEuWX0/DbIIT9w7p/lxnQR3WmkGGTXA83wij6WcmkMaGEvIV7dWJ8RpBBohB00I1IKsnJPtB+oZDET+wHK1xNIe5IjdTMeQQDgRfVe5xQxiuJvSkh+syxv69J7hA5N0lM6zYGT040ciU5uyiCKyv2p9HMudHROV6XbOEJkit8jLEE7jEkPQ5Yfddjiz2rP5I7zenLTf6ZGKR+VX/YReg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB5974.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(346002)(396003)(136003)(376002)(478600001)(2906002)(86362001)(966005)(9686003)(66574015)(33656002)(7696005)(8936002)(9326002)(52536014)(66556008)(64756008)(66446008)(76116006)(83380400001)(186003)(8676002)(53546011)(6506007)(26005)(55016002)(316002)(66476007)(5660300002)(66946007)(71200400001)(166002)(110136005)(30864003)(491001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?L2pkL0hFaVpRSXc1Q0Y0aFZSUWxNQ3AyZ29tR0JWZUdEdWE3LzRkL1JLTWVS?= =?utf-8?B?cHNsOGZKajlhU3FYblZQQitpekY4aVRtc1JibTFsNU5sb3hHR2IxUXF1WlF5?= =?utf-8?B?NG9xeVQ0VGhjSUVIVmxJV2h4Q0tLNXpCOGlaNFRvaWxERTJzaUZzNGZ5V1Ew?= =?utf-8?B?d0U1emluQVRnM0RCODV6aHZxZnp2RUI0UWhZTGhIRkYwSFpyd2UrYUVUY3k4?= =?utf-8?B?aEUzOUVwcUpjbWRweHJKR21ORzRUdDdqRHNDd0tpWVdXY1ZNemgwdGNvWndv?= =?utf-8?B?dnBvM0loYXlkS0MrUmQ3THRJd01EV1R3RUxmc3poWXZVZ1RVMFNJMmJUTlhE?= =?utf-8?B?OGJ5djJpUGo2TjVYbThHbFRZRDBTOU1zaUtjSE84RzU2emRhYTduM1JDc0Vn?= =?utf-8?B?OEhQN3pNUVExSVlZMjlZMGJtanRVb2xPZ0FWSDBPQ2MyM2lTNmVYRU9FcjZw?= =?utf-8?B?Vk1qUEFjd0Y2aVdnc1JOVHFSeStDekhZcE55TVd1L0ljWnU0WkhSSUVkNGFu?= =?utf-8?B?OW81bW84YTl6RzJ1bzZCRlZ6UTJQTXYycWJtc1h0bXh6U1NSNW9IeCs4cnNM?= =?utf-8?B?ZSsrNUlUTS9jZnByaHJxOVN4Q1RtTmNoT0xZRS9VNzNpWitoMnhDNWl6Z083?= =?utf-8?B?UURHMU9aMUcyTGdVQWVpa2xFR2lpZHFBSUhNOTY5bWFpdjdRajJVNi9yRFJ0?= =?utf-8?B?a3h6cE1GRi9MU2d1TXJGSk1naUNmVlo0UzZROXZXTlhUTzUvbWtFZWRZMVRM?= =?utf-8?B?dWZvT1VndldVdUFIOWJUNWY5Wnl2MjhBY0dYV2hqRHlTVXFXSk1YalYwakRp?= =?utf-8?B?M3piM05Wa3EvandyZ2k0Vkg2WW1EMTJPYnJGcWhLdFdTOE5BVVRuZ2tSYkJ1?= =?utf-8?B?SHcvRDdBdEVLOHFkQVZFdjBWQitqNkZrcW9ReTdjRWhuNnRGRXZwOG9RQ09t?= =?utf-8?B?azkvSjNtYzhCQmtPcGh1MUswRkN0Q3g5NzNMVVRNbjlERDhPMUlNamhiVDR3?= =?utf-8?B?OG40LzF3UDI4WjRMNThIZXUxdlY5NWpXZFFDSm5pejQxTXB4VzRTUERlK2dy?= =?utf-8?B?TEFYOHFUeVpqVk1Mdi9ZZ0ZwS1Q2a2Q4NXVjaWdBTlZ0K2ZVM1EwUU1Mc2s3?= =?utf-8?B?eDhLanVDdzlzcm0wRDVZb1FZUXk0NVVBMFJqUjE0dnh4MXNTbHJsRS9LZHpK?= =?utf-8?B?MUZacUdqTnNWTWU4bDZPcW04UTV3NzhhMzhGY1M5eDh2Zm1oME5ISFdxT0R6?= =?utf-8?B?andWQ0hDb2hCVEhFRHFjbnVBMzlRME4wZ0pqODlkWm9LY1NZSFNSWnlOTEEx?= =?utf-8?B?UVppZHBZblBwT1pudFRGV1ZZM25HMGxiVHFMeWh0c05TUWdqc2NPUlJKWklq?= =?utf-8?B?WWpQN21QZTQ4d3RDbkozNERnaE4vTmtNdTJGS1p0YmlGc1FMVWk3QVNEeE9n?= =?utf-8?B?K3IyU0tidEx1VUc5ZC9ySUtLcFBVWmgyOXZTbHZrL2tCTzVLZlE1cFZwaWpV?= =?utf-8?B?VFpLcFV2cWVqbm1vRk9OYVhEckdMQWttYnJlbXVvRWtvaTk4RGU4KzVyYXRq?= =?utf-8?B?Vi9MU2dwdHlVd1AreGtvQ0RKQWdjR2htRGdqYWdjcC81VkdiUXZndW94bjJV?= =?utf-8?B?MmtTU3g3OENlajNOYzYrR2N3eGE5d2hYZTVsRFhSZWtNLzFlWWpzeHpsZjdI?= =?utf-8?B?Uy84dzI4Y0NkS1lsUVlIVndQN2c5MkN0RGw1UmdrNjJpZFkwK2Z2K3p2c1dr?= =?utf-8?Q?k4KKxqWrJNQq0vwx4rVWnL4m1ro17B6p2Y9JQt/?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR05MB59744D2727CDE7B27BC2F0FFD4969BYAPR05MB5974namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB5974.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ba62be43-c940-4e7a-53ab-08d8e010445e
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 19:52:54.2986 (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: lHcUeAB6w5SOLknbri8jqBLm2pa4hGXQG+2MmHjWnOWigLupeTELdiYrxtwkzty+YGntdSJ6MJ31wReu+23Ykw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5109
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-05_13:2021-03-03, 2021-03-05 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 clxscore=1015 adultscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103050100
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/wVOATXUEFjO8xOQNGIkoRqZycFk>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6
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: Fri, 05 Mar 2021 19:53:12 -0000

Hi Fanghong,

Please refer me to the exact text in RFC 8986 that this is violating.

What I see is:

   FIB:  Forwarding Information Base.  A FIB lookup is a lookup in the
      forwarding table.

The FIB entries can include both unicast and multicast addresses. A multicast address entry could also have the following behaviors (as non-exhaustive examples; others could also apply) just like a unicast one:


     4.6.  End.DT6: Decapsulation and Specific IPv6 Table Lookup

     4.7.  End.DT4: Decapsulation and Specific IPv4 Table Lookup

     4.8.  End.DT46: Decapsulation and Specific IP Table Lookup

     4.9.  End.DX2: Decapsulation and L2 Cross-Connect

     4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup

     4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup

     4.12. End.DT2M: Decapsulation and L2 Table Flooding

Jeffrey

From: duanfanghong <duanfanghong@huawei.com>
Sent: Friday, March 5, 2021 6:12 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; gjshep@gmail.com; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Rishabh Parekh (riparekh) <riparekh@cisco.com>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey,

Zzh4> To be exact, a multicast address with the LOC:FUNC:ARG semantics.
That’s a false use of SRv6 LOC:FUNC:ARG semantics.
Please find “FIB” and “FIB lookup” in RFC8986.
When a multicast address is used, it is no longer a “FIB lookup” and the SRv6-capability carved in a router is no longer available.

This is really outside the scope of current SRv6, and should be discussed in SPRING working group (or maybe with PIM working group jointly).

Note, besides this SRv6 misuse, there are still overhead concerns in both of the two opinions.

Thank you.

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Thursday, March 4, 2021 9:38 PM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>; Rishabh Parekh (riparekh) <riparekh@cisco.com<mailto:riparekh@cisco.com>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh4> below.

From: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>
Sent: Thursday, March 4, 2021 3:30 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey,

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291*section-2.7__;Iw!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-LUAcH5W$>)$>), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs.

So I understand the “multicast locator” you are saying is using the multicast address (rfc4291 section-2.7).

Zzh4> To be exact, “multicast locator” is the LOC part of a multicast address, and the ‘LOC:FUNC:ARG’ concept is introduced in
SPRING working group have just discussed about this:
https://mailarchive.ietf.org/arch/msg/spring/QadqCj31BgJCLicfUONQEviLno8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/QadqCj31BgJCLicfUONQEviLno8/__;!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-O6puE97$>
“If so, it really does not conform to SRv6 data plane.”

Zzh4> I am copying Rishabh, who made that comment. I am pretty sure the two are different things.

I think this is a big change and should be discussed in SPRING working group.

Zzh3> I don’t see that it needs to stacked and there is no plan to do so.

Do you also use the “multicast locator” here ?

Zzh4> To be exact, a multicast address with the LOC:FUNC:ARG semantics.

Anyway, it is a bigger change than above, with consenquences we can’t easily imagine.

I don’t think it is reasonable, far more an implementation concern I have already raised about forwarding plane or control plane.

Zzh4> Please see above.
Zzh4> Jeffrey

Thank you.


From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Thursday, March 4, 2021 3:54 AM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh3> below.

From: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>
Sent: Wednesday, March 3, 2021 8:45 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey

Overhead of encapsulation is a concern but we can talk about it later. Please see my comments  with ‘Dfh>’ below.

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Wednesday, March 3, 2021 9:20 AM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh2> below.

From: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>
Sent: Tuesday, March 2, 2021 6:46 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey and Sandy,

o In option 1, do you mean that, an entire IPv6 header is added between BIER header and the customer multicast packet with a BIER Proto value 6 used?

  Consider non-BFR case like this:
  A(bfr) ---- B(nonbfr) ---- C(nonbfr) ---- D(nonbfr) ---- E(bfr)
  You need an IPv6 Header + BIER Header + IPv6 Header + customer multicast packet encapsulation ?

Zzh2> This was discussed in the last round.
Zzh2> If both IPv6 based fragmentation and tunneling are needed, then indeed two IPv6 headers are used in the cleanly layered architecture.
Zzh2> I pointed out that when IPv6 is used for everything everywhere, then you don’t get to complain about the additional overhead. For comparison, with BIERv6, you’re using the IPv6 header even between directly connected neighbors where a simple l2 header is enough; with BIERv6, if FRR is used in the network, my understanding is you’ll also have two IPv6 headers – one pushed by the BFIR and the other pushed by the PLR.
Zzh2> If one really cares about reducing the overhead, then doing fragmentation/ESP without requiring IPv6 but in a layer independent way is a better solution and that still achieves clean layering.

  Here are some further questions about the inner IPv6 header : 1) what does "multicast locator"  mean? 2) what is the source address of the inner IPv6 address?

Zzh2> A multicast locator is similar to unicast locator but the difference is that multiple nodes can receive traffic addressed to that <locator + func/arg>.
Dfh> Still don’t understand “similar to unicast locator”, and “multiple nodes can receive traffic addressed to that <locator + func/arg>”.
Is it something like “Replication SID” in <draft-ietf-pim-sr-p2mp-policy>?
Or can you please give an example of a multicast locator showing the locator and func/arg part?

Zz3> It’s different from the “replication sid”. Per RFC 8986:

   This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128, then
   the remaining bits of the SID MUST be zero.

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291*section-2.7__;Iw!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-LUAcH5W$>)$>), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs. Obviously, we don’t need to setup multicast trees for those addresses on the transit nodes (because BIER is doing the distribution), but the BFERs have corresponding FIB entries with END.DT4/6/2M forwarding behaviors.

Zzh2> The inner address is the BFIR’s address, since it is the node that imposes that inner IPv6 header.

o In option 2, do you mean that, an IPv6 address is added between the BIER header and the customer multicast packet with a BIER Proto value TBD used?

Zzh2> Yes.

  So an IPv6 address is floating in a place outside of any IPv6 header? I don't think it's reasonable.

Zzh2> Why not? We only need the IPv6 address for service delimiting and don’t need anything else provided by a full IPv6 header. In fact, only the func/arg part is needed so a 32-bit value is practically enough; though for theoretical flexibility provided by variable length of func/arg bits, the entire IPv6 address is used.
Dfh> So I understand the “IPv6 address” is used outside of any IPv6 header, making “IPv6 address” like an MPLS Label.
Could more IPv6 addresses be directed stacked just like MPLS Label stack ?
Zzh3> I don’t see that it needs to stacked and there is no plan to do so. For example, for EVPN BUM with MPLS forwarding plane, a label stack (of two) are used to identify the bridge domain and source Ethernet Segment together, but with SRv6, they are identified with FUNC+ARG in a single SID.
Zzh3> Thanks.
Zzh3> Jeffrey

Zzh2> Jeffrey

Thank you


From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, March 2, 2021 10:32 AM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh> below.

From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of duanfanghong
Sent: Monday, March 1, 2021 8:23 PM
To: gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi,

I see this document proposes 2 options for MVPN/EVPN.
One is using the destination address to carry the ID of an MVPN/EVPN, but this means that every BFR have to be aware of the MVPN/EVPN instance, introducing state of MVPN/EVPN service and forwarding overhead in transit BFR nodes.

Zzh> This is not true. In this option, IPv6 is payload and is only exposed at the BFER. We have talked this in the last round of discussion.

The other is to use an IPv6 address after a BIER header and before the customer IP packet, however it proposes a new Proto value and new process in forwarding plane.

Zzh> BIERv6, with its companion MVPN/EVPN solution, also requires new process in forwarding plane.

I think both of the options have obvious defects,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

and thus I do not support the adoption.

Thanks !
Fanghong Duan


From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Greg Shepherd
Sent: Friday, February 26, 2021 12:37 AM
To: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Thank you all for the active discussion that brought us to consensus. This draft now addresses all of the points of discussion for the solution.

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zhang-bier-bierin6/__;!!NEt6yMaO-gk!Wz3exwJN85TEXwRgTI9gEwvjszwONVImICqBRh9GKk0mHtpLuzDK9Nf4DnO7hYbt$>

Please reply to this thread with your support/opposition of WG adoption of the draft.

Thanks,
Shep
(Chairs)


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only