- Test - lists.nanog.org

Re: [funsec] Not so fast, broadband providers tell big users (fwd)
by Scott Weeks 14 Mar '07

14 Mar '07

--- christopher.morrow(a)verizonbusiness.com wrote: On Tue, 13 Mar 2007, Scott Weeks wrote: > > On Mar 13, 2007, at 8:17 AM, Chris L. Morrow wrote: > > > > > what business drivers are there to put more bits on the wire to > > > the end user? > > For us in Hawaii IPTV will drive that. for the service from the provider, or from remote places (example google-tv which may or may-not exist, just an example of 'not $TELCO') --------------------------------------------- For service from the provider to the customer, but the bits will still goto the user. We also have the 'remote places' problem. For example: www.hawaiiweb.com/maui/html/sites/kaupo.html but for the most part population-wise we'll get to the folks homes and workplaces. scott

2 1

Re: [funsec] Not so fast, broadband providers tell big users (fwd)
by Scott Weeks 14 Mar '07

14 Mar '07

--- christopher.morrow(a)verizonbusiness.com wrote: > On Mar 13, 2007, at 8:17 AM, Chris L. Morrow wrote: > > > what business drivers are there to put more bits on the wire to > > the end user? Getting in late here... For us in Hawaii IPTV will drive that. scott

2 1

Re: [funsec] Not so fast, broadband providers tell big users (fwd)
by Daniel Senie 13 Mar '07

13 Mar '07

At 02:15 PM 3/13/2007, Todd Vierling wrote: >On 3/13/07, Roland Dobbins <rdobbins(a)cisco.com> wrote: >> > There are other technologies better >> > suited to rural deployment, such as satellite, powerline, some cable, >> > or even re-use of the previous generation's ADSL gear once metro areas >> > are upgraded. >> >>Or something like WiMAX? > >Depends on how rural the area is. Some parts of the US have >problematic terrain and *very* sparse population; there, the cost >would far outweigh the subscriber uptake. Should someone want >bandwidth in such an area, powerline or satellite are probably better >choices. You've mentioned powerline a few times. Care to expand on the business case for BPL? One vendor has gear which does not blanket the RF spectrum with noise (Motorola) but requires equipment on the local feeder network, thus much equipment density. Other vendors also seem to need fairly high equipment density. The trials to date have been in areas with other carriers already present, and have caused widespread RF interference (the equipment vendors have spent much PR money trying to refute the interference evidence). As for satellite, have you ever actually used a DirecPC or similar service? The latency makes such services useful mostly for casual web browsing and for email service. You can't use VPNs, VOIP, or most other more interesting services. And the companies necessarily have severe, enforced "fair use" throttling to ensure more than a few users can use the service. >(I don't mention cell-based wireless technologies, because the >providers in that market space haven't truly awakened to the >possibility of fixed cell termination sites for broadband-type access. >That is generally seen as a congestion threat, not an opportunity, by >the carriers.) Sprint seems to be doing an OK job in this regard, actually. Their "unlimited" contract seems to not have strings attached like Verizon Wireless (who think "unlimited" means "use it occasionally for email, but we really didn't mean "unlimited."). If Sprint provided more cell coverage in the small towns of the Berkshires, then their EVDO service with a router and data card would be a reasonable, if a bit pricey, way to get broadband-like performance to many more people. Alas, there seems to be no economic incentive for them (or anyone else) to provide even voice wireless services in that area. Last year Verizon put up a cell site in Great Barrington, MA, resulting in an article about it in the Berkshire Eagle. First time many people had been able to use their cell phones in south Berkshire.

2 1

Verizon Abuse contact
by Zak Thompson 13 Mar '07

13 Mar '07

Can someone from Verizon's abuse department contact me off list? Cheers, Zak Thompson Yellow Fiber Networks

2 1

Philly area Broadwing / Focal / Level3 fiber cut?
by Jeff Weisberg 13 Mar '07

13 Mar '07

| I cannot even call their toll-free help lines, as the figer cut apparently | is affecting that as well, according to their local NOC people, who cannot | chd any more light on this. I was able to get through to their NOC. there was a cut, but the person I spoke with did not have much in the way of details. broadwing master ticket #59210 --j

2 1

Foundry XMR/MLX Experience - Update
by Robert Boyle 13 Mar '07

13 Mar '07

Hello all, In December 2006, I asked for input from people on their experience with Foundry since we were leaning toward them for our new core router standard for our current backbone upgrade cycle. About 50 people replied and asked me to update them with my choice and information I gathered since they were also considering Foundry. We also looked at Juniper and Cisco's offerings, but they weren't competitive in the price/performance ratio and Juniper's annual maintenance fees were astronomical and their sales people arrogant. The feedback on Force10 from people who said they were also looking at them was that their software was not mature or stable enough and their financial picture was questionable while the hardware per port cost was higher than Foundry. I never contacted Force10 based on the premilinary feedback I received from their actual users. Everyone who actually used Foundry loved their boxes. Two people said stay away from Foundry, but upon further inquiry, one had not actually personally used any Foundry gear and the other had a problem, but never contacted Foundry support for help. Foundry openly admits that they had some quality problems in the past with certain older hardware models which had a bad ASIC production run and those issues have been addressed and the customers made whole. That certainly seems to be the case based on the feedback I received. I am very pleased with the current generation of hardware. We also liked the fact that the Foundry CLI language is basically IOS with a Santa Clara accent which minimizes staff training requirements. We love our Cisco gear, but it just isn't price competitive for high density and line rate without any oversubscription. I also don't like the imminent, uncertain, and nebulous maybe/maybe-not IOS feature-set code-base split between the 7600 and 6500 series platforms. We evaluated a Foundry MLX, but we decided to purchase an XMR which is the big brother of the MLX. The main difference between the MLX and the XMR is that the XMR will take 1 million routes in the CAM vs. 512k for the MLX. The XMR also has a higher limit on the number of BGP peers and it has more RAM. Both models run the exact same code. The XMR will also so MPLS and IPV6 routing (in hardware) without any special feature licenses. You buy the box and you can do anything it is capable of. I like that way of doing business too. Our evaluation period was flawless. We didn't run into any bugs and the box just worked as advertised. In fact, I copied and pasted a Cisco config to get the box up and running and I think I only had to change 3 or 4 lines. We told Foundry we also wanted 100Mbit SM SFP support and BFD support and they were both included in the new release of the software. It works with ISIS, BGP, and SNMP without any issues at all. We have been very pleased. They work with any SFP optics although the official position is that only factory optics are supported. We just purchased four XMR routers which we will be deploying shortly. The MLX which has been in production for almost 3 months has had zero issues interoperating with our Cisco gear including 7200s and 6500s speaking ISIS and BGP. Foundry's support team goes above and beyond. They have been extremely helpful with any questions and they really want to make sure their customers are happy and willing to recommend their products. I have been converted. We are also planning to roll out MPLS once the routers are in place. POS cards are out now too in OC12/OC48 and OC192. The chassis is 40GE and 100GE capable and will support the cards once they are released. Here are some quotes which I received: "We're looking at replacing our current routers as well. I'm currently looking at Force10 (E600), Foundry (XMR), and Juniper (MX960). Since we're primarily a commodity internet shop, we don't need MPLS today, which is the only reason I'm considering Force10. We use Foundry for L2 today and have had great luck using 3rd party SFPs. We buy all our SFPs from Calix (OEM'd Finisar)." "Like every vendor, Foundry has it's quirks but they're putting real efforts into getting things handled. We've worked closely with them for the past 3 years and helped them understand better how to move from enterprise support into the ISP market. They're still doing a little catch up in code but getting there pretty fast. I'd venture that by the end of 2007, they will have every bit of feature support you could find from juniper or cisco. Many of the most important things for even a large network are there now and are being beaten to hell and back in various people's networks. The end result is that the bugs that make it in there are getting ferreted out pretty fast." "A summarization of the answers you receive would be great. We have a few of the MLX16 and MLX8's in our lab right now, but not in the same capacity that your using them, so I can't comment on the number of BGP peers and how they handle it. We're testing MPLS currently, mainly VPLS functions, and soon will be doing several gigs of IP video with Multicast, and hopefully MSDP and Anycast RP. Currently, they don't have BFD support for either OSPF or IS-IS, but our SE is checking on the software release dates. Also, we just got in some Ineoquest boxes that can generate/monitor 10Gb of IP video, so we can at least put some stress on our links." (BFD is now supported in 3.3) "I don't know much about Foundry other than I see them installed in racks semi frequently (more and more these days). We're taking on a project in Q1 to upgrade or replace all of our Cisco Cataylst switches. We're going to do a full market eval, but from what I've seen so far I highly doubt we'll be sticking with Cisco Cataylst switches (they're too big and bulky and just not very Service Provider focused)." "MLX should work. XMR will go slightly farther (more CAM for routes). Foundry will have different bugs from Cisco." "I cannot speak exactly for the MLX, however we have used Foundry gear for several years now and have seen little to no problems. In our network we have NetIron40Gs and BigIron RX8s in the core. They have supported so far several million routes of BGP across 15 eBGP peers. Scaling the number of peers should not be a problem since on the MLX you have more TCAM for supporting a huge number of routes and peers on each line card. We have also found that 3rd party SFPs and XFPs have not been a problem at all unless they are Cisco. Since I do not run ISIS, I cannot comment on that at all, we run OSPF and have found no problems there either. Hope it all works out for you." "********* uses XMR's in their core network (practically identical to MLX)" "As Bevan indicated, we haven't pushed these too hard yet. We did push them with a SmartBits analyser early on to test some specific QoS things (which came up clean), but haven't stressed them in production yet. One gotcha is that the code doesn't support hit-less software upgrades yet - the newly released code supports hitless upgrades for quite a few features, but not for MPLS. It's coming - just not there yet. We're not using them to take multiple full BGP views in a transit-like configuration, so your mileage may vary." "The hardware is pretty stable, we've only had a handful of hardware swaps in 3 years of use. The software is about as stable as any software... although they tend to move on to new feature versions rather quickly and don't necessarily have deep support on older versions. That being said, they will roll a bug fix into a version you need if you request it. Their TAC is so-so. Sometimes you'll get a great tech and sometimes you'll get a lazy one. If you work their system you'll get what you need. Also, their SE's are very involved and tend to be dedicated professionals who will do whatever it takes. We got the MG8's very early in the product life-cycle. At one point we had a strange problem. Foundry sent the product engineer to ********* to troubleshoot the issue in person. We just had a hardware line card fail. While the TAC didn't RMA it properly, the SE/Sales team saw that things weren't getting handled properly and our Salesman flew the replacement down (we're in *****, they're in San Jose) personally to make sure we had it in time. When we decided to go with Foundry, their service was a key element of our decision. They've overall lived up to the hype." So far we have also been very pleased. I'll send out another update once we get our XMRs deployed and MPLS enabled. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin

1 0

Philly area Broadwing / Focal / Level3 fiber cut?
by up＠3.am 12 Mar '07

12 Mar '07

I cannot even call their toll-free help lines, as the figer cut apparently is affecting that as well, according to their local NOC people, who cannot chd any more light on this. I suprisingly just found that I can connect to my colo servers there if I first ssh to a server I have in germany. However, traceroutes from here (comcast) stop here: 5 po-70-ar01.ivyland.pa.panjde.comcast.net (68.86.208.145) 13.165 ms 7.634 ms 17.193 ms 6 po-10-ar01.401nbroadst.pa.panjde.comcast.net (68.86.208.33) 9.913 ms 7.899 ms 13.856 ms 7 12.118.114.49 (12.118.114.49) 18.673 ms 113.943 ms 201.091 ms 8 tbr1-p012301.phlpa.ip.att.net (12.123.137.210) 22.029 ms 16.856 ms 14.122 ms 9 tbr1-cl8.n54ny.ip.att.net (12.122.2.17) 15.477 ms 20.529 ms 21.079 ms 10 ggr1-p330.n54ny.ip.att.net (12.123.0.81) 21.812 ms 13.032 ms 13.623 ms 11 att-gw.ny.broadwing.net (192.205.32.106) 17.127 ms 16.489 ms 12.97 ms 12 s0-3-0.c1.nwyk.broadwing.net (216.140.10.193) 15.672 ms 17.7 ms 12.865 ms 13 so7-0-0.a1.nwaknj.broadwing.net (216.140.8.198) 32.475 ms 17.576 ms 13.366 ms 14 g1-2-0.core2.jfk.foc.broadwing.net (216.140.10.110) 23.748 ms 17.769 ms 18.252 ms 15 * * * 16 * * * If anybody can shed any light, please cc a reply to james(a)ns2.pil.net Thanks, James Smallacombe PlantageNet, Inc. CEO and Janitor up(a)3.am http://3.am =========================================================================

1 0

First Middle East Network Operators Group (MENOG) Meeting in Bahrain
by Paul Rendek 10 Mar '07

10 Mar '07

[Apologies for duplicate e-mails] Dear Colleagues, The Middle East Network Operators Group (MENOG) will hold its first meeting from 3-5 April 2007 at the Diplomat Radisson SAS Hotel in Bahrain. Hosted by 2Connect, the event will offer network engineers and other technical staff the opportunity to share their knowledge and experiences, and identify areas for regional cooperation. MEETING AGENDA -------------- A preliminary agenda is now available online, however there are still presentation timeslots available. If you are interested in participating as a presenter please contact us as soon as possible at <contact(a)ripe.net>. The preliminary agenda is available at: http://www.ripe.net/meetings/menog/meeting_plan.html SPONSORSHIP INFORMATION ----------------------- The MENOG meeting is non-commercial and relies on the contributions of sponsors. By participating as a sponsor, you will be supporting a valuable regional forum, while exposing your organisation to many of the Middle East's leading Internet professionals. If you are interested in becoming a sponsor please contact us at <contact(a)ripe.net>. For more information on becoming a MENOG 1 sponsor, see: http://www.ripe.net/meetings/menog/sponsors.html REGISTRATION ------------- Registration for MENOG 1 is free and open to everyone. You can register online at: https://lirportal.ripe.net/lirportal/meeting/registration/meeting.html?id=42 HOTEL ACCOMMODATION -------------------- MENOG 1 attendees who wish to stay at the Diplomat Radisson SAS Hotel can take advantage of a reduced room rate. More information on this package, including the hotel booking form, can be found at: http://www.ripe.net/meetings/menog/meeting-venue.html MENOG 1 will be modeled on meetings held by NANOG (North American Network Operators Group) in North America, and SANOG (South Asian Network Operators Group) in the South Asian region. The meeting agenda will include presentations, tutorials and workshops to discuss implementation issues that require community cooperation. Topics of discussion will include network expansion, broadband deployment and scaling wireless networks in the desert. The RIPE NCC is proud to support the launch of this important regional forum, and will be providing organisational assistance throughout MENOG 1. For more information, please see: http://www.ripe.net/meetings/menog/ Regards, Paul Rendek, Head of Communications RIPE NCC

1 0

Fw: Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard
by Steven M. Bellovin 10 Mar '07

10 Mar '07

Begin forwarded message: Date: Fri, 09 Mar 2007 16:34:36 -0500 From: The IESG <iesg-secretary(a)ietf.org> To: IETF-Announce <ietf-announce(a)ietf.org> Cc: idr mailing list <idr(a)ietf.org>, idr chair <idr-chairs(a)tools.ietf.org>, Internet Architecture Board <iab(a)iab.org>, RFC Editor <rfc-editor(a)rfc-editor.org> Subject: Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard The IESG has approved the following document: - 'BGP Support for Four-octet AS Number Space ' <draft-ietf-idr-as4bytes-13.txt> as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-13.txt Technical Summary Currently the Autonomous System number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. Based on historical and current allocation rates, the range available to two-octet AS numbers is expected to run out in 2010. Working Group Summary This is a long-standing work item for the working group, with the first draft being published in February 2001. The approach described in the draft to support 4 Byte AS numbers is one of no change to BGP in terms of protocol in all but one aspect: The OPEN message uses a 4-Byte capability advertisement and the use of a 2 Byte MyAS field value. In all other respects there is no change to the protocol elements of BGP, other than using 4 bytes where ASs are used. The other substantive topic of the draft is in the interoperation of 4-Byte AS speakers with 2-Byte AS speakers. The OPEN message with capability advertisement has attracted one comment that this is contrary to RFC3392, however a detailed analysis of this comment has not lead to substantiation of this comment. Using this as a dynamic capability rather than an OPEN capability was raised as a comment, with the response that there is no reason to make the capability dynamic in this case. The tunnelling technique of using an opaque transitive community attribute to carry the 4-Byte AS Path attracted some comment. The comment was concerned with the reconstruction of the 4-Byte AS path across a 2-to-4 byte BGP boundary, where the algorithm for the reconstruction was, in some comments, not sufficiently well-defined. However it is also the case that the critical elements of the role of the AS Path are adequately described in the draft. The AS path length is used as a metric in the BGP path selection process, and the AS path itself is used for loop prevention. The draft specifies that the reconstruction of the AS path across a 2-byte to 4-byte AS transition should preserve the AS path length. The draft does not cover every possible eventuality of reconstruction of the 4-byte AS path, but a closer examination of the loop detection issue reveals that loops that may occur across a mixed 2 Byte / 4 Byte path are detectable within one iteration of the loop within the 2-Byte component of the mixed loop path in all circumstances. Accordingly, both the use of the AS path length as a path metric and the use of the AS path as a loop detection mechanism are preserved in this approach, even though the draft is not definitive in describing the AS path reassembly algorithm in every possible eventuality. In other words the draft contains the necessary and sufficient minimum set of properties for AS path reconstruction, leaving the precise algorithm up to the implementation. This approach is not seen as impairing the functionality, interoperability or integrity of BGP, either within the context of the individual peering session or in the context of the broader IDR framework. A comment was raised that on-the-wire inspection of BGP updates would not know in all cases whether they were seeing 2-byte or 4-byte AS BGP updates. The BGP update contains no additional control flags, and unless the on-the-wire device collects the initial OPEN message with the capability negotiation then the information as to 2-byte or 4-byte AS updates is not explicit. It has been noted that heuristics could be readily applied here, and the presence of the reserved 2-byte AS value 0 in the AS path is one indicator that the momitor is applying a 2-byte interpretation to a 4-byte BGP update. There were no other approaches referenced in the working group during Last Call, and the choice of this draft as representing one that is backwards compatible with existing BGP appears to have been an obvious obvious choice to the working group. The IETF Last call comments concernd the RFC3392 Capability Advertisement examination of these comments indicates that the concerns relating to RFC3392 are unwarranted, and the treatment of the capability advertisement is consistent with a conventional use of RFC3392 and is compatible with older versions of BGP. The IETF Last Call comments touched upon the larger size of BGP updates, and the desireability of using a compressed representation of AS Path. The Working Group did not see any need to include a compressed representation of AS paths in BGP updates. It appears that the onus of making a case that some form of compressed encoding of these BGP fields is of merit lies with the proponents of this as a potential source of problem, and the solution with respect to the AS_PATH representation lies in RFC3392 with additional capabilities being negotiated, either at session OPEN time or possibly dynamically. Thus, this 4-byte spec, that does not used compressed representation of AS_PATH is adequate, and those who believe that more compact representations are called for have a clear path of proposing such a specification to the IDR working group as a negotiated capability. The task for those who are of the opinion that such compact encodings are important to show why and propose a capability to be negotiated to do so in both the 4Byte and 2Byte worlds in the IDR Working Group. Protocol Quality Bill Fenner and Geoff Huston reviewed the document for the IESG. There are implementations; see the implementation report at http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Steve Bellovin, http://www.cs.columbia.edu/~smb

2 1

RE: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons
by michael.dillon＠bt.com 09 Mar '07

09 Mar '07

> No, the SP can't be the 'Internet > firewall' for customers, They can if the SP supplies and manages the CPE device. Nowadays, a lot of functionality could potentially be provided in a CPE device. Hardware cost and hardware capabilities are no longer barriers to doing this. There is still software cost, of course, but that can get amortized over many years and many, many subscribers. > but protecting one's > customers from being spammed/packeted from purported source > addresses > which are by definition nonsensical (as well as protecting everyone > else's customers from same) doesn't seem much to ask. > > What's needed here are better/easier/less brittle mechanisms for > same. Until such time as they're invented and deployed, let's not > make the perfect the enemy of the merely good, yes? Less brittle mechanisms don't need to be invented. There is nothing hard about putting an operational process in place to manage bogon filtering. There is also nothing hard about writing some software to update bogon filters. People do this kind of thing every day in network operations without much fanfare precisely because it is nothing special. It's just good operational practice in a company that does not expect its vendors to spoonfeed them everything. There's kind of a disease in the telecomms business. Many years ago someone got the idea that developing telecomms devices and systems was one business, and operating those devices and systems was another. Over time this crystalized into the idea that an operator bought platforms from vendors and then operated those platforms according to the vendor's instructions. This may be good for the capital investment industry (banks etc.) but it fails when there is a need for creativity in the telecomms operator. Sometimes, network operators have to take the bull by the horns and develop their own systems to do a job that vendors simply don't understand. --Michael Dillon

13 20