Subject: [Bier] Comments on draft-chen-bier-frr-02.

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 16 Mar 2021 21:41:31 +0000

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.

   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).

   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

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 17 Mar 2021 12:36:06 +0100

as participant

> forwarded incorrectly - especially if you consider the approach

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 ;-)

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.

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 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.

> longer available you can simply take another one).

+1

IGPs provide very reach X-LFA support today already (well, in RFCs and
solid implementaions)

-- tony

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 17 Mar 2021 13:47:09 +0000

For a document that *describes* (not specifies) how BIER FRR would work, the key is how the BIFT is organized to achieve FRR. Different implementations have different ways, therefore what the document says is only informational not normative. Still, we need to choose a good reference model that best describes how BIER FRR works. For that, I believe a single BIFT with each entry having ECMP/primary/backup branches is the best reference (but again an implementation is free to adapt/change).

How those backup branches are built, and whether IGP/LFA/controller is used actually does not matter. The key is that BIFT is about how a BFER is reached and however you pre-determine the backup branch is fine – it does not matter whether it is using an alternative path to the primary branch’s BFR neighbor or to the BFER itself; it does not matter either if the alternative path is somehow determined with or without IGP LFA, or if a controller is involved.

Of course it is useful to document different ways to determine that alternative path, but it is only informational.

Jeffrey

From: Tony Przygienda <[email-masked]>
Sent: Wednesday, March 17, 2021 7:36 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; [email-masked]
Subject: Re: [Bier] Comments on draft-chen-bier-frr-02.

[External Email. Be cautious of content]

as participant

On Tue, Mar 16, 2021 at 10:41 PM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:[email-masked]>> wrote:
Hi Huaimo,

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 ;-)

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.

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://urldefense.com/v3/__https:/tools.ietf.org/html/draft-chen-bier-frr-00__;!!NEt6yMaO-gk!QMDiuqPpXZqvp0RA8a_krtepgZAqnFF88J0KqRP3vSZnlog-_Rp029nK3W_MT_HV$> 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.

+1

IGPs provide very reach X-LFA support today already (well, in RFCs and solid implementaions)

-- tony

Jeffrey

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!QMDiuqPpXZqvp0RA8a_krtepgZAqnFF88J0KqRP3vSZnlog-_Rp029nK3fR7rQ2j$>

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 17 Mar 2021 15:31:23 +0000

Hi Jeffrey,

    Thanks for your comments.
    My responses are inline below with prefix [HC].

Best Regards,
Huaimo
________________________________
From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Tuesday, March 16, 2021 5:41 PM
To: Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>
Subject: Comments on draft-chen-bier-frr-02.

Hi Huaimo,

Some are nits, but if I understand it correctly, the idea of using
multiple per-nbr FRR BIFTs is flawed.
[HC]: My statement below is right.

[HC]: There are two forwarding entries for each BFER in the BIFT for FRR.
One is primary forwarding entry with primary bit mask and primary next hop.
The other is the backup forwarding entry with backup bit mask and backup next hop.
The backup next hop is the next hop of the neighbor.
All the primary forwarding entries in the BIFT have thier primary bit masks and
primary next hops that are computed before the failure of a neighbor.
When the failure of a neighbor happens, the BIER packets that
go to the neighbor as its next hop are forwarded to the next hop
of the neighbor using the backup forwarding entry.
All the other BIER packets that go to the other neighbors
as their next hops are forwarded to these next hops (i.e., primary next hops)
using the primary forwarding entries.
These primary forwarding entries with thier primary bit mask and primary next hop
are computed before the failure. After the failure, all the primary forwarding entries
will be recomputed and may be different from those before the failure.
>From the time at which the neighbor fails to the time at which
all the primary forwarding entries are recomputed and updated
based on the updated network topology after failure,
Some of the BIER packets that are forwarded using the old primary
forwarding entries may be lost.

[HC]:  The draft about LFA-based BIER FRR does not mean other approaches
for BIER FRR cannot be used.

[HC]: In one implementation, we can have a BIFT pointer, which points
to the forwarding table that is used. In normal operations, the pointer
points the normal BIFT. When a neighbor fails, we can set the pointer to
the FRR BIFT for the neighbor. After the network convergence,
the normal BIFT is recomputed and updated based on the updated network
topology after the failure, we can set the pointer to the normal BIFT.

[HC]: We will update accordingly.

[HC]: We may add some text to explain.

[HC]: It seems that this is based on some RFCs. I will double check.

[HC]: We will update accordingly.

[HC]: Switching between normal and FRR BIFT is described above.

[HC]: We will update accordingly.

[HC]: We focus on single failure at one time. Multiple failures at the same
should be out of scope now. We may consider it in future.

[HC]: Compression is optional.

[HC]: Multiple failures handling is out of scope for now.

Jeffrey

---

From: iirme01 <[email-masked]>
Date: Wed, 17 Mar 2021 17:20:34 +0100

Hi all,

I'm one of the authors of [I-D.merling-bier-frr].

Hi Huaimo,

you find my response to the "lost packet"-issue inline with the prefix [DM].

Best regards,

Daniel

Am 17.03.2021 um 16:31 schrieb Huaimo Chen:
> ------------------------------------------------------------------------
> *From:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Sent:* Tuesday, March 16, 2021 5:41 PM
> *To:* Huaimo Chen <[email-masked]>; [email-masked] 
> <[email-masked]>
> *Subject:* Comments on draft-chen-bier-frr-02.
> Hi Huaimo,
>
[DM]: Why would any packets be lost? Until the forwarding entries, i.e., 
both the primary and backup ones, are updated, the backup forwarding 
entries are used for forwarding for all BFERs that are usually reached 
via the now unreachable next-hop. That is, the packets are forwarded to 
other next-hops. All other BFERs are reached via reachable next-hops 
through primary forwarding entries.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 17 Mar 2021 16:39:29 +0000

