Re: [mpls] [spring] Query related to SR Architecture

Usman Latif <> Tue, 15 September 2015 10:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3EA5E1B4B7B for <>; Tue, 15 Sep 2015 03:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GR-E2mu1T0i4 for <>; Tue, 15 Sep 2015 03:18:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C0681B4B77 for <>; Tue, 15 Sep 2015 03:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1442312337; bh=AZW3I13x/nBEDV1LZpFSjBqtbM0HVNbIfttMzlbi97c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=KuZnS9LTpSLjkVUUxWanFfi2TD0GG9fta4hSzUXQW+dj1MGyK6psBzdM2WC93ud7UdGO5LZWL0epheJ9dEDknii5IjqLvXLsEmQ7LQ6vbOQBY3mV5FP6KhNe85756rWuo9tjlHFvcoO4e9ZTdAalV8hJo1PISu/rPFF6R1ilpZlBpw95mEz2OJuD9GoFdZEdpaGptguQd0lZci1e0NDEtxKLf8OtPoC/ELjXveJGqYpZkDsnT1wiZlytJ0lGk4ge7jlM6OA8k4RPAqQI1GzSuHPE9ABR3cvGlGREI82Civ5bYZt76jnty2exit2rPWCmeSfFnfhUG8jqOfuASEaCVQ==
Received: from [] by with NNFMP; 15 Sep 2015 10:18:57 -0000
Received: from [] by with NNFMP; 15 Sep 2015 10:18:57 -0000
Received: from [] by with NNFMP; 15 Sep 2015 10:18:57 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 7oaV17gVM1kJHcCNKp0XBV52e5N07vVCIqToqjy9dnIWGG5BUSNPhWHZoJRh270 iFJjBqCmoD0hPqpR7J8H4X5lgsvyO9FrG1k6CZPXqrTzVnKe1FNQR4G_4emXYhvqsI5Llebi4rfZ PToUMLI0vS2njQr1X7G30EaZURpjONDReY38oNf_MO5kUPv.2CLkPAR_z9gxgtLOH9QmMUUeDXrm ZiqxSUQDrQIM2BtinNVOq7z4ROT_Y_33v2SB94d0FiHRIxKnsPZRRy.OkJQPc4sjpy8QpjN.KLE5 iFZ0qbU7qbs_8TwCq5KPCOmJloTN3YiwVa6_mDpUKohAy8132txa8rVcBLrhLPi7qL5qiYODh57N _gmYGOs6KsBc18x9BKLmZ5eEIY_4GcXIXXEX1fyRH0K_ieh.mPqmoLW8taxwXxJSxVweISv1afL7 p4_f1ARwJBp9lzAL_e77AF7egn_cLBVEqNCMzmwG_JdzYDZt.igzA64LaTjH8eQvUHZucwG3IWHu ARrMymw--
Received: by; Tue, 15 Sep 2015 10:18:57 +0000
Date: Tue, 15 Sep 2015 10:18:41 +0000
From: Usman Latif <>
To: Robert Raszuk <>, stefano previdi <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_60594_809141503.1442312321738"
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [mpls] [spring] Query related to SR Architecture
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Usman Latif <>
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Sep 2015 10:19:00 -0000

I tend to agree with Robert - The point is if we are going to advocate source routing for both unicast (using SR) and multicast (using BIER) then we have to have a comparative analysis done for what that entails in terms of existing carriers using MPLS in their core and using LDP/RSVP-TE for "both unicast and multicast at the sametime" and being able to achieve traffic engineering and fast rerouting capability for both types of traffic at the sametime using one set of protocol.
If SR and BIER are disjoint from each other, then are we providing the same (or better) level of service from a protocol perspective to the carriers to meet their demands for unicast and multicast at the sametime?
The reason I bring this up is because it would probably be the last resort for a carrier to have to deploy both SR/BIER as well as LDP/RSVP to meet their demands around both multicast and unicast traffic.


      From: Robert Raszuk <>
 To: stefano previdi <> 
Cc: Usman Latif <>;; "" <> 
 Sent: Tuesday, 15 September 2015, 20:07
 Subject: Re: [spring] Query related to SR Architecture
Stefano,How SR controller is to be aware about amount of multicast traffic on a per link basis in a given network to wisely select optimal paths for unicast ?Are you advocating completely disjoined topologies for unicast and multicast ? If so it would be great to document it somewhere ... perhaps even as BCP.Of course there are more solutions for engineered coexistance of both in the same topology, but just saying go to BIER IMHO is not sufficient :)Best,

if you're an operator (SP, content, etc) and looking for a multicast solution, maybe you should have a look at BIER WG.



On Sep 15, 2015, at 9:44 AM, Usman Latif <> wrote:

> Hi,
> I have a basic question around SPRING/SR.
> How can an IP/MPLS carrier in the market today deploy SPRING in their core network without SR being able to support efficient multicast routing in the network?
> Are we not restricting carriers by proposing the SPRING/SR architecture when we know it does not efficiently support routing of multicast traffic?
> I would like get some feedback on this point
> thanks,
> Usman
> _______________________________________________
> spring mailing list

spring mailing list