Re: Netflix contact
Fill out the form, they will get back to you in a couple hours (they did for me, anyway) https://openconnect.itp.netflix.com/request/index.html You do need a certain amount of ingest from them before they will consider it. Regards, Michael Holstein Cleveland State University From: NANOG nanog-boun...@nanog.org on behalf of Brian R. Swan swan...@swannie.net Sent: Wednesday, January 21, 2015 12:31 PM To: nanog@nanog.org Subject: Netflix contact Is there anyone out there from NetFlix? If so, can you please contact me off list, I'd like to discuss a campus network/proxy situation that my customer has with your service.
Netflix contact
Is there anyone out there from NetFlix? If so, can you please contact me off list, I'd like to discuss a campus network/proxy situation that my customer has with your service.
Re: link monitoring and BFD in SDN networks
On Mon, Jan 19, 2015 at 22:55:04 +, Dave Bell wrote: http://www.rvdp.org/presentations/SC11-SRS-8021ag.pdf; The 802.1ag code used is open source and available on: https://svn.surfnet.nl/trac/dot1ag-utils/ Of course if you want fast failover, you need to send packets very rapidly. Every 250ms is not unreasonable. This is going to cause the control plane to get very chatty. Typically on high end routers, processes such as BFD are actually ran on line cards as opposed to on the routing engine. When a failure is detected this reports up into the control plane to trigger a reconvergence event. I see no reason why this couldn't occur using SDN. Exactly. This is something you want to do in hardware, especially if you want to do fast reroute with the OpenFlow group table. Problem is that many 1U OpenFlow switches do not support 802.1ag. We made the propotype mentioned above to show and investigate the benefits of OAM. The closed open networking foundation is supposed to be working on this, but I don't know the status because their mailing lists are closed. In SDN/OpenFlow I think a couple of things are needed: - configure 802.1ag on the interfaces (via ofconfig?) - configure OpenFlow paths (e.g. primary and backup) and also create forwarding entries for 802.1ag datagrams along those paths - configure fast reroute with the group table (ofconfig?) By doing this detection and failover are handled in hardware. rvdp
Re: link monitoring and BFD in SDN networks
On Wed, Jan 21, 2015 at 12:22 PM, Ronald van der Pol ronald.vander...@rvdp.org wrote: On Mon, Jan 19, 2015 at 22:55:04 +, Dave Bell wrote: http://www.rvdp.org/presentations/SC11-SRS-8021ag.pdf; The 802.1ag code used is open source and available on: https://svn.surfnet.nl/trac/dot1ag-utils/ Of course if you want fast failover, you need to send packets very rapidly. Every 250ms is not unreasonable. This is going to cause the control plane to get very chatty. Typically on high end routers, processes such as BFD are actually ran on line cards as opposed to on the routing engine. When a failure is detected this reports up into the control plane to trigger a reconvergence event. I see no reason why this couldn't occur using SDN. Exactly. This is something you want to do in hardware, especially if you want to do fast reroute with the OpenFlow group table. Problem is that many 1U OpenFlow switches do not support 802.1ag. We made the propotype mentioned above to show and investigate the benefits of OAM. The closed open networking foundation is supposed to be working on this, but I don't know the status because their mailing lists are closed. In SDN/OpenFlow I think a couple of things are needed: - configure 802.1ag on the interfaces (via ofconfig?) - configure OpenFlow paths (e.g. primary and backup) and also create forwarding entries for 802.1ag datagrams along those paths - configure fast reroute with the group table (ofconfig?) Fast reroute (in the form of fast failover) is supported in the OF spec (1.3+), using Group Tables. By doing this detection and failover are handled in hardware. rvdp Data plane reachability could be performed in SDN/OpenFlow networks using BFD/ Ethernet CFM (802.1ag), Y.1731, preferably on silicon if there is support (which i believe every silicon vendor should work on). It would not be ideal if these OAM frames are forwarded to a central controller. Today - I think it is done on some form of software layer (ovs, sdks) that reside on these OF switches.
Comcast contact regarding /32 nullroute
Someone/something is announcing a /32 from our IP space into comcast from a private ASN. Could someone from comcast help at least provide me some more information off-list? Normal support channels are not helping. route-server.newyork.ny.iboneshow ip bgp 74.115.212.130 BGP routing table entry for 74.115.212.130/32, version 2713438548 Paths: (13 available, best #10, table Default-IP-Routing-Table, not advertised to EBGP peer) Advertised to update-groups: 2 64650, (received used) 68.86.80.4 (metric 69635) from 68.86.80.4 (68.86.1.4) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export It should instead look like this. route-server.newyork.ny.iboneshow ip bgp 74.115.212.129 BGP routing table entry for 74.115.212.0/22, version 2674585749 Paths: (13 available, best #12, table Default-IP-Routing-Table) Advertised to update-groups: 2 29944 29889, (received used) 68.86.1.89 (metric 66845) from 68.86.80.4 (68.86.1.4) Origin IGP, metric 0, localpref 300, valid, internal Community: 7922:89 7922:2900 Originator: 68.86.1.89, Cluster list: 68.86.1.4, 68.86.1.0 -- ~Randy
Re: Office 365 Expert - I am not. I have a customer that...
On 20 Jan 2015, at 23:19, Christian Kuhtz chku...@microsoft.com wrote: I don't belong to the O365 product group, but did you look at this? https://technet.microsoft.com/en-us/library/hh852542.aspx and a blog article to go along with that: http://blogs.technet.com/b/educloud/archive/2013/08/20/do-you-have-any-bandwidth-calculators-for-office-365.aspx There's a bunch more than comes up under office 365 bandwidth calculator in your friendly neighborhood search engine. The Exchange client model, for example, looks like it can give you basics for a model based projection if you can characterize your base. biggest issue to deal with is migration traffic analysis, you need to identify biggest pst users, biggest non techie users who dont delete emails so hence have large email sets. you need to identify work times so that migration efforts can start overnight ideally. Colin
