Subject: Re: [Bier] planning

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 1 Feb 2015 09:49:19 -0000

"Cost" might not need to be analysed in a "total dollars" way, but we should be
able to give some indications at this stage of the likelihood of changes needed.

For example:
- minor mod to software that can be performed incrementally
- mod to all software in the network
- hardware upgrade at the network edges
- hardware upgrade across the whole network

This *does* require an understanding of the direction of the solution, but not
of the fine details of the solution.

In many ways this situation is analogous to the introduction of MPLS a few years
ago. And without knowing the exact mechanisms involved, we can have an idea of
how this will roll out into existing networks.

Certainly, this type of question is something that exercises the IETF when
considering new technology, especially at the lower layers. 

On the other hand, Joel, you need to understand that this work is currently
being proposed as Experimental. In that context, one of the outputs of the
experiment could be the answer to these questions.

Adrian

> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 31 January 2015 21:10
> To: Greg Shepherd
> Cc: [email-masked]
> Subject: Re: [Bier] planning
> 
> I do not know what draft it belongs in.  I named those two drafts
> because they, plus the architectural draft (which also seems the wrong
> place) are the ones I have available to understand the question.
> 
> While the details of the solution are still subject to debate, there is
> as far as I can tell general agreement on the shape of the solution we
> want to work on.  Which is, I think, a good thing.
> 
>  From my experience, without some discussion of how the costs relate to
> the benefits, the IESG is likely to have significant difficulty
> chartering work with a known high deployment cost.  Maybe we can get
> this chartered anyway?
> 
> Yours,
> Joel
> 
> On 1/31/15 3:34 PM, Greg Shepherd wrote:
> > A cost analysis of any solution must include a description of the solution.
This
> certainly does not belong in a problem statement draft.
> >
> > Sent from my iPhone
> >
> >> On Jan 31, 2015, at 12:01, "Joel M. Halpern" <[email-masked]> wrote:
> >>
> >> I have read the latest versions of the BIER problem statement and BEIR use
> case drafts.
> >>
> >> I am still looking for a document that discusses (and preferably answers,
but at
> least discusses) the cost of introducing a new data plane to address the
> problems, and the net benefit from doing so.
> >> I expect that the introduction of BIER can be justified.  But I can not
find where
> this is discussed.
> >>
> >> Yours,
> >> Joel
> >>
> >> _______________________________________________
> >> BIER mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/bier
> >
> > _______________________________________________
> > BIER mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/bier
> >
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Robinson, Dom" <[email-masked]>
Date: Mon, 2 Feb 2015 11:05:41 +0000

