Segment Routing Circle

Hi All, 

Any thoughts or deployment on Tree-Sid for Multicast distribution in SR ? We have the network with all Juniper only Nodes at present running RSVP for both unicast and Multicast. We are running NG-Multcast. Thoughts are aligned now to move from RSVP to SR for both Unicasat and Multicast distribution. I understand Tree-Sid is next way of distibution of multicast in SR. 

Any deployment you have been through or any thougts?

Juniper readiness on Tree-Side

Is Juniper Tree-Sid is going to be standard based and can run with other vendors ?

Any intermediate steps moving from RSVP to SR for both unicast to Multicast ?

Hi pjindgar

More than a year ago we have asked several vendors including Juniper about new proposals (Tree-SID, BIER, ..) for Multicast for IPTV
use case in our MultiDomain network. Finally we decided to focus in NG-MVPN as a mucho more mature solution and ask for some
Enhancement Requests and leave emerging technologies for much later.

As you mention that you have 100% Juniper network and you are using NextGen-mVPN with RSVP-TE I don't know if you are using  or have tested HotRootStandby Feature (Draft Morin FastFailover for mVPN). I liked so much (Sub 20 msec. Much better than the Sub-50msec for hundreds of PMSI) than I proposed a PoC in the Live Network (Internal USe OLT) and still believe it's one of the best enhancements for ng-mVPN (RFC6513/RFC6514)
In case you are analyzing the possibility to evolve to Tree-SID , i don't know if you have checked the feature parity with RSVP-TE ng-MVPN (and specifically the HotRootStandby)

Regards

Miguel

While we plan to implement both Tree-SID and BIER, I would prefer Tree-SID, between Tree-SID and BIER.

In the drive towards network simplification, having a single forwarding plane packet encapsulation for all traffic types is the best.  Tree SID encapsulation is same as other SR encapsulation for unicast traffic.  On the other hand, BIER is a different encapsulation.  Unless there is a very specific use case for BIER, I would just stick to Tree-SID.

I think an interesting approach would be to look 1^st at what applications may drive the need for optimal replication trees in WANs. Both BIER and Tree-SID assume there is a need for the computation of an optimal replication tree to deliver a multicast service, presumably for bandwidth control or ???   IMHO, ingress replication over P2P tunnels (SR-TE) may be a sufficient solution and represents the most simple option. 

Also, we should consider whether it’s the SR data-plane or something else that is driving the evolution to “SR”.  If an optimal distribution tree is required, due to BW considerations, then retaining a RSVP control-plane but leveraging a SR data-plane, https://datatracker.ietf.org/doc/rfc8577 ,  may be another consideration.  rfc8577 does not include the necessary machinery for P2MP but it could be extended.

thnx,

--Colby

--Colby

I think  below are the few implemntation as per my knowledge worldwide:

1> IPTV with active/standaby

2> Multicast VPNs

3> Multicast extranets with Active/Active with end to end PATH disjointness ( Capital Market world)

3rd use case need disjointness and that can be acheiable with Controller. 

I believe other vendors are also doing Tree-Sid so interesting to know Juniper stand here and readiness ? At the end, it would be multi-vendor environment...

Hi,

In the data plane, there is NO difference between tree-sid (now called SR-P2MP in IETF) and p2mp tunnels (whether signaled by mLDP or RSVP-TE).

In the control plane, tree-sid uses controllers to calculate the tree (could be subject to many constraints and TE considerations) and signal forwarding state to individual tree nodes directly using PCEP or BGP.

So, of the two principals of Segment Routing - no per-flow state inside network and controller-driven - only the latter is used with tree-sid/sr-p2mp.

If you're not religious about removing RSVP signaling from your SR network (which would be used to signal multicast only), your existing RSVP-TE P2MP solution should work fine as is and is much more mature. If you care about control calculation, we already have a solution deployed by an European tier 1 operator - the tunnel ingress delegate the calculation to North Star, who returns explicit paths for the ingress to set up the P2MP tunnel using RSVP-TE P2MP signaling.

If you do care about moving to tree-sid/sr-p2mp, we're working on it, and we're collaborating with other vendors/operators on IETF standard so our implementation will be standard based and interoperable. Please work with PLM for specific timelines.

I think the main point here is that we have an algorithm that calculates right P2MP tree for multicast distribution.  The algorithm is agnostic to what signaling technology is used (RSVP or SR.) and is proven in the field.

Thanks Sachin. As i mentioned, we at colt keen to deploy Tree-Sid solution. We have our 100% traffic which is multicast in nature. There are 100s of Markets/stock excahnges connected to us and then we distributes their product to other customer who trade with stock exchages. So key requirements on this network:

> Active/Active Multicast feed with path disjoint

> 50ms protection

> Low latency path to be followed

Do we have any draft or any high level proposal prepared by Juniper on Tree-Sid solution ?  Let us know if we can help in defining use cases more granularly ?

Certainly, Praveen.  We will work with you to make sure your case is properly addressed.  Financial trading networks is an important segment for multicast where most of the traffic is multicast.

Hi Praveen,

Of the following three requirements:

1. > Active/Active Multicast feed with path disjoint
2. > 50ms protection
3. > Low latency path to be followed

#1 has two aspects - a) path calculation b) MVPN mechanism.

NS can already handle a) and #3, and for b) the HotRootStandby feature that Miguel mentioned earlier works well.

#2 also has two aspects - A) switch time between the two tunnels B) FRR protection for a tunnel itself

All the above are already supported with existing RSVP-TE based solution. Now to moved away from RSVP-TE, there are the following things to be done:

1. MVPN protocol&implementation enhancements to signal root/leaf information to controller calculation and to signal a new tunnel type&instance
2. Actual setup of the new type of tunnel from the controller

Let me focus on #2 above in a separate posting.

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:

1. 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.
2. 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.
3. PCEP-signaled SR-P2MP. Covered by an individual draft that Bell/Nokia/Cisco/Juniper co-author: draft-hsd-pce-sr-p2mp-policy-01
4. 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.