Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CB31B490E; Tue, 15 Sep 2015 03:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOaqxsxnGDvO; Tue, 15 Sep 2015 03:07:53 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1EA1B490F; Tue, 15 Sep 2015 03:07:24 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so21045592wic.1; Tue, 15 Sep 2015 03:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UN8okY3N26te77QaAkvrcFfbddt1zR51G38gIeihQyA=; b=CuNsUIqNniKDDUt7Ct1iFQA0wmvlGNRPkzt5vfnV05VRhtrKCZKNN2ASsRov+sQkoH Aq7C1lzGq1Y6YFc/quqw7cOoWPe6w0eh+yuk7wCiQEVId89fl1J1DI1hv2gGZc1vEfkG ZG2iBC+cBeeJhM3YZZNZezYz14tukKUFSKK0D0vWBwR1LuOaFS7DiUUWM8Ds4ZhuGCtX oBt3x44RQGijHq5JRUvLmjN5yLcMnd3/eP8omrIWUqSvsURkA32oNbRjrR8iBjruehHx 9LD7rUKpPWkoXKztulak7rAa28/KEV4uvAj+ukhY+oyR3lfElV/J23JQHz52lQF1QcI9 HChA== MIME-Version: 1.0 X-Received: by 10.194.238.39 with SMTP id vh7mr36998110wjc.109.1442311643292; Tue, 15 Sep 2015 03:07:23 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.37.5 with HTTP; Tue, 15 Sep 2015 03:07:22 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Tue, 15 Sep 2015 03:07:22 -0700 (PDT) In-Reply-To: References: <197940302.24606.1442303093417.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 15 Sep 2015 12:07:22 +0200 X-Google-Sender-Auth: fODTvOD3JxmmbA3yiBMJLv9G-CU Message-ID: From: Robert Raszuk To: stefano previdi Content-Type: multipart/alternative; boundary=089e0141aa1a276a5b051fc659ae Archived-At: Cc: "mpls@ietf.org" , spring@ietf.org, Usman Latif Subject: Re: [mpls] [spring] Query related to SR Architecture X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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:07:54 -0000 --089e0141aa1a276a5b051fc659ae Content-Type: text/plain; charset=UTF-8 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, R. Hi, if you're an operator (SP, content, etc) and looking for a multicast solution, maybe you should have a look at BIER WG. Thanks. s. 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@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --089e0141aa1a276a5b051fc659ae Content-Type: text/html; charset=UTF-8

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,
R.

Hi,

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


Thanks.

s.


On Sep 15, 2015, at 9:44 AM, Usman Latif <osmankh@yahoo.com> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--089e0141aa1a276a5b051fc659ae--