Re: [Bier] Comments on draft-chen-bier-frr-02.
Huaimo Chen <huaimo.chen@futurewei.com> Wed, 17 March 2021 20:28 UTC
Return-Path: <huaimo.chen@futurewei.com>
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 92EB73A1352 for <bier@ietfa.amsl.com>; Wed, 17 Mar 2021 13:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb18ZGA4gLcG for <bier@ietfa.amsl.com>; Wed, 17 Mar 2021 13:28:54 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2117.outbound.protection.outlook.com [40.107.220.117]) (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 637A43A1351 for <bier@ietf.org>; Wed, 17 Mar 2021 13:28:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TUzgHK/F7INyP17D+NWjV1MyF/tLTh8luPGojP9dOiK+IlEh4CX0cMRbJPpcnPEs8OeV8TP7K/ZabEOaqOwemX1s18ZXigEthPppWBs4G48R1vsBCqrSh9CgjNEtbuUWdHN9u7DH8Ppr1H+/e+dyWn/+mB81kC1DAJbpCyeA57LajlUTmXjgtJLhk5CJBKc0uhOq23ealhlbnDqEbmzpdWhYXGPI9kVMLraQ0QT8A/eDfu0qlkLk2muKYESmHEol5XYfUk87DvxRN4HQ99ig2k2f8U2GCsZuOB3Wx1M/1eCEwnBoklcgTw4ybA0VccUbczTCFyYrCeP1ZsKlF5/nKw==
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=Xo3LyFR8d4id6ZtynA5dUTARPObGW4NhnU29MD0rKh0=; b=SeBqoZmtvG+W1mqUfkDcY8eEpo8d4NNDecPGn1JpLc0b1GCYDIcngpt46X5RcFigTIqZBLvzX/ZZUFlQKkMFOYh0yFIO9Mhq51zjj58TEQIe+D6IdSLifWTCiFrlWXQ3HwkXM8ejlSSSLinxM/sd3bCtzyQl7XuvY7kNgMJ13KrF1MTqdNlvKQc9OYf9YfA24kDp+zX/p7eNZ/zLxZYlUZWzWPQu5Pj7FbsB+ZVD4fTvHC3YAywtbtuRjhCyDNRGLz7OPXDZrcjnzHO+1PuwnD51bOWngzkBvdsXi/TNacWBckX0j9zp6E8Do3eHhVWRUDFoey6P/BVsgdr6sLqiwg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xo3LyFR8d4id6ZtynA5dUTARPObGW4NhnU29MD0rKh0=; b=pmU2GU6OAIZFoQ5ur+g51w5GdIECxGWoYl8XNI3Waki1MLc1nGEF+yvSsrqFzhqenzne+uIxrLEDcsoZjc7Kwds6Y/+N0yuc2ifF5Rmmh9am9/WMrTEnXEbuJykcAnrb19vG+7217u1qv0vICCO0p6vpCr5UDkf1N6yRaiburmk=
Received: from MN2PR13MB4087.namprd13.prod.outlook.com (2603:10b6:208:263::16) by MN2PR13MB4365.namprd13.prod.outlook.com (2603:10b6:208:a2::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.9; Wed, 17 Mar 2021 20:28:49 +0000
Received: from MN2PR13MB4087.namprd13.prod.outlook.com ([fe80::8570:65e5:9f35:f117]) by MN2PR13MB4087.namprd13.prod.outlook.com ([fe80::8570:65e5:9f35:f117%6]) with mapi id 15.20.3955.018; Wed, 17 Mar 2021 20:28:49 +0000
From: Huaimo Chen <huaimo.chen@futurewei.com>
To: Tony Przygienda <tonysietf@gmail.com>, "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>
CC: "bier@ietf.org" <bier@ietf.org>
Thread-Topic: [Bier] Comments on draft-chen-bier-frr-02.
Thread-Index: AdcarQ4JLoZGL76CTimMbvlaYdVumQAdKmgAABAGDL0=
Date: Wed, 17 Mar 2021 20:28:49 +0000
Message-ID: <MN2PR13MB40871BBD63087E6DD318A111F26A9@MN2PR13MB4087.namprd13.prod.outlook.com>
References: <MN2PR05MB5981712D40FD05376D55784FD46B9@MN2PR05MB5981.namprd05.prod.outlook.com>, <CA+wi2hPVAsEcz+iKneQ0p4bKZnP23MKTAO46T1eRdbG9spEfUA@mail.gmail.com>
In-Reply-To: <CA+wi2hPVAsEcz+iKneQ0p4bKZnP23MKTAO46T1eRdbG9spEfUA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [73.114.233.24]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1d39387e-03e2-4edf-1589-08d8e98345ca
x-ms-traffictypediagnostic: MN2PR13MB4365:
x-microsoft-antispam-prvs: <MN2PR13MB436539C76DE148BF9D010B00F26A9@MN2PR13MB4365.namprd13.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: az8slLt8ON/kuDRLmnYG5kMAKl639r15S0F/dG5zZrwkazo7e2OahqFGZb2QbsRVDfl/X5WM6YgXyYHs8cs1SJJ0L4Z5XXDd2IPv83ERfXmkadQpODoS2picufpv4qI2gH5vf7cMQbzRWbER2QEenOVbuFamCIDnDU1MJ6BTRoZnOhabOR4CILR8ZoO4OzNkTpYn7bOfJYNJmZ0G5YSEplk0IakaD67eDvQ4DS1XSm5DVCNd2Gii64BSR0Z07wDBqqb+aYuXLlgTuMwjo/NRWn+atxFd/Z185PEuROmhn3zfF6vghj2j9gAzBYp2+ItQOtmAXaamX6+j3Qer+9v73h6e6yZKztH20ysQ7+ej1TK/51N5jEAJyL0L/uzJBeUoZBaAqijLuyFPqP8T+PjuZqHI8zAlbNSHddELneA1lsmbaluCyQTnv492/MQzcTdewyJX5hGpzIR4EOkJLnKxBAm5p5als213HAO71QqDj5hWtwgSpqFVi6ogTZBbaRasYoPW3HcWa4MNHj6vHk1envWwvPkyDmGwat4MkxcQPQaFGRuUOJUmaalrK1ORRW2I2yoT9hbTRH/+iLGkjeB2IRCSF0fIvtuvCW2udAXjO1Ii5vzB8HXfP9gMBZlZsGYO4fcHxgGrvIJxdJrTrp/5Sg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB4087.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(376002)(396003)(346002)(136003)(316002)(52536014)(478600001)(19627405001)(66556008)(8676002)(55016002)(5660300002)(6506007)(8936002)(26005)(110136005)(53546011)(86362001)(33656002)(186003)(9686003)(71200400001)(2906002)(166002)(7696005)(83380400001)(30864003)(76116006)(4326008)(44832011)(66946007)(64756008)(66446008)(966005)(66476007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: NlT13xX+z2b4bp+z0LTZ58VY+Yzf4gJanLrl0BVE0za7WWp+1FOHn0zdVDX0tcF5mDzuTXvTF73t+3GacX/8YIew+ILS9C/u7drYmDCtkfLReQKs9ihJ7v3dQO9ze886Q9xDFtDrO5+UVCmc3gH/pnZdNTJeY6dRjjLb8fWnkaITPWXBgeE9fAMQHrXf2YK35O5HF2o7WTZDWODjUiYPjy2DTLYbRCVreI3kbh/+D6/ucvxn/+TEH2WVT4IxyCErxcs17bsCCeYeDR8riiqgMdD1sXdw/4F8cgafpSLPBd6HaVbp3KIMFgyecBlpkflyWbj56ZNxAHAxymQy80P5+x3dAdtMVRFqzI2rrMtPoZyBOvFFNhTq/ls/Yg1zdTRlF28NvvafOpqSgNxPcrPqBmVNuf+4evZDW9rOFCW93hYvyYTtHcrmMWpyT8/gB9Kw9wSydPMoEJ+DgyZoI2e6YbaX7H+1vzUrPbdX1FUE6YNdEbXfmUdhkkNsug62GqXdeWCaHwEoA++innHpQny0feY1K1421++gT36pjr7fXVvSATG0rkeqj/reoX6p+Ioh8GWaTvkbbkdHEec4QXDi1RP4Z8Z2PGq/ISaR3EJu4/x10V+GXAHM5HpMgbtcuAUFj1up5CByx2e6WAyOXAhS6nPRc3J3iHO3T42l4sW7ReLUk9N1V/3TrBCNelpD8HNO/NNcL+uzJgCjOYZnUpIsVqqWMruGzAU1Yl8o+mUInp4YTgMhCbgGQdZu+PiUa2T8JpUOzVGOfzXH8nnPyVzezI3g/MgszpxCESkiQ9a4XAW+H08KrsKypo1sBYA/q0TQZlsPCJ50rtxaS55WJQELu3eAJSkQaqBHG3WnmiiIvTFKewok7ycS1d40E1IOMyGtUo/vsD5fAUgL0sbLO3x9K4OUF38ezmTp4hEhWUo7S3eG4CNtjJGChFDCGZQQR75Hsrp5w+BcYW1jrOKTs8L5W0a9t7dniiQUgSJuHZq4z7tx4aL6FWYjbJDLE8J6DmpkeBThihV+5nJBObgR6KizKOthGer/tEAnNrBG78K/UKwg4UicWEdazLtqgETefWZgLUuPmqRXga1wbpq48vSIvq9mMbTZnNaVRKH417Cr18e/xcxd1i/BTzNZwvOLM+W/c0lqTg69obwGp3xbYtOTtUIRATzG45vHo7PLrUmnciuW28pGKDzvVXegOHhJKtgTBbpkuddlXr7VrqGEntUPPKnpJanvha94+geSimsf60KZpBqIxOiw6iqRMtWRUnu/gei+tdWcSwVvTKe1F7LwyqnGqHPzWrI8dD9Ye+KuDg7KKH4f8YdxDFXDCeZqqJVe
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB40871BBD63087E6DD318A111F26A9MN2PR13MB4087namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB4087.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d39387e-03e2-4edf-1589-08d8e98345ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 20:28:49.2510 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3gSF++aGGKvA0qc0ZdDjWD6RfhTbtxjndp75slWM61A6Vkv+xrXbPhljI/m0F2w5153SEN/NO0uK2RjKqhPtUw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB4365
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/VsTPRmUi-26VSWrBPzdnLXzPvT0>
Subject: Re: [Bier] Comments on draft-chen-bier-frr-02.
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: Wed, 17 Mar 2021 20:28:58 -0000
Hi Tony, Thanks much for your comments. My responses are inline below with [HC]. Best Regards, Huaimo ________________________________ From: Tony Przygienda <tonysietf@gmail.com> Sent: Wednesday, March 17, 2021 7:36 AM To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org> Cc: Huaimo Chen <huaimo.chen@futurewei.com>; bier@ietf.org <bier@ietf.org> Subject: Re: [Bier] Comments on draft-chen-bier-frr-02. as participant On Tue, Mar 16, 2021 at 10:41 PM Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote: Hi Huaimo, Please see my comments below. Some are nits, but if I understand it correctly, the idea of using multiple per-nbr FRR BIFTs is flawed. [I-D.merling-bier-frr] proposes a tunnel-based fast re-route (FRR) ... Before the primary bit mask is recomputed and updated, some of BIER packets may be forwarded incorrectly. Would like to see elaborations on why some of the packets may be forwarded incorrectly - especially if you consider the approach at the end of this mail. it seems to me just a bit of a wild assertion. IGPs are the fastest way to distribute topology info unless every node is somehow hooked up to a "controller" which is basically a degenerate IGP graph (super edge connected AFAIR). so one could construct a case where every node before running IGP talks to controller and that can compute & install backups first while IGP is converging. I doubt for the moment practicality of something like this but there is little account for taste in networking ;-) [HC]: This may earn some time. So I think a framework should explain that a unicast nexthop when running IGP has already protection (all LFA variants) with BIER for free if implemented correctly and given maturity of that technology it's an easy choice. If/when that cannot be used (IGP is not in place) etc then the framework document should explain protection schemes that could be built directly into BIFT (and I agree as informational for the moment and we see whether it goes from there). The same document IMO should also cover TE-FRR which is a bit of a more interesting case. [HC]: If the framework is a separate document, it should cover BIER FRR and BIER-TE FRR. If the framework is added into BIER FRR draft, it seems better to just cover BIER FRR. All the BIER packets are forwarded using the BIFTs and the forwarding procedure specific for BIER. All the IP packets are forwarded using the normal FIBs and the forwarding procedure specific for IP. When/if IP FRR is provided, it is through the FIB with LFA and the forwarding procedure for IP. When there is a failure, IP packets are protected by IP FRR through the FIB with LFA and the forwarding procedure for IP. All the BIER packets are still forwarded using the BIFTs, which do not have backup next hops. They are not protected since they are not forwarded using the FIB with LFA. We can use the LFA backup next hop in the FIB for IP for free in the corresponding forwarding entry in the BIFT for BIER if IP FRR is supported in the network. If/when IP FRR is not provided in the network, the LFA backup next hops are computed for the BIFTs. After the BIFTs have the LFA backup next hops and the forwarding procedure for BIER is enhanced for BIER FRR, all the BIER packets are protected. BTW, the Menthe paper seems bit misleading in this respect, it somehow doesn't show that the NH unicast is easily protected via IGP FRR @ no additional storage or complexity cost. The section VI on LFA based FRR is literally this AFAIS, modulo squeezing the protection into BIFT NH (which is with IGP not a _real_ nexthop but indirection to IGP neighbor if implemented smartly). yes, all the discussion on compressed backup etc is fine if there's no IGP but to try to replicate what IGPs do today already does not seem like any saving (unless one costrues again a convoluted case of underlying IGP without LFA available/enabled). https://tools.ietf.org/html/draft-chen-bier-frr-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-bier-frr-00&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C0a7430f6b7114910a3a208d8e938f01b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637515778055504267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6iJobZAFGq3ORT3BpvwvnqSbRy7ZFUc7Ws5uKFUxzjw%3D&reserved=0> itself seems very implementation specific (and subtly flawed, I think Jeffrey picked @ it carefully in rest of this email) but describes largely same concept AFAIS so it looks to me those drafts could be esaily joined into a common bier-frr draft convering all the approaches and bier te frr as well. [HC]: It is OK for me to combine those drafts into one covering all the BIER FRR approaches. For BIER-TE FRR, it seems different from BIER FRR. It would be better to have a separate one. This document describes a mechanism for fast re-route (FRR) protection against the failure of a node or link in the core of a BIER domain, which resolves the above issue. It is based on LFA, which is called LFA-based BIER-FRR. Unicast FRR can be based on many mechanisms, and BIER FRR can simply follow suit. It does not have to be limited to LFA or tunnel - simple ECMP can also work if there are ECMP paths (if an ECMP branch is no longer available you can simply take another one). +1 IGPs provide very reach X-LFA support today already (well, in RFCs and solid implementaions) [HC]: The draft is about LFA-based BIER FRR. Any X-LFA supported today can be included. -- tony In normal operations, the normal BIFT is used to forward BIER packets. When a neighbor fails, the BFR as PLR uses the FRR BIFT for the neighbor to forward BIER packets. For a BIER packet to traverse the BFR and the failed neighbor, the BFR reroutes the packet around the failed neighbor using the FRR BIFT for the neighbor. For a BIER packet to traverse the BFR and any other neighbors, the BFR forwards the packet to its expected next hop neighbors using the forwarding entries with these BFR neighbors in the FRR BIFT. I do not see why there is a need for per-neighbor FRR BIFT. It is also not clear how the switch between normal BIFT and FRR BIFT is done - in fact I think it is flawed - more on that later. From the BIRT on the BFR, a "Bit Index Forwarding Table" (BIFT) is derived. In addition to having a route to a BFER in each row of the BIFT which is the same as the BIRT, it has a "Forwarding Bit Mask" (F-BM) in its each row. For the rows in the BIRT that have the same SI and the same BFR-NBR, the F-BM for each of these rows in the BIFT is the logical OR of the BitStrings of these rows. Need to be a bit more strict here. A row in BIFT is about a particular BFER, which could be reached via two ECMP nbrs. The F-BM is really for a nbr, not for a row. See Figure 6 in RFC8279. When a BFR receives a packet, for each BFER k (from the rightmost to the leftmost) represented in the SI and BitString of the packet, if BFER k is the BFR itself, the BFR copies the packet, sends the copy to the multicast flow overlay and clears bit k in the original packet; otherwise the BFR finds the row (i.e., forwarding entry) in the BIFT for the sub-domain using the SI and BitString as the key or say index, and then copies, updates and forwards the packet to the BFR-NBR (i.e., the next hop) indicated by the row (i.e., forwarding entry). Strictly speaking, the BIFT is for <sub-domain, SI> (if we ignore different bitstringLen), and the lookup key is 'k' not the entire bitstring. The FRR-BIRT for BFR-NBR X of the BFR considers the failure of X and maps the BFR-id (in the sub-domain) of a BFER to the BFR-prefix of A nit here - strictly speaking it's not that you map the bfr-id to bier prefix in BIRT. BIRT is built based on how a BIER prefix is reached, and the mapping is the other way around - you map the prefix to a BFR-id when you derive the BIFTs from BIRT. The BFR may build the FRR-BIRT for BFR-NBR X by copying its BIRT to the FRR-BIRT first, and then change the next hop with value BFR-NBR X in the FRR-BIRT to a backup next hop (BNH) to protect against the failure of X. In other wards, for the BFR-id of a BFER in the FRR- BIRT for BFR-NBR X, if the next hop BFR-NBR on the path to the BFER is X, it is changed to a BNH when there is a BNH on a backup path to the BFER without going through X and the link from the BFR to X. If there is not any BNH to a BFER to protect against the failure of X, the next hop BFR-NBR X to the BFER in the FRR-BIRT for BFR-NBR X is changed to NULL. For a multicast packet having the BFER as one of its destinations, if the next hop BFR-NBR to the BFER is NULL, the BFR does not send the packet to the next hop BFR-NBR NULL but drops it when X fails. A nit - it's not that the packdet is dropped. Rather, the bit for that BFER is simply cleared. So for BFERs not affected by X's failure, they're still present in X's FRR BIFT and are the same as in the normal BIFT. Keeping these per-nbr FRR BIFTs with those unaffected entries just does not make sense - you might as well have one BIFT in which each row includes ECMP/backup branches. Of course, this is implementation details/preferences, but: - it's not good to specify this controversial implementation details - switching to using FRR BIFT is actually flawed - see later comments. The forwarding procedure defined in [RFC8279] is updated/enhanced for a FRR-BIFT to consider the case where the next hop BFR-NBR to a BFER is NULL. For a multicast packet with the BitString indicating a BFER as one of its destinations, the updated forwarding procedure checks whether the next hop BFR-NBR to the BFER in the FRR-BIFT is NULL. If it is NULL, the procedure will not send the packet to this next hop BFR-NBR NULL but drop the packet. A nit - not "drop the packet" but simply clear the bit. Additionally, even when you do not support FRR you also have situations whwere some BFERs are simply not reachable. In other words, clearing the bit for those BFERs is the base requirement/assumption in RFC8279, not a update/enhancement. The FRR-BIFTs will be pre-computed and installed ready for activation when a failure is detected. Once the BFR detects the failure of its BFR-NBR X, it activates the FRR-BIFT for X to forward packets with BIER headers and de-activates its BIFT. After activation of the FRR- BIFT, it remains in effect until it is no longer required. Let's say this BFR has several BFR neighbors (including X and W). X fails first and W fails instantly after that. Which FRR BIFT do you use? X's FRR BIFT does not consider W's failure and W's FRR BIFT does not consider X's failure, so using either one alone has problems. Notice that this is different from the typical "multiple failure" scenario - it's not that X and W may depend on each other but it could be that some BFERs have a common backup neighbor Y, yet if you use X's FRR BIFT then those BFERs normally reachable via W are not protected now that W also fails. Similarly, if you use W's FRR BIFT then those BFERs normally reachable via X are not protected now that X also fails. That's why a single BIFT should be used for both normal and FRR forwarding, just like in unicast case. The number of entries in a FRR BIFT is the number of BFERs. Each FRR BIFT on a BFR can be compressed through combining all the entries with the same BFR-BNR and F-BM into one entry. The number of entries in a compressed FRR BIFT is the number of neighbors of the BFR minus one. For example, the compressed FRR-BIFT for BFR C on BFR B is shown in Figure 7. The number of entries in it is three, which equals the number (four) of neighbors of BFR B minus one. +----------------+---------+------------+ | BFR-id | F-BM | BFR-NBR | | (SI:BitString) | | (Next Hop) | +================+=========+============+ | 1, 4 (0:01001) | 01001 | G | +----------------+---------+------------+ | 2, 3 (0:00110) | 00110 | E | +----------------+---------+------------+ | 5 (0:10000) | 10000 | A | +----------------+---------+------------+ Figure 7: Compressed FRR BIFT for BFR C on BFR B For a BIER packet with a BFR-ID as a destination, the entry containing the BFR-ID is used to forward the packet. Not sure of the benefit of compression here. It makes the lookup more complicated. If the memory consumption is a concern, just get rid of per-nbr FRR-BIT and use a single one. Additionally, the F-BM and BFR-NBR information can be considered forwarding information that can be pointed at by multiple BIFT entries, so the above compression does not really give you much savings. Once BFR B detects the failure of its BFR-NBR X, after receiving the packet from BFR A, BFR B copies, updates and sends the packet using the FRR-BIFT for X on BFR B to avoid X and link from B to X according to the forwarding procedure defined in [RFC8279]. For example, once BFR B detects the failure of its BFR-NBR C, after receiving the packet from BFR A, BFR B copies, updates and sends the packet to BFR G and BFR E using the FRR-BIFT for BFR C on BFR B to avoid C and link from B to C. See earlier comments about failure of multiple neighbors (who do not use each other for backup). Using a per-nbr FRR BIFT not only is unnecessary, but also has problems. A better way is to simply have a single BIFT for both normal and FRR forwarding. Each entry has some ECMP and/or primary/backup branches, and you simply use another ECMP branch or a backup branch when the normally used branch fails. A backup branch can go through completely different nbr, or go through the same neighbor but via a tunnel. Jeffrey Juniper Business Use Only _______________________________________________ BIER mailing list BIER@ietf.org<mailto:BIER@ietf.org> https://www.ietf.org/mailman/listinfo/bier<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C0a7430f6b7114910a3a208d8e938f01b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637515778055514220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4K8XatJm5IE%2BxM5EyPAsTziosEnmVi70LiyTgUKtjgc%3D&reserved=0>
- [Bier] Comments on draft-chen-bier-frr-02. Jeffrey (Zhaohui) Zhang
- Re: [Bier] Comments on draft-chen-bier-frr-02. Tony Przygienda
- Re: [Bier] Comments on draft-chen-bier-frr-02. Jeffrey (Zhaohui) Zhang
- Re: [Bier] Comments on draft-chen-bier-frr-02. Huaimo Chen
- Re: [Bier] Comments on draft-chen-bier-frr-02. iirme01
- Re: [Bier] Comments on draft-chen-bier-frr-02. Jeffrey (Zhaohui) Zhang
- Re: [Bier] Comments on draft-chen-bier-frr-02. Tony Przygienda
- Re: [Bier] Comments on draft-chen-bier-frr-02. Huaimo Chen
- Re: [Bier] Comments on draft-chen-bier-frr-02. Huaimo Chen
- Re: [Bier] Comments on draft-chen-bier-frr-02. Huaimo Chen
- Re: [Bier] Comments on draft-chen-bier-frr-02. Tony Przygienda
- Re: [Bier] Comments on draft-chen-bier-frr-02. Tony Przygienda