To continue on the topic of controller signaled multicast ...
Let me broaden the scope a bit to beyond SR-P2MP (aka tree-sid) but include IP multicast and mLDP as well.
There is already a IETF BESS WG document draft-ietf-bess-bgp-multicast-controller-04 driven by Juniper but with operator co-authors. Its earlier versions were targeted at IP multicast and mLDP - instead of using PIM or mLDP protocol for signaling, BGP signaling from controllers are used to setup IP multicast tree and mLDP tunnel. Obviously, now it's call mLDP tunnel only because the tunnel identification is still mLDP FEC, not that we're using mLDP protocol messages. -03 revision added SR-P2MP signaling.
For IP multicast tree setup by controllers via BGP, we already have a POC implementation (we have a recorded demo for anyone interested in seeing that) and are in the process of productization. We have also requested IANA earlier allocation for needed codepoints. Adding mLDP and SR-P2MP support in our implementation should not be difficult.
A good thing about using controller-signaled mLDP (instead of going to SR-P2MP) is that there is no need to change MVPN's signaling for provider tunnels. As far as MVPN is concerned, it's still mLDP tunnel - whether it is set up by traditional hop-by-hop mLDP signaling or by BGP signaling from controllers. This is good for customers who have been using mLDP all along.
I mentioned before that there is no difference in the forwarding plane between SR-P2MP and mLDP/RSVP P2MP tunnels; the difference is just that SR-P2MP use controller calculation and signaling. Now with controller-signaled mLDP, even the control plane difference has diminished - it's just how a tunnel is identified - by mLDP FEC or by SR-P2MP identification <tree-root, tree-id>. It's worth to note that mLDP FEC is very flexible and can carry a lot of (opaque) information if needed.
Now finally let's get to SR-P2MP, The concept is covered by draft-ietf-spring-replication-segment and draft-ietf-pim-sr-p2mp-policy. The former is about replication segment as a building block (it's basically the forwarding state for a tree on a particular node) and the latter is about the tree itself - how it is represented and instantiated via SR-P2MP policies. The actual signaling are specified in other documents explained below.
There are actually three flavors of signaling SR-P2MP from a controller; so in total there are four flavors of controller-signaled P2MP if we include mLDP:
- BGP-signaled mLDP tunnel: LDP/mLDP protocol is not used, but mLDP tunnel identification (mLDP FEC) is used. Covered by WG document draft-ietf-bess-bgp-multicast-controller.
- BGP-signaled SR-P2MP, also covered by WG document draft-ietf-bess-bgp-multicast-controller – we only need a new route type to signal SR-P2MP and everything else is the same.
- PCEP-signaled SR-P2MP. Covered by an individual draft that Bell/Nokia/Cisco/Juniper co-author: draft-hsd-pce-sr-p2mp-policy-01
- BGP SR-TE signaled SR-P2MP. Covered by an individual draft that Bell/Nokia/Cisco co-authors – Juniper won’t join until some major concerns are resolved: draft-hb-idr-sr-p2mp-policy-00
They’re listed in preference order that I like (obviously we want to get opinion from our customers), for the following reasons.
#1 has the following advantages:
a. Transition from existing mLDP deployment is easier. MVPN overlay signaling does not change – only the setup of the mLDP tunnel changes.
b. mLDP FEC that identifies the tunnel offers much better flexibility
c. We already have a POC implementation of draft-ietf-bess-bgp-multicast-controller for IP multicast. Extending it to mLDP (and SR P2MP for #2) is not difficult.
d. The spec is already a WG document with co-authors from Bloomberg, Verizon and Refinitiv
e. draft-ietf-bess-bgp-multicast-controllers is not explicitly tied to SR but it can be used for SR. It can be used for plain IP multicast, for plain mpls multicast, and for SR multicast.
#2 does not have the above advantage a) and b), but c), d), and e) hold for #2.
#3's advantage is that PCEP is already used for unicast – though I doubt controllers establish PCEP sessions to internal routers for unicast and now they would need *direct* PCEP sessions to all internal routers as well, which could be a concern. BGP signaling on the other hand, only needs *one* session from the controller to *any one* of the BGP speakers (typically a RR) and all signaling will go through that one.
#4 is last resort - the spec is far from mature and I’m still fighting with some issues in the -00 revision.
Hopefully now it's clear why #1 is the best solution that we could pursue to cover all use cases (we’re proposing it for 5G transport in ORAN). #2 is ok for customers who really want SR-P2MP.