(Greg - I am not sure if i eventually got allowed to post this - i cant see
it in my own inbox although i did receive a mail from the BIER mailer
asking me to confirm, which i did..

Perhaps I have to post again: so please see comment below (assuming this
makes it) else can you guys perhaps forward my input to the list?

Dom

On 1 February 2015 at 01:23, Robinson, Dom <[email-masked]> wrote:

> Hi guys - i wonder if it would be worth extending the IPTV section to
> embrace content pre-placement in not only IPTV, but OTT and even
> big-software update and other such CDN activity: I stay close to IP
> Multicast specifically for this use case, and I always think it is
> interesting that while live/linear is an obvious Multicast candidate,
> pre-placing content in many caches that is known to be 'about to be heavily
> requested' is actually an extremely valuable capability - even if it is not
> live....
>
> Just a thought.
>
> While i am a n00b to the formality of an IETF draft, if you like i would
> be happy to try to extend that IPTV paragraph to try to explain that 'CDN'
> focussed use case...?
>
> Let me know - ill try to contribute before the start of next week....
>
> Kind regards
>
> Dom
>
> On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) <
> [email-masked]> wrote:
>
>> Hi,
>>
>> Below is the updated version of BIER use case draft.
>>
>> Please read and share your comments.
>>
>> Regards,
>> Nagendra
>>
>>
>>
>> On 1/30/15, 3:40 PM, "[email-masked]" <[email-masked]
>> >
>> wrote:
>>
>> >
>> >A New Internet-Draft is available from the on-line Internet-Drafts
>> >directories.
>> >
>> >
>> >        Title           : BIER Use Cases
>> >        Authors         : Nagendra Kumar
>> >                          Rajiv Asati
>> >                          Mach(Guoyi) Chen
>> >                          Xiaohu Xu
>> >                          Andrew Dolganow
>> >                          Tony Przygienda
>> >                          Arkadiy Gulko
>> >       Filename        : draft-kumar-bier-use-cases-01.txt
>> >       Pages           : 11
>> >       Date            : 2015-01-30
>> >
>> >Abstract:
>> >   Bit Index Explicit Replication (BIER) is an architecture that
>> >   provides optimal multicast forwarding through a "BIER domain" without
>> >   requiring intermediate routers to maintain any multicast related per-
>> >   flow state.  BIER also does not require any explicit tree-building
>> >   protocol for its operation.  A multicast data packet enters a BIER
>> >   domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
>> >   BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
>> >   The BFIR router adds a BIER header to the packet.  The BIER header
>> >   contains a bit-string in which each bit represents exactly one BFER
>> >   to forward the packet to.  The set of BFERs to which the multicast
>> >   packet needs to be forwarded is expressed by setting the bits that
>> >   correspond to those routers in the BIER header.
>> >
>> >   This document describes some of the use-cases for BIER.
>> >
>> >
>> >The IETF datatracker status page for this draft is:
>> >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/
>> >
>> >There's also a htmlized version available at:
>> >http://tools.ietf.org/html/draft-kumar-bier-use-cases-01
>> >
>> >A diff from the previous version is available at:
>> >http://www.ietf.org/rfcdiff?url2=draft-kumar-bier-use-cases-01
>> >
>> >
>> >Please note that it may take a couple of minutes from the time of
>> >submission
>> >until the htmlized version and diff are available at tools.ietf.org.
>> >
>> >Internet-Drafts are also available by anonymous FTP at:
>> >ftp://ftp.ietf.org/internet-drafts/
>> >
>> >I-D-Announce mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/i-d-announce
>> >Internet-Draft directories: http://www.ietf.org/shadow.html
>> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
> --
> Dom Robinson
> Co-Founder, Director and Creative Firestarter @ id3as-company ltd
> Innovation, Development, Architecture, Strategy
> for IT, Cloud and StreamingMedia Projects
> uk.linkedin.com/in/domrobinson
>
> Also Contributing Editor for www.StreamingMedia.com
> http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm
>

-- 
Dom Robinson
Co-Founder, Director and Creative Firestarter @ id3as-company ltd
Innovation, Development, Architecture, Strategy
for IT, Cloud and StreamingMedia Projects
uk.linkedin.com/in/domrobinson

Also Contributing Editor for www.StreamingMedia.com
http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm

---

From: Dom Robinson <[email-masked]>
Date: Mon, 2 Feb 2015 13:00:14 +0000

Thanks Ice / Greg  

Ok here is my first n00b stab at extending the text. I possibly need to read up on text formatting (use of brackets and terms like ‘layer4’) but perhaps let me share this as a way to refine the logic of what i feel could be included. My key thinking is that we are trying to avoid specifically involving IGMP and MBGP while still ‘allowing them’ and yet to open up for SDN / application layer control plane over-lay if a CDN operator wants to build that and still support BIER…

< feeling timid among such an esteemed crowd :) >

——

3.3.  IPTV, OTT and CDN Services  
IPTV is a service, well known for its characteristics of allowing both live and on-demand delivery of media traffic over Managed IP networks.  
  
Over The Top (OTT) is a similar service, well known for its characteristics of allowing live and on-demand delivery of media traffic between IP domains, where the source is often on an external network relative to the receivers.
  
Content Delivery Networks (CDN) operators provide layer 4 applications, and often some degree of managed layer 3 IP network, that enable media to be securely and reliably delivered to many receivers. In some models they may place applications within third party networks, or they may place those applications at the edges of their own managed network peerings and similar inter-domain connections. CDNs provide capabilities to help publishers scale to meet large audience demand. Their applications are not limited to audio and video delivery, but may include static and dynamic web content, or optimized delivery for Massive Multiplayer Gaming and similar. Most publishers will use a CDN for public Internet delivery, and some publishers will use a CDN internally within their IPTV networks to resolve layer 4 complexity.

