Subject: [Bier] Comments on about PCEP and BIER

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 11 Nov 2021 16:54:58 +0000

Hi,

These are follow up comments about draft-li-pce-based-bier presented in today's BIER session.

Tony mentioned it's better to rename it to something like "bier-pcep-overlay-ip-mcast". There was also a question whether there should be one PCEP document for other multicast trees.

I think there should be one PCEP document (or a set of PCEP documents with *similar* signaling/procedures) that covers all the following:

- Set up multicast trees in default/master routing instance or VRFs, whether it is IP multicast or SR-P2MP tunnel or even mLDP tunnel
- The replication can be BIER or BIER-TE or native IP forwarding (just like in PIM case) or MPLS/SRv6 based

In fact, there is one similar document for BGP signaling already - draft-ietf-bess-bgp-multicast-controller - that does all the above using BGP (see https://mailarchive.ietf.org/arch/msg/idr/V_GLdnLnIA87wsd3fbcUKchNnTs/ about how BIER-TE can be used for replication on a multicast tree node). I am not saying that PCEP is not needed - I am just saying that similar specification can be done for PCEP.

If we take that approach, the document would be homed in PCEP, and BIER/BIER-TE relevant part is just how to specify the bitstring that a BFIR would use (i.e., 7.3.  Forwarding Indication Object) - assuming that "7.1.2.  BIER Information TLV" would be done via BGP-LS.

Thanks.

Jeffrey

Juniper Business Use Only

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 11 Nov 2021 18:10:12 +0100

It seems to me PCEP would not be used by a controller to set u the
static configruartion, such as the BFER addresses or BFIT parameters
(especially in BIER-TE where there are multple). This would AFAIK
come from YANG via NetConf or the like

So then comes the big question how we want to manage the overlay
signaling. 

I have not followed the BCP for how other solutions do this, but:

It seems to be perfectly possible to also manage the overlay signaling
via YANG. And then it should be possible to derive a PCEP solution
from the YANG solution quite formalistically.

If we start with PCEP, doing the same via YANG later on might be more
difficult. I am not sure. But it is what i worry about.

Its not that i like YANG. But it seems to me to be the safest starting
point for our BIER controller plane.

I definitely do not want to end up with inconsistent YANG and PCEP options!

Aka: nothing against PCEP work, but shouldn't we really first pledge
with all interested authors to start with the work on YANG ?

Going PCEP and maybe forgetting about YANG along the way may be
sufficient for technologies we know will ONLY be used in SP network
and where PCEP is widely used. But BIER is a new technology. We should
attempt to first concentrate on a controller plane API that most
likely allows us to reach various markets. BIER could be used in
data-centers, it could be used in embedded / industrial networks,
such as campus size video switching networks etc. pp. All those
non-legacy SP deployment casees make me worries about not having Yang
but only PCEP..

Cheers
    Toerless

On Thu, Nov 11, 2021 at 04:54:58PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[email-masked]