Hi Huaimo,

My comments were in three categories:

  1.  Nits - we can skip them now
  2.  About your statement about draft-merling. I need to digest your response so I'll defer that to later and/or to Michael.
  3.  The flaw in multiple per-nbr FRR BIFTs

The first two are not really important to the adoption call and the direction of the BIER FRR document, but the 3rd one is.

As you said:

In my view, the following does handle multiple failures to maximum extent:

zzh> A better way is to simply have a single BIFT for both normal and FRR

Consider that and the cost associated with building/maintaining multiple BIFTs, I would argue that the multiple per-nbr FRR BIFT approach, while perhaps acceptable for a particular implementation, is not ready yet for WG adoption.

Please note that I am not arguing against LFA based FRR. I am just saying that the reference model of a single BIFT with ECMP/primary/backup branches for an entry is the best baseline.

Jeffrey

From: Huaimo Chen <[email-masked]>
Sent: Wednesday, March 17, 2021 11:31 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Subject: Re: Comments on draft-chen-bier-frr-02.

Hi Jeffrey,

Best Regards,
Huaimo
________________________________
From: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 16, 2021 5:41 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Comments on draft-chen-bier-frr-02.

Hi Huaimo,

Jeffrey

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 17 Mar 2021 17:47:53 +0100

> Consider that and the cost associated with building/maintaining multiple
> BIFTs, I would argue that the multiple per-nbr FRR BIFT approach, while
> perhaps acceptable for a particular implementation, is not ready yet for WG
> adoption.
>
>
>
> Please note that I am not arguing against LFA based FRR. I am just saying
> that the reference model of a single BIFT with ECMP/primary/backup branches
> for an entry is the best baseline.
>

as participant and from experience

+10

in that sense merling's paper seems a better model to talk about stuff.
Plus the technical concerns about the compressed multiple BIFTs on multiple
failures

-- tony

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 17 Mar 2021 19:04:59 +0000

Hi Jeffrey,

Best Regards,
Huaimo
________________________________
From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Wednesday, March 17, 2021 12:39 PM
To: Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: Comments on draft-chen-bier-frr-02.

Hi Huaimo,

  1.  Nits – we can skip them now
  2.  About your statement about draft-merling. I need to digest your response so I’ll defer that to later and/or to Michael.
  3.  The flaw in multiple per-nbr FRR BIFTs

As you said:

[HC]: It seems that some ECMP and/or backup branches can be included

in the FRR BIFT.

[HC]: There are some extra cost. It seems that the cost may not be too high since the size of the BIFT is not big.

[HC]: The starting point is the LFA based BIER FRR.

We may include a single BIFT for comparisons.

Since this draft is experimental, we can select one

after some experiments and/or research on them are

done.

Jeffrey

Hi Jeffrey,

Best Regards,

Huaimo

Hi Huaimo,

Jeffrey

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 17 Mar 2021 19:14:09 +0000

Hi Tony,

    Thanks much for your comments.
    My responses are inline below with [HC].

Best Regards,
Huaimo
________________________________
From: Tony Przygienda <[email-masked]>
Sent: Wednesday, March 17, 2021 12:47 PM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Bier] Comments on draft-chen-bier-frr-02.

+10

in that sense merling's paper seems a better model to talk about stuff. Plus the technical concerns about the compressed multiple BIFTs on multiple failures

[HC]: The starting point of the draft is the LFA-based BIER FRR.
The compression is optional. Regarding to multiple BIFTs or a single BIFT,
we can include a single BIFT in the draft for comparisons.
Since the draft is experimental, we can choose one after
some experiments and/or research on them.

-- tony

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 17 Mar 2021 20:28:49 +0000

Hi Tony,

Best Regards,
Huaimo

as participant

[HC]: This may earn some time.

[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.

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.

+1

[HC]: The draft is about LFA-based BIER FRR. Any X-LFA supported today
can be included.

-- tony

Jeffrey

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 17 Mar 2021 21:28:51 +0100

On Wed, Mar 17, 2021 at 8:14 PM Huaimo Chen <[email-masked]>
wrote:

> ------------------------------
> *From:* Tony Przygienda <[email-masked]>
> *Sent:* Wednesday, March 17, 2021 12:47 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
> *Cc:* Huaimo Chen <[email-masked]>; [email-masked] <
> [email-masked]>
> *Subject:* Re: [Bier] Comments on draft-chen-bier-frr-02.
>
>
>
>
>
Yes, I think it's a good idea. Having both models in the draft will make
this a framework for BIER FRR [without TE] (including original work by
Menthe on single BIFT with LFA failovers). Addressing Jeffrey's technical
comments with experiments/further evolution is a good idea as well. And
adding clear sections on the use cases/feasiblity and deployment model in
case of IGP, no IGP signalling.

As you say, experiments in implementation should give us some kind of
comparison and real world input on the feasibility, +/- of different
approaches

thanks

-- tony

-- tony

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 17 Mar 2021 21:33:44 +0100

agreed on both counts

-- tony

On Wed, Mar 17, 2021 at 9:28 PM Huaimo Chen <[email-masked]>
wrote:

> *Sent:* Wednesday, March 17, 2021 7:36 AM
> 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.
>
> <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>
>
>