In a typical IPTV environment the egress routers connecting to the receivers will build the tree towards the ingress router connecting to the IPTV servers.  The egress routers would rely on IGMP/MLD (static or dynamic) to learn about the receiver's interest in one or more multicast group/channels.  Interestingly, BIER could allows provisioning any new multicast group/channel by only modifying the channel mapping on ingress routers.  This is deemed beneficial for the linear IPTV video broadcasting in which every receivers behind every egress PE routers would receive the IPTV video traffic.
  
With BIER, there is no need of tree building from egress to ingress. Further, any addition of new channel or new egress routers can be directly controlled from ingress router.  When a new channel is included, the multicast group is mapped to Bit string that includes all egress routers.  Ingress router would start sending the new channel and deliver it to all egress routers.  As it can be observed, there is no need for static IGMP provisioning in each egress routers whenever a new channel/stream is added.  Instead, it can be controlled from ingress router itself by configuring the new group to Bit Mask mapping on ingress router.
  
In OTT services the receivers will often be on remote domains. These receivers may connect to the egress routers of a managed CDN that supports BIER. This will enable the CDN to efficiently deliver the content to many egress locations, in turn providing internal optimization.  
  
Where these egress routers connect directly to the Ingress BIER routers of downstream domains then a continuity of the scaling that BIER offers could be provided. This may rely on MBGP interoperation (or similar) between the egress of one domain and the ingress of the next domain, or some other SDN control plane may prove a more effective and simpler way to deploy BIER. For a single CDN operator this could be well managed in the Layer 4 applications that they provide and it may be that the initial receiver in a remote domain is actually an application operated by the CDN which in turn acts as a source for the Ingress BIER router in that remote domain, and by doing so keeps the BIER more descrete on a domain by domain basis.

---  

Looking forward to learning (a lot) from the feedback!

Hope it is useful…

Dom

Co-Founder, Director and Creative Firestarter @ id3as-company ltd
Innovation, Development, Architecture, Strategy
for IT, Cloud and StreamingMedia Projects
http://www.linkedin.com/in/domrobinson

Contributing Editor for StreamingMedia
http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm

Book out now on Wiley.com “Advanced Content Delivery, Streaming, and Cloud Services” : http://bit.ly/1r1ttEG (http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118575210,descCd-buy.html?dmmspid=25526142&dmmsmid=88793&dmmsuid=2334962)

On Monday, 2 February 2015 at 11:55, IJsbrand Wijnands wrote:

