z**r
发帖数: 17771 | 1 一个multicast architecture已经很老了，基本上是全网打开，造成core router大量
mroutes，费力不讨好。
现在要转到mVPN上，可是一个VRF里的不同CE对于Multicast需求不太一样，有的要求
1mbps带宽的streaming就可以，有的需要2m或者3m甚至更高，这些高要求的在访问高带
宽的stream失败的时候，会自动去尝试低一些的stream，但是只有较低资源的CE不能访
问高带宽的stream，以前的方法是放不同级别的multicast source比如content engine
到不同的地方，然后做大量boundary，很不scalable。现在的情况下，有什么更好的办
法可以解决这个问题嘛？
不知道说清楚没有，需要其他细节的，请提问。 |
c*****i
发帖数: 631 | 2 一般这个不是都是application来定的？比如一个video同时有2个mcast tream，一个1m
，1个3m，application可以根据client在site location来选？cisco的cds好像有类似
的东西。 |
s*****g
发帖数: 1055 | 3 I can understand using mVPN to reduce multicast states on core routers, but
I don't know how vrf solution would be able to make any difference in terms
of application's bandwidth selection. |
t*******r
发帖数: 3271 | |
s*****g
发帖数: 1055 | 5 data MDT is only used to suppress traffic to PE that does not have a
receiver.
【在 t*******r 的大作中提到】
: data MDT不行么
|
k*****s
发帖数: 231 | 6 可以设定缺省的mdt, 然后设定DATA MDT 应对高带宽的需求把。基本思路可以这么走，
不过得看网络里有什么产品了。 |
z**r
发帖数: 17771 | 7 感谢各位回帖。
问题是mdt只是PE到PE的，主要限制是在CE上
【在 k*****s 的大作中提到】
: 可以设定缺省的mdt, 然后设定DATA MDT 应对高带宽的需求把。基本思路可以这么走，
: 不过得看网络里有什么产品了。
|
z**r
发帖数: 17771 | 8 agree
【在 s*****g 的大作中提到】
: data MDT is only used to suppress traffic to PE that does not have a
: receiver.
|
z**r
发帖数: 17771 | 9 this is my issue now. I need to figure out a way to satisfy the bandwidth
selection
but
terms
【在 s*****g 的大作中提到】
: I can understand using mVPN to reduce multicast states on core routers, but
: I don't know how vrf solution would be able to make any difference in terms
: of application's bandwidth selection.
|
m********d
发帖数: 188 | 10
engine
好问题，综合了应用/网络、design/operation等等问题。先说说我的理解。low-speed
ce/high
speed ce，但是应用程序不知道这些，应用程序应该只依靠能否检测到相应的
streaming来决定是否
灰化button。如果向low-speed ce过滤掉高带宽stream（一开始的boundary的作用？）
，应用程
序自然检测不到，用户也不会播放。如果保持应用程序不变，那就只能想办法让low-
speed ce只收到
低带宽的stream。为不同带宽的streaming设置不同的vpn，然后配置ce的时候，根据带
宽放到不同
vpn里（当然了，3mbps ce可以加入所有的vpn）。可行么？
【在 z**r 的大作中提到】
: 一个multicast architecture已经很老了，基本上是全网打开，造成core router大量
: mroutes，费力不讨好。
: 现在要转到mVPN上，可是一个VRF里的不同CE对于Multicast需求不太一样，有的要求
: 1mbps带宽的streaming就可以，有的需要2m或者3m甚至更高，这些高要求的在访问高带
: 宽的stream失败的时候，会自动去尝试低一些的stream，但是只有较低资源的CE不能访
: 问高带宽的stream，以前的方法是放不同级别的multicast source比如content engine
: 到不同的地方，然后做大量boundary，很不scalable。现在的情况下，有什么更好的办
: 法可以解决这个问题嘛？
: 不知道说清楚没有，需要其他细节的，请提问。
|
|
|
z**r
发帖数: 17771 | 11 把不同带宽需求的CE放在不同的VPN里，也是俺最开始想到的solution，但是这个VPN不
单单是针对multicast，还有很多别的应用，所以最后也否了这个了。最后的解决方案
还是采用了back door，绕过了VPN的限制
speed
【在 m********d 的大作中提到】
:
: engine
: 好问题，综合了应用/网络、design/operation等等问题。先说说我的理解。low-speed
: ce/high
: speed ce，但是应用程序不知道这些，应用程序应该只依靠能否检测到相应的
: streaming来决定是否
: 灰化button。如果向low-speed ce过滤掉高带宽stream（一开始的boundary的作用？）
: ，应用程
: 序自然检测不到，用户也不会播放。如果保持应用程序不变，那就只能想办法让low-
: speed ce只收到
|
m********d
发帖数: 188 | 12
engine
多说说你的backdoor办法，我们也好学习学习？
【在 z**r 的大作中提到】
: 一个multicast architecture已经很老了，基本上是全网打开，造成core router大量
: mroutes，费力不讨好。
: 现在要转到mVPN上，可是一个VRF里的不同CE对于Multicast需求不太一样，有的要求
: 1mbps带宽的streaming就可以，有的需要2m或者3m甚至更高，这些高要求的在访问高带
: 宽的stream失败的时候，会自动去尝试低一些的stream，但是只有较低资源的CE不能访
: 问高带宽的stream，以前的方法是放不同级别的multicast source比如content engine
: 到不同的地方，然后做大量boundary，很不scalable。现在的情况下，有什么更好的办
: 法可以解决这个问题嘛？
: 不知道说清楚没有，需要其他细节的，请提问。
|
m********d
发帖数: 188 | 13
engine
多说说你的backdoor办法，我们也好学习学习？
【在 z**r 的大作中提到】
: 一个multicast architecture已经很老了，基本上是全网打开，造成core router大量
: mroutes，费力不讨好。
: 现在要转到mVPN上，可是一个VRF里的不同CE对于Multicast需求不太一样，有的要求
: 1mbps带宽的streaming就可以，有的需要2m或者3m甚至更高，这些高要求的在访问高带
: 宽的stream失败的时候，会自动去尝试低一些的stream，但是只有较低资源的CE不能访
: 问高带宽的stream，以前的方法是放不同级别的multicast source比如content engine
: 到不同的地方，然后做大量boundary，很不scalable。现在的情况下，有什么更好的办
: 法可以解决这个问题嘛？
: 不知道说清楚没有，需要其他细节的，请提问。
|
z**r
发帖数: 17771 | 14 现在还是纸面上的，4月份会做一个CPOC，到时候验证一下。其实俺不喜欢这个
backdoor的方法，但是似乎目前看是唯一的解。
【在 m********d 的大作中提到】
:
: engine
: 多说说你的backdoor办法，我们也好学习学习？
|
z**r
发帖数: 17771 | 15 CPOC胜利结束，其中对于next gen multicast也有了新的方案。最后没有走backdoor的
方式，俺实在不喜欢。最后的方法是在靠近video source的地方做boundary，这样不需
要在receiver端做大量的boundary，只不过在source一端需要给每个mVPN一个入口，也
就是create多个VRF，确保每个mVPN都可以有机会接收所有stream，该block哪个stream
，只要在boudary上限制一下就可以。
开始试了在data mdt上加个access list，但是怎么也不成功，哪位说说为什么？
【在 z**r 的大作中提到】
: 现在还是纸面上的，4月份会做一个CPOC，到时候验证一下。其实俺不喜欢这个
: backdoor的方法，但是似乎目前看是唯一的解。
|
