Minutes IETF122: bier: Mon 10:00
minutes-122-bier-202503171000-00

Celebrate for BIER 10 years’ anniversary!

IETF 122 BIER Session:
Monday Session IV 17:00-18:30 Local time, Mar 17, 2025

0, WG Status, Chairs, 10 minutes
Greg Mirsky: Very helpful summary. OAM requirements draft is important
for BIER Ping, BIER BFD, BIER performance measurements and BIER MTU
discovery drafts. The OAM drafts are ready for next step. Looking
forward to the shepherd work for OAM requirements and related drafts.

1, BIER Overlay, 20 minutes, Hooman Bidgoli
PIM Overlay:
Jeffrey Zhang: The need for the JP attributes is the open question. The
BIER header may be lost before the packet sent to PIM control plane. We
may use different BIER prefixes for different sub-domains but it may not
be normal. The results of the offline discussion among the authors is
that in default it doesn't need to use JP but in special situations we
may use JP attributes. And in MLDP use cases we needn't the attributes
at all.
Toerless Eckert: When the outer BIER header is trusty, PIM can use the
information directly other than the PIM JP attributes.
Hooman Bidgoli: From the implementation perspective it's hard to get the
BIER header information from the data plane. For the security part in
the PIM light the IP packet can be authenticated via IP header.
Stig Venaas: For the BIER IGMP/MLD overlay draft I am working on, it's
really difficult to get the information from the BIER header. We also
define some extensions for getting the information. We think it matches
the sender information that in the BIER header.
Toerless Eckert: The BFR-ID and IP address can be used for distinguish
sub-domain when there isn't many sub-domains and BFR-prefix for the same
BFIR. The adding of JP attributes may bring inconsistency.
Hooman Bidgoli: It doesn't fit when multiple BIER instances used.
Jeffrey Zhang: In normal situation PIM doesn't need the BIER header but
the IP source address.

MLDP Overlay:
Hooman Bidgoli: The shepherd review of this draft done.
Jeffrey Zhang: Two things about this draft, one is what type of label is
here, downstream or upstream assigned label. The other is I don't think
we need the interface attribute to include BIER information either.
Tony Przygienda: Implementation is the most important so please take the
discussion to the mailing list and make the decision. The second thing
is that if the generic election of multiple ingresses in PIM light draft
fit BIER well?
Stig Venaas: In PIM we use RPF to get the address of the ingress router.
I think it's not an issue for PIM overlay.

2, EANTC interop, 30 minutes, Hooman Bidgoli
Toerless Eckert: Seems like in this topology the ingress replication is
used other than P router replication.
Hooman Bidgoli: The EANTC test in last year we have a P router in the
middle and the router did replication.
Toerless Eckert: In multicast the downstream label doesn't make sense
whatever the terminology used, DCB or whatever.
Jeffrey Zhang: The key is where the label is installed, where the label
from, and where the label is going to be looked up. The BIER
encapsulation RFC only says the values used by upstream and downstream
assigned label. And we will also discuss this topic in MPLS session this
week.
Hooman Bidgoli: For Nokia there is only one incoming label type used for
BIER payload.
Tony Przygienda: For a same value label it's different for upstream and
downstream type. The distinction of upstream and downstream is real.
Zhenbin Li: Sorry that I almost forgot the details of MVPN but I
discussed this topic with my colleges. We think it's important to
distinguish the type of label.
Jeffrey Zhang: The meaning of upstream and downstream assigned label may
be changed.
Tony Przygienda: The discussion can be in mailing list and MPLS WG.
Hooman Bidgoli: For the statically assigned label, it can still be
upstream label. Maybe we can use global label other than downstream or
upstream assigned label.
Jeffrey Zhang: We needn't to change the BIER encapsulation RFC.
Hooman Bidgoli: It works when we use upstream label type.
Jeffrey Zhang: It works for wrong reason. (Will have discussion offline)

3, BIER FRR discussion, 15 minutes, Toerless Eckert
Tony Przygienda: Thanks for the work for the raising quality and make a
lot of good points. For the authors BIER already has the slice bread
when IGP underlay is used you get all the IGP protection stuff. This
draft is talking about if IGP underlay is not used in some deployments.
If you have observations that have to be addressed, please discuss with
the authors. It's a complex thing and it has a value because
implementation. Thanks again for your thorough review.
Toerless Eckert: I haven't seen enough interesting of implementation and
feasibility in implementation. We may have a second round of the draft
to make it experimental or even standard track other than informational.
Minor fits may be fine but we can really talk about the feasibility of
implementation.
Nils Warnke: From operators’ point of view, in multicast cases we often
have a sub five milliseconds deep failover. The FRR depends on what
failure occurs. We often have the failure of a fiber cut, only few
packets dropped. It's harder to get the failure about two or more steps
away. For operators 100 or 150 milliseconds is a huge gain already.
Toerless Eckert: When you have two planes so it's possible that you have
two copies arriving at the same time, there can be switchover. When you
have the arbitrary topology, I am not sure if the remote link failure
notification can be gotten. TI-LFA works for unicast so we want to use
it for multicast tunneling.
Nils Warnke: Complexity goes up when the routers gone up significantly.

Greg Mirsky: How to put all the bypass tunnels in BIER BitString when
the downstream nodes gone.
Toerless Eckert: We assume the node is still there but the link is gone,
the node bit is removed and it's already in the draft.

End of the session.