> Hi Dom,
>  
> Your email made it to the list just fine.
>  
> I think your use-case makes sense. Since the content is driven from the source side, the operator can just identify the CDN’s and push the content to it. What is nice is that you don’t need to make the CDN’s pre-join a multicast tree in order to push the data to it. There could also be a nice SDN user interface to it as well :-)
>  
> Why don’t you go ahead with preparing the text and we’ll add the content with you as co-author, ok?
>  
> Thx,
>  
> Ice.
>  
> > On 02 Feb 2015, at 12:05, Robinson, Dom <[email-masked] (mailto:[email-masked])> wrote:
> > (Greg - I am not sure if i eventually got allowed to post this - i cant see it in my own inbox although i did receive a mail from the BIER mailer asking me to confirm, which i did..  
> >  
> > Perhaps I have to post again: so please see comment below (assuming this makes it) else can you guys perhaps forward my input to the list?
> >  
> > Dom
> >  
> > On 1 February 2015 at 01:23, Robinson, Dom <[email-masked] (mailto:[email-masked])> wrote:
> > > Hi guys - i wonder if it would be worth extending the IPTV section to embrace content pre-placement in not only IPTV, but OTT and even big-software update and other such CDN activity: I stay close to IP Multicast specifically for this use case, and I always think it is interesting that while live/linear is an obvious Multicast candidate, pre-placing content in many caches that is known to be 'about to be heavily requested' is actually an extremely valuable capability - even if it is not live....
> > >  
> > > Just a thought.
> > >  
> > > While i am a n00b to the formality of an IETF draft, if you like i would be happy to try to extend that IPTV paragraph to try to explain that 'CDN' focussed use case...?
> > >  
> > > On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) <[email-masked] (mailto:[email-masked])> wrote:
> > > > Hi,
> > > >  
> > > > On 1/30/15, 3:40 PM, "[email-masked] (mailto:[email-masked])" <[email-masked] (mailto:[email-masked])>
> > > > wrote:
> > > >  
> > > > >
> > > > >until the htmlized version and diff are available at tools.ietf.org (http://tools.ietf.org/).
> > > > >
> > > > >[email-masked] (mailto:[email-masked])
> > > > [email-masked] (mailto:[email-masked])
> > > uk.linkedin.com/in/domrobinson (http://uk.linkedin.com/in/domrobinson)
> > >  
> > > Also Contributing Editor for www.StreamingMedia.com (http://www.streamingmedia.com/)
> > uk.linkedin.com/in/domrobinson (http://uk.linkedin.com/in/domrobinson)
> >  
> > Also Contributing Editor for www.StreamingMedia.com (http://www.streamingmedia.com/)
> > [email-masked] (mailto:[email-masked])

---

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Feb 2015 12:38:53 -0500

Dom,

On Mon, Feb 2, 2015 at 8:00 AM, Dom Robinson <[email-masked]> wrote:

>  Thanks Ice / Greg
>
> Ok here is my first n00b stab at extending the text. I possibly need to
> read up on text formatting (use of brackets and terms like ‘layer4’) but
> perhaps let me share this as a way to refine the logic of what i feel could
> be included. My key thinking is that we are trying to avoid specifically
> involving IGMP and MBGP while still ‘allowing them’ and yet to open up for
> SDN / application layer control plane over-lay if a CDN operator wants to
> build that and still support BIER…
>

Your contributions and willingness to engage are quite welcome.  Don't feel
timid - we were all new at one time
and we all have experience in different areas.

Regards,
Alia

> ——
>
> *3.3.  IPTV, OTT and CDN Services*
>
> IPTV is a service, well known for its characteristics of allowing both
> live and on-demand delivery of media traffic over Managed IP networks.
>
>
>
> Over The Top (OTT) is a similar service, well known for its
> characteristics of allowing live and on-demand delivery of media traffic
> between IP domains, where the source is often on an external network
> relative to the receivers.
>
>
>
> Content Delivery Networks (CDN) operators provide layer 4 applications,
> and often some degree of managed layer 3 IP network, that enable media to
> be securely and reliably delivered to many receivers. In some models they
> may place applications within third party networks, or they may place those
> applications at the edges of their own managed network peerings and similar
> inter-domain connections. CDNs provide capabilities to help publishers
> scale to meet large audience demand. Their applications are not limited to
> audio and video delivery, but may include static and dynamic web content,
> or optimized delivery for Massive Multiplayer Gaming and similar. Most
> publishers will use a CDN for public Internet delivery, and some publishers
> will use a CDN internally within their IPTV networks to resolve layer 4
> complexity.
>
>
>
>
>
> In a typical IPTV environment the egress routers connecting to the
> receivers will build the tree towards the ingress router connecting to the
> IPTV servers.  The egress routers would rely on IGMP/MLD (static or
> dynamic) to learn about the receiver's interest in one or more multicast
> group/channels.  Interestingly, BIER could allows provisioning any new
> multicast group/channel by only modifying the channel mapping on ingress
> routers.  This is deemed beneficial for the linear IPTV video broadcasting
> in which every receivers behind every egress PE routers would receive the
> IPTV video traffic.
>
>
>
> With BIER, there is no need of tree building from egress to ingress.
> Further, any addition of new channel or new egress routers can be directly
> controlled from ingress router.  When a new channel is included, the
> multicast group is mapped to Bit string that includes all egress routers.
> Ingress router would start sending the new channel and deliver it to all
> egress routers.  As it can be observed, there is no need for static IGMP
> provisioning in each egress routers whenever a new channel/stream is
> added.  Instead, it can be controlled from ingress router itself by
> configuring the new group to Bit Mask mapping on ingress router.
>
>
>
> In OTT services the receivers will often be on remote domains. These
> receivers may connect to the egress routers of a managed CDN that supports
> BIER. This will enable the CDN to efficiently deliver the content to many
> egress locations, in turn providing internal optimization.
>
>
>
> Where these egress routers connect directly to the Ingress BIER routers of
> downstream domains then a continuity of the scaling that BIER offers could
> be provided. This may rely on MBGP interoperation (or similar) between the
> egress of one domain and the ingress of the next domain, or some other SDN
> control plane may prove a more effective and simpler way to deploy BIER.
> For a single CDN operator this could be well managed in the Layer 4
> applications that they provide and it may be that the initial receiver in a
> remote domain is actually an application operated by the CDN which in turn
> acts as a source for the Ingress BIER router in that remote domain, and by
> doing so keeps the BIER more descrete on a domain by domain basis.
>
>
> ---
>
> Book out now on Wiley.com “Advanced Content Delivery, Streaming, and Cloud
> Services” : http://bit.ly/1r1ttEG
> <http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118575210,descCd-buy.html?dmmspid=25526142&dmmsmid=88793&dmmsuid=2334962>
>
> I think your use-case makes sense. Since the content is driven from the
> source side, the operator can just identify the CDN’s and push the content
> to it. What is nice is that you don’t need to make the CDN’s pre-join a
> multicast tree in order to push the data to it. There could also be a nice
> SDN user interface to it as well :-)
>
> On 02 Feb 2015, at 12:05, Robinson, Dom <[email-masked]> wrote:
>
> (Greg - I am not sure if i eventually got allowed to post this - i cant
> see it in my own inbox although i did receive a mail from the BIER mailer
> On 1/30/15, 3:40 PM, "[email-masked]" <[email-masked]>
> wrote:
>
> >
> <http://www.streamingmedia.com/>
> <http://www.streamingmedia.com/>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 3 Feb 2015 00:04:11 +0000

Hi Dom,

Thanks for the text. I will work on getting it into the use case and include you as co-author.

Thanks,
Nagendra

From: Dom Robinson <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 2, 2015 at 8:00 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Nagendra Kumar Nainar <[email-masked]<mailto:[email-masked]>>, Greg Shepherd <[email-masked]<mailto:[email-masked]>>, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt

Thanks Ice / Greg

——

---

Hope it is useful…

Dom

Book out now on Wiley.com “Advanced Content Delivery, Streaming, and Cloud Services” : http://bit.ly/1r1ttEG<http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118575210,descCd-buy.html?dmmspid=25526142&dmmsmid=88793&dmmsuid=2334962>

Hi Dom,

Thx,

Ice.

On 02 Feb 2015, at 12:05, Robinson, Dom <[email-masked]<mailto:[email-masked]>> wrote:

Dom

On 1 February 2015 at 01:23, Robinson, Dom <[email-masked]<mailto:[email-masked]>> wrote:
Hi guys - i wonder if it would be worth extending the IPTV section to embrace content pre-placement in not only IPTV, but OTT and even big-software update and other such CDN activity: I stay close to IP Multicast specifically for this use case, and I always think it is interesting that while live/linear is an obvious Multicast candidate, pre-placing content in many caches that is known to be 'about to be heavily requested' is actually an extremely valuable capability - even if it is not live....

Just a thought.

Kind regards

Dom

On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,
Nagendra

On 1/30/15, 3:40 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
wrote:

>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

--
Dom Robinson
Co-Founder, Director and Creative Firestarter @ id3as-company ltd
Innovation, Development, Architecture, Strategy
for IT, Cloud and StreamingMedia Projects
uk.linkedin.com/in/domrobinson<http://uk.linkedin.com/in/domrobinson>

Also Contributing Editor for www.StreamingMedia.com<http://www.streamingmedia.com/>
http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm

--
Dom Robinson
Co-Founder, Director and Creative Firestarter @ id3as-company ltd
Innovation, Development, Architecture, Strategy
for IT, Cloud and StreamingMedia Projects
uk.linkedin.com/in/domrobinson<http://uk.linkedin.com/in/domrobinson>

Also Contributing Editor for www.StreamingMedia.com<http://www.streamingmedia.com/>
http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier