Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
Robert E. Seastrom wrote: No, let's not. To steal a line from rbush, we tried that three years ago and it didn't work then. Good point, but the situation is very different than what it was three years ago. We have a moderation team, we have nanog-futures for meta discussion, etc. Further, we don't disagree. I am with you that the MLC does a good job and has a good approach. What I am saying is not to dump everything, but rather now that issues are resolved, how about a lighted finger on that moderate button? Thanks for letting me know I wasn't clear in my statement. The current MLC's approach is working Just Fine; apparently they have found the proper balance. Don't mess with success. How do you define balance? The threads on nanog-futures clearly show the balance is not there. The MLC does a good job and the moderation isn't working well. These two facts need to be aligned. What we are not happy with is how moderation works. -r Gadi. ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On Thu, 23 Apr 2009, Gadi Evron wrote: facts need to be aligned. What we are not happy with is how moderation works. Speak for yourself ; I'm quite sure that I'm not a part of the 'we' you mention here. cheers! == A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now. ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
Cat Okita wrote: On Thu, 23 Apr 2009, Gadi Evron wrote: facts need to be aligned. What we are not happy with is how moderation works. Speak for yourself ; I'm quite sure that I'm not a part of the 'we' you mention here. Indeed! ;) To be clear, we includes me and others who spoke here who believe moderation is not working well. But let us try and look at what we do agree on: 1. MLC is doing a good job. 2. Things are much better now. Does that narrow our disagreement to how moderation is done in practice? Gadi. ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] ADMIN: Reminder on off-topic threads
Moderation has never worked well. Personal choice, killfiles, are optimal IMHO. Best, Martin On 4/23/09, Gadi Evron g...@linuxbox.org wrote: Cat Okita wrote: On Thu, 23 Apr 2009, Gadi Evron wrote: facts need to be aligned. What we are not happy with is how moderation works. Speak for yourself ; I'm quite sure that I'm not a part of the 'we' you mention here. Indeed! ;) To be clear, we includes me and others who spoke here who believe moderation is not working well. But let us try and look at what we do agree on: 1. MLC is doing a good job. 2. Things are much better now. Does that narrow our disagreement to how moderation is done in practice? Gadi. ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On Apr 23, 2009, at 4:14 AM, Gadi Evron wrote: What I am saying is not to dump everything, but rather now that issues are resolved, how about a lighted finger on that moderate button? The issues are not resolved. How about a slightly heavier finger on the moderate button? Gadi, everyone here understands that you want NANOG to be a all-things- Gadi-wants-to-talk about. The rest of us prefer to keep topics relevant to their list, and not discuss the same topic on multiple mailing lists. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
Hey Jo, On 23-Apr-2009, at 13:56, Jo Rhett wrote: Gadi, everyone here understands that you want NANOG to be a all- things- Gadi-wants-to-talk about. Personally, I find the ad-hominem attacks against gadi (of which this is a surely mild example) far more annoying than anything gadi has posted to this list or the main one in the past few years. Just saying. Joe ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On 23-Apr-2009, at 07:14, Gadi Evron wrote: The threads on nanog-futures clearly show the balance is not there. The goal should not be to have nanog-futures descend into silence; the goal should be to have a useful mix of productive conversation on the main list. You can have the latter without the former. I would argue in fact that if this list is silent, the main list is in trouble: the fact that people are posting here shows that they are still engaged, and still care. That's a good thing. Joe ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
Back when I ran the PC, people used to suggest that we split our meetings up into tracks. Most folks wanted two tracks: one for stuff they were interested in, and one for everything else. The mailing list is the same way, everyone has a different idea of what's interesting and on-topic. The challenge for the MLC, and the community, is to determine a rough consensus and implement it. And it will always be a moving target, as people and technologies change. My sense is that the current moderation policy is reasonable, though a bit more discussion is warranted and documentation is needed. The list of what's on-topic is more fluid, and periodically needs a new round of consensus-building and AUP rewriting. And that's what I'd like to see this discussion become. Disclaimer: I'm the Steering Committee liaison to the MLC, but these are my personal opinions. Steve ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] ADMIN: Reminder on off-topic threads
--- mar...@theicelandguy.com wrote: From: Martin Hannigan mar...@theicelandguy.com Moderation has never worked well. Personal choice, killfiles, are optimal IMHO. I agree. scott - ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On 23 Apr 2009, at 20:55, Jo Rhett wrote: It wasn't meant as an attack. I hope it wasn't interpretted that way. Yeah, it wasn't a very good message to reply to in order to make that point. Sorry if it felt like I was beating you up. There are so many knee-jerk mails that it's easy to classify things as knee-jerk anti- gadi and everything else. For the record I've met Gadi (hi, Gadi!), and have drunk beer with him, and I have time for him, and perhaps that also colours some of the irritation I feel when I see what looks like attacks at the person rather than attacks at the point under discussion. And it wasn't specific. Nanog shouldn't be everything-Jo-wants-to- talk-about or everything-Randy-wants-to-talk-about or anything else. Very much agreed, and in that spirit... It's focus should be on the ONE topic, and related topics are better covered in their own mailing lists. ... it often feels like a mistake to use absolute language when describing whether things are on-topic or not for the main list. What is clearly an ARIN policy for some people is apparently operational for others, for example. OK, maybe bad example, maybe everybody realises it's policy but has poor impulse control. Personally, when I take the time to think before I hit send, I ask myself (a) is this something that someone running an ISP would care about, and (b) am I prepared to spend time after this message contributing to the thread, assuming I have something further to add. If the answer to both is yes, (or if I have an inappropriate amount of alcohol or caffeine or both in my bloodstream, or if I suffer from poor impulse control for some other reason since clearly I at least as much as the next person) I hit send. On futures, however, I just hit send. :-) Joe ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On Thu, Apr 23, 2009 at 09:10:31PM -0400, Joe Abley wrote: On 23 Apr 2009, at 20:55, Jo Rhett wrote: And it wasn't specific. Nanog shouldn't be everything-Jo-wants-to- talk-about or everything-Randy-wants-to-talk-about or anything else. !snork!... rubbing the sleep from remaining good eye... Very much agreed, and in that spirit... It's focus should be on the ONE topic, and related topics are better covered in their own mailing lists. AhAH! the setup On futures, however, I just hit send. :-) and permission!?!!?! (thanks Joe) Joe EVERYONE IS ENTITLED TO MY OPINION - (the old skool NANOG motto) --bill (settling back into sleep) ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: The real issue
Is ARIN, who won't even take back large blocks of space from people who have long ago stopped using it and aren't paying anything for it, prepared to start filing civil suits against people who were assigned / 24's (and paid for them) due to inaccurate declaration? it's a real shame that there is no mailing list for the endless arin policy disease threads. randy
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On 22 apr 2009, at 23:39, Jack Bates wrote: What really would help is more people who are not on NANOG pushing vendors to support IPv6. Even my Juniper SE has mentioned that I'm one of 2 people he's had seriously pushing for IPv6 features. Other vendors have just blown me off all together (we'll have it sometime). Right. And I'm also the only one asking for 32-bit AS numbers. People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established. Serious input and participation means work and money. You can participate on mailinglists without attending meetings, so in that sense it doesn't have to cost money. As an operator, it would make sense to spend a little time in the requirements phase but not after that. So yes, it would take time, but we're not talking about hours a day on an ongoing basis. Doesn't help that when I was a wee one, mom dated someone who bragged about his status in the IETF :-) and even had a pen. Sad way to be introduced to any organization, but I have seen similar mentalities regarding IETF mentioned here reinforcing my belief that arrogance is alive and I don't have the time and money to deal with it. In any case, if you have input on this whole NAT64 business, let me and/or Fred know. If you have input on anything else, speak up on this list or a NANOG meeting and there's a decent chance that someone will take those comments back to the IETF.
Re: Broadband Subscriber Management
Integration with the billing system is a big one, but remember that not everybody is in control of the DSLAM or whichever device connects to the access network and touches the end user directly. They may instead rely on a wholesale provider for that if they don't have the reach themselves. From: Larry Smith lesm...@ecsis.net Sent: Thursday, 23 April 2009 2:07:42 AM To: nanog@nanog.org CC: Subject: Re: Broadband Subscriber Management On Wed April 22 2009 11:01, Curtis Maurand wrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any technical support to turn on/off customers.
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On 23 apr 2009, at 12:23, Nathan Ward wrote: Just participating in mailing lists is good for keeping up to date, but not so good for getting things changed. That's what I've found, anyway. Might not always be true. Depends on the issue. Sometimes bad ideas get traction in the IETF, it's hard to undo that. But there are also times when even a single message containing good arguments can have an effect. Also don't expect too much from IETF participation: if doing X is going to make a vendor more money than doing Y, they're going to favor X, even if Y is the superior solution.
Re: Important New Requirement for IPv4 Requests
It appears that ARIN wants to raise the IP addressing space issue to the CxO level -- if it was interested in honesty, ARIN would have required a notarized statement by the person submitting the request. No. Those are two entirely different problems. A notary signs only that the person in front of them has been checked to be who they say they are. That's authentication. A Notary cannot attest that what is on the document is valid. Actually, a notary can administer oaths, and the requirement from ARIN ought to require an attestation of the accuracy of the data submitted under oath or affirmation if we're going to go down that route. http://www.commonwealth.virginia.gov/OfficialDocuments/Notary/2008NotaryHandBook.pdf -r
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
Iljitsch van Beijnum wrote: Depends on the issue. Sometimes bad ideas get traction in the IETF, it's hard to undo that. That's an understatement. Also don't expect too much from IETF participation: if doing X is going to make a vendor more money than doing Y, they're going to favor X, even if Y is the superior solution. Some wag around here re-christened it the IVTF (V stands for Vendor, not Victory). ;-) I haven't bothered to go in years
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On Thu, 23 Apr 2009, Nathan Ward wrote: After trying to participate on mailing lists for about 2 or 3 years, it's pretty hard to get anything done without going to meetings. Just participating in mailing lists is good for keeping up to date, but not so good for getting things changed. That's what I've found, anyway. Might not always be true. If you were to go to meetings, you would realize that it won't help in gettings things changed significantly better than active mailing list participation would... :-/ -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On Thu, Apr 23, 2009, William Allen Simpson wrote: Some wag around here re-christened it the IVTF (V stands for Vendor, not Victory). ;-) I haven't bothered to go in years If the people with operational experience stop going, you can't blame the group for being full of vendors. Methinks its time a large cabal of network operators should represent at IETF and make their opinions heard as a collective group. That would be how change is brought about in a participative organisation, no? :) Adrian
Re: Broadband Subscriber Management
My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. At least one major vendor hold this to be the case, but I'm not sure if this is necessarily the case. Furthermore, a lot of the DSLAMs going out are GigE on the P side and ATM on the PE-CE. I can think of at least one or two issues with bungled ATM policing/shaping with a few vendors. In the case of my particular SP, they're performing the effective rate limiting at L1 anyway and terminating the PPPoA at the DSLAM so, in essence, they get to provide less throughput on the backend while advertising more (due to the inherent overhead of PPP and AAL5) Here's the output from my DSL training to show how they're doing it currently: Interleave FastInterleave Fast Speed (kbps): 0 6016 0 768 This is my subscribed speed. RADIUS does add some nice features for usage monitoring but, here atleast, it was not a primary concern when it was first implemented (due to the 'unlimited' manner in which DSL was sold, the ability to get this per port, etc). --William From: Larry Smith lesm...@ecsis.net Sent: Thursday, 23 April 2009 2:07:42 AM To: nanog@nanog.org CC: Subject: Re: Broadband Subscriber Management On Wed April 22 2009 11:01, Curtis Maurand wrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any technical support to turn on/off customers.
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On Thu, Apr 23, 2009 at 08:17:07PM +0800, Adrian Chadd wrote: On Thu, Apr 23, 2009, William Allen Simpson wrote: Some wag around here re-christened it the IVTF (V stands for Vendor, not Victory). ;-) I haven't bothered to go in years If the people with operational experience stop going, you can't blame the group for being full of vendors. Methinks its time a large cabal of network operators should represent at IETF and make their opinions heard as a collective group. That would be how change is brought about in a participative organisation, no? :) Adrian Operator participation in IETF has been a problem for at least 18 years. I remember a fairly large dustup w/ John Curran and Scott Bradner over why the OPS area was so lacking in actual operators at the Columbus IETF. Its never gotten any better. IETF used to be populated by developers and visionaries (grad students with lofty ideas). Once commercialization set in (they graduated and got jobs) their funding sources changed from government grants to salaries. And management took a more active role. the outcome is that vendors now control much of the IETF participation and indirectly control IETF output. just my 0.02 from the cheap seats. --bill
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On 24/04/2009, at 12:14 AM, Pekka Savola wrote: On Thu, 23 Apr 2009, Nathan Ward wrote: After trying to participate on mailing lists for about 2 or 3 years, it's pretty hard to get anything done without going to meetings. Just participating in mailing lists is good for keeping up to date, but not so good for getting things changed. That's what I've found, anyway. Might not always be true. If you were to go to meetings, you would realize that it won't help in gettings things changed significantly better than active mailing list participation would... :-/ I got heaps done in SFO - to the point where I'm happy to pay to get to Stockholm and Hiroshima later this year (I'm self employed, and live at the end of the world, so for me it's harder than most who just have to convince the boss :-). -- Nathan Ward
Re: Broadband Subscriber Management
On 24/04/2009, at 12:23 AM, William McCall wrote: My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. Also, DSL was the upgrade from dialup in many places, and dialup is generally PPP. For ISPs, the re-engineering required north of the last mile is much less, particularly in the billing/accounting systems that no one wants to touch because they were written by that coder who left a few years ago and work just fine. -- Nathan Ward
Re: Broadband Subscriber Management
You need also to remember that in many cases the DSL link is not provided by the actual ISP. In many cases this is a wholesale scenario which uses L2TP to forward the PPP session from the telco/DSL provider to the ISP. In many cases there would also be another L2TP hop to another sub-ISP/customer. Arie On Wed, Apr 22, 2009 at 7:01 PM, Curtis Maurand cmaur...@xyonet.com wrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Just a suggestion Sherwin Ang wrote: Hello Nanog! i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's. how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours? thank you for any insights that you may share. -Sherwin
Re: Broadband Subscriber Management
Arie Vayner wrote: You need also to remember that in many cases the DSL link is not provided by the actual ISP. In many cases this is a wholesale scenario which uses L2TP to forward the PPP session from the telco/DSL provider to the ISP. In many cases there would also be another L2TP hop to another sub-ISP/customer. I have this exact setup (we are the sub-ISP). Sorry to sway this thread, but it seems like a good opportunity to ask about a problem I'm having. We went from a setup where the DSL provider's LNSs would auth/acct against our RADIUS server. This was working great for billing as previously discussed. Recently, there was another ISP inserted into the mix, between us and the DSL provider. The problem is that I now see RADIUS entries from both company's LNSs for each PPPoE login, which completely throws off the accounting numbers. Is there anyone here who can provide any insight as to whether this is normal, and/or how to fix it? We only do the authentication for our DSL subs. Essentially, I want to stop receiving the LNS connection info from the DSL provider itself, and only receive the ones coming from the intermediary ISP. I'm not particularly familiar with the specifics of an LNS configuration, but it would be great if I had some information that I could discuss with the provider in hopes to get this turned off (if possible): user213:ISP xx.xx.38.134 Thu Apr 23 07:37 - 07:41 user818:DSL Thu Apr 23 07:37 - 07:41 Steve
Re: Broadband Subscriber Management
Good point. Oliver Eyre wrote: Integration with the billing system is a big one, but remember that not everybody is in control of the DSLAM or whichever device connects to the access network and touches the end user directly. They may instead rely on a wholesale provider for that if they don't have the reach themselves. From: Larry Smith lesm...@ecsis.net Sent: Thursday, 23 April 2009 2:07:42 AM To: nanog@nanog.org CC: Subject: Re: Broadband Subscriber Management On Wed April 22 2009 11:01, Curtis Maurand wrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any technical support to turn on/off customers.
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On 23 apr 2009, at 14:17, Adrian Chadd wrote: Methinks its time a large cabal of network operators should represent at IETF and make their opinions heard as a collective group. That would be how change is brought about in a participative organisation, no? :) Why don't you start by simpling stating what you want to have happen? So far I've seen a number of messages complaining about the IETF (btw, if you like complaining about the IETF, go to the meetings, there is significant time set aside for that there) but not a single technical request, remark or observation. The IETF works by rough consensus. That means if people disagree, nothing much happens. That is annoying. But a lot of good work gets done when people agree, and a lot of the time good technical arguments help. Like I said, the IETF really wants input from operators. Why not start by giving some?
Re: The real issue
it's a real shame that there is no mailing list for the endless arin policy disease threads. Ohh, you can merge it with the one about the ICANN governance outcry nonsense, that way will be easier to filter or delete. My .02 Jorge
Re: Broadband Subscriber Management
Could you have two instances of RADIUS, one for the middle-man and ignore the accounting from that server? -- Leigh Steve Bertrand wrote: Arie Vayner wrote: You need also to remember that in many cases the DSL link is not provided by the actual ISP. In many cases this is a wholesale scenario which uses L2TP to forward the PPP session from the telco/DSL provider to the ISP. In many cases there would also be another L2TP hop to another sub-ISP/customer. I have this exact setup (we are the sub-ISP). Sorry to sway this thread, but it seems like a good opportunity to ask about a problem I'm having. We went from a setup where the DSL provider's LNSs would auth/acct against our RADIUS server. This was working great for billing as previously discussed. Recently, there was another ISP inserted into the mix, between us and the DSL provider. The problem is that I now see RADIUS entries from both company's LNSs for each PPPoE login, which completely throws off the accounting numbers. Is there anyone here who can provide any insight as to whether this is normal, and/or how to fix it? We only do the authentication for our DSL subs. Essentially, I want to stop receiving the LNS connection info from the DSL provider itself, and only receive the ones coming from the intermediary ISP. I'm not particularly familiar with the specifics of an LNS configuration, but it would be great if I had some information that I could discuss with the provider in hopes to get this turned off (if possible): user213:ISP xx.xx.38.134 Thu Apr 23 07:37 - 07:41 user818:DSL Thu Apr 23 07:37 - 07:41 Steve
RE: The real issue
Word up arin-annou...@arin.net; arin-p...@arin.net Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 We move the information that moves your world. -Original Message- From: Jorge Amodio [mailto:jmamo...@gmail.com] Sent: Thursday, April 23, 2009 9:35 AM To: nanog@nanog.org Subject: Re: The real issue it's a real shame that there is no mailing list for the endless arin policy disease threads. Ohh, you can merge it with the one about the ICANN governance outcry nonsense, that way will be easier to filter or delete. My .02 Jorge __ This inbound email has been scanned by the MessageLabs Email Security System. __ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.
Re: Important New Requirement for IPv4 Requests [re impacting revenue]
Apologies for a somewhat latent response - I was attending an IPv6 Seminar (of which ARIN was a sponsor) the last two days and am just getting to nanog mail today. On Tue, Apr 21, 2009 at 15:42, Shane Ronan sro...@fattoc.com wrote: I'm not sure if anyone agrees with me, but these responses seem like a big cop out to me. A) If ARIN is so concerned about the potential depletion of v4 resources, they should be taking a more proactive roll in proposing potential solutions and start conversation rather then saying that the users should come up with a proposal which they then get a big vote one. They is YOU. ARIN policy is created by the community - Your voice, your community. The statement should read: If [you] are so concerned about the potential depletion of v4 resources, [you] should be taking a more proactive [role] in proposing potential solutions and start[ing] conversation. If you participated in the ARIN PDP (1), even by just lurking on the ppml (2), you would already be aware that many folks have proposed many potential solutions (some of which have already been adopted) and that there _is_ an ongoing conversation that I strongly encourage you to join. B) Again, while it might be the IETF's job, shouldn't the group trusted with the management of the IP space at least have a public opinion about these solutions are designed. Ensuring that they are designed is such a way to guarantee maximum adoption of v6 and thus reducing the potential for depletion of v4 space. I think that developing resource management policy to meet those goals is much more in line with ARINs mandate. As I mentioned above, this is happening. C) Are ARIN's books open for public inspection? If so, it might be interesting for the group to see where all our money is going, since it's obviously not going to outreach and solution planning. Perhaps it is being spent in a reasonable manner, and the fees are where they need to be to sustain the organizations reasonable operations, but perhaps not. Links to annual statements etc. have already been provided. I am sure an email to ARIN (3) would help you answer your question further. Mr Curran, given the response you've seen from the group, and in particular the argument that most CEO's or Officers of firms will simply sign off on what they IT staff tells them (as they have little to no understanding of the situation), can you explain what exactly you are hoping to achieve by heaping on yet an additional requirement to the already over burdensome process of receiving an IPv4 allocation? I obviously can not speak for Mr. Curran, but I do applaud this effort. I believe that adding this requirement will lower exaggeration and fraud as well as raise awareness. These are both noble goals and well worth the marginal effort required. The argument that most officers will sign anything put in front of them is not very convincing to me. I have a hard time accepting incompetence or laziness as a valid rational for any argument at all really. ~Chris (speaking for myself) (1) - https://www.arin.net/knowledge/pdp/ (2) - https://www.arin.net/participate/mailing_lists/index.html (3) - mailto:i...@arin.net Shane Ronan --Opinions contained herein are strictly my own-- On Apr 21, 2009, at 9:01 AM, John Curran wrote: Roger - A few nits: A) ARIN's not ignoring unneeded legacy allocations, but can't take action without the Internet community first making some policy on what action should be taken... Please get together with folks of similar mind either via PPML or via Public Policy meeting at the the Open Policy Bof, and then propose a policy accordingly. B) Technical standards for NAT NAPT are the IETF's job, not ARIN's. C) We've routinely lowered fees since inception, not raised them. Thanks, /John John Curran Acting CEO ARIN -- Chris Grundemann weblog.chrisgrundemann.com
Re: Broadband Subscriber Management
And they will never listen (TELEM). On Wed, Apr 22, 2009 at 12:01 PM, Curtis Maurand cmaur...@xyonet.comwrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Just a suggestion Sherwin Ang wrote: Hello Nanog! i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's. how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours? thank you for any insights that you may share. -Sherwin -- --sharlon
Re: MRTG in Fourier Space
Gents, On Tue, Apr 21, 2009 at 5:30 PM, Dave Plonka plo...@doit.wisc.edu wrote: Hi Crist, On Tue, Apr 21, 2009 at 05:12:04PM -0700, Crist Clark wrote: Has anyone found any value in examining network utilization numbers with Fourier analyses? After staring at pretty In short, yup! there are some interesting periodic characteristics in the data that could be easily teased out beyond, Well, the Indeed, there are. Interesting things emerge in frequency (or phase) space - bits/sec, packets/sec, and ave size, etc. - all have new meaning, often revealing subtle details otherwise missed. The UW paper [Barford/Plonka et. al] is one of my favories and often referenced in other publications. Along similar lines, I presented a lightning talk at nanog that demonstrates using windowed Ft's (mostly Gaussian or Hamming) in three-axis graphs (i.e. 'waterfalls') available in common tools (buadline, sigview, labview, etc) for characterizing round trip times through various network queues and queue states. Unexpectedly, interesting details regarding host IP stacks and OS scheduler behavior became visible. Find the talk slides and video here (look for 'kapela'): http://www.nanog.org/meetings/nanog37/agenda.php A quick Google search turned up nothing at all. Signal analysis, sadly, isn't as fun as going shopping or posting to webhosting talk, etc. so you won't likely find much there. Such techniques are used in the are of network anomaly detection. For instance, a search for network anomaly detection at scholar.google.com will yield very many results. I would also mention citeseer (http://citeseer.ist.psu.edu/) and ieee explore (http://ieeexplore.ieee.org) - there's lots of related application of Ft's and wavelet/fir filters in various disciplines, all of which can apply to the analysis of time-series data. is one such work. We mention that we use wavelet analysis rather than Fourier analysis because wavelet/framelet analysis is able to localize events both in the frequency and time domains, whereas Fourier analysis would localize the events only in frequency, so an iterative approach (with varying intervals of time) would be necessary. In general, this is the reason why Fourier analysis has not been a common technique used in network anomaly detection. I want to suggest that time windowed Ft might be a reasonable middle ground, certainly for Crist's case. Naturally, the trade-offs will be in frequency accuracy (ie. longer window) vs. temporal accuracy (ie. short window). Another solution for your needs might be cascaded FIR bandpass filters, but again, you're subject to time/frequency error trade-offs as related a filter's bandwidth. While you're at it, consider processing your time series data into histogram stacks, or nested histograms. I haven't specifically seen a paper covering this, but another UW gent (DW, are you reading this?) used to process their 30 second ifmib data into a raw .ps file, and printed this out weekly/daily. The trends visible here were quite interesting, but I don't think much further work was done to see if anything super-interesting was more/less visible in this form than traditional ones. -Tk
Re: MRTG in Fourier Space
On Thu, Apr 23, 2009 at 2:48 PM, Anton Kapela tkap...@gmail.com wrote: Indeed, there are. Interesting things emerge in frequency (or phase) space - bits/sec, packets/sec, and ave size, etc. - all have new Forgot to mention one point - since packets/bits/etc data is more monotonic than not (math wizards, please debate/chime in) and since it's not a 'signal' in the continuous sense, you might find value in differentially filtering the input data *before* FT or wavelet processing. This would serve to remove the weird-looking DC offset in the output simply by creating a semi-even distribution of both positive and negative input sample values. -Tk
Re: Important New Requirement for IPv4 Requests [re impacting revenue]
Chris Grundemann wrote: They is YOU. ARIN policy is created by the community - Your voice, your community. ... If you participated in the ARIN PDP (1)... Ok, so am I the only one who missed which policy proposal this was that generated the new requirement that an officer sign off on the request for more IPv4 space? I can't find the Policy Proposal number or the Draft Policy ID, but then maybe I'm not looking hard enough. Matthew Kaufman
Re: Important New Requirement for IPv4 Requests
Net-Admin: This IPv6 stuff is important, we should already be deploying it full-tilt. Manager:Some IPv6 testing should be reflected in next years budget. Director: I hear IPv6 is the future, but customers just aren't demanding it. VP Network: Humm, maybe I should have read the Network World article on IPv6 rather than the one on Google World Dominance. ...you forgot the rest of the conversation: VP Network: Why doesn't www.google.com return one of these v6 addresses? Director: Yeah, did do a limited v6 deployment last year, why doesn't i work? Net-Admin: We aren't one of the networks that have been individually vetted by Google to return an to without complications. Director: So even with all their scale, influence and technology resources, they still won't do it by default? VP Network: Sounds like we can hold back on that budget for another year.
Re: IXP
Bill Woodcock wo...@pch.net writes: ... Nobody's arguing against VLANs. Paul's argument was that VLANs rendered shared subnets obsolete, and everybody else has been rebutting that. Not saying that VLANs shouldn't be used. i think i saw several folks, not just stephen, say virtual wire was how they'd do an IXP today if they had to start from scratch. i know that for many here, starting from scratch isn't a reachable worldview, and so i've tagged most of the defenses of shared subnets with that caveat. the question i was answering was from someone starting from scratch, and when starting an IXP from scratch, a shared subnet would be just crazy talk. -- Paul Vixie
Re: IXP
In a message written on Fri, Apr 24, 2009 at 01:48:28AM +, Paul Vixie wrote: i think i saw several folks, not just stephen, say virtual wire was how they'd do an IXP today if they had to start from scratch. i know that for many here, starting from scratch isn't a reachable worldview, and so i've tagged most of the defenses of shared subnets with that caveat. the question i was answering was from someone starting from scratch, and when starting an IXP from scratch, a shared subnet would be just crazy talk. I disagree. Having no shared subnet renders an exchange switching platform useless to me. If I have to go to all the work of configuring both ends in a exchange point operator provisioning system (and undoubtly being billed for it), assigning a /30, and configuring an interface on my router then I will follow that procedure and order a hunk of fiber. Less points of failure, don't have to deal with how the exchange operator runs their switch, and I get the bonus of no shared port issues. The value of an exchange switch is the shared vlan. I could see an argument that switching is no longer necessary; but I can see no rational argument to both go through all the hassles of per-peer setup and get all the drawbacks of a shared switch. Even exchanges that took the small step of IPv4 and IPv6 on separate VLAN's have diminished value to me, it makes no sense. It's the technological equvilient of bringing everyone into a conference room and then having them use their cell phones to call each other and talk across the table. Why are you all in the same room if you don't want a shared medium? -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp3nEl2LGJwE.pgp Description: PGP signature
Re: IXP
On Thu, Apr 23, 2009, Leo Bicknell wrote: It's the technological equvilient of bringing everyone into a conference room and then having them use their cell phones to call each other and talk across the table. Why are you all in the same room if you don't want a shared medium? Because you don't want to listen to what others have to say to you. Adrian (The above statement has network operational relevance at an IP level.)
RE: Broadband Subscriber Management
I wasn't aware that LECs have the money to provide a DSLAM port per pair. =) PPPoA/E wasn't invented to prevent DSL sharing (not possible), but was the result of extending the dial-up approach of PPP with usernames and passwords to provide end-users IP connectivity. As Arie mentions in his posting, the separation of physical link termination and session termination, done in the dial-up world at the time, lent to setting up DSL in the same manner. You don't have to read too many commentaries on IRB RFC 1483 to recognize that that approach is all that great, either. Frank -Original Message- From: William McCall [mailto:william.mcc...@gmail.com] Sent: Thursday, April 23, 2009 7:24 AM To: nanog@nanog.org Subject: Re: Broadband Subscriber Management My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. snip
Re: MRTG in Fourier Space
As IP traffic is assumed to be self-similar, my EE origins tell me to look for parameters that could measure it from stochastic process theory. On a Google search this paper sounded interesting: http://www.sparc.uni-mb.si/OPNET/PDF/IWSSIP2007Fras.pdf (...) We estimated the Hurst parameter (H) for the arrival process, and the fitted distributions for the measured data (packet size and inter-arrival processes). Using the autocorrelation function of the process, we determined long-range or short-range dependence. distribution and its parameters. The Hurst parameter was estimated using three graphical methods (variance, R/S, and periodogram methods). Distribution and its parameters were estimated using fitting tools. (...) Doing it in RRD-time seems like a challenge, though. It might be easier to plot fractals from the data source if your target audience is made of humans, because they will spot patterns real fast with much less number crunching. Rubens On Tue, Apr 21, 2009 at 9:12 PM, Crist Clark crist.cl...@globalstar.com wrote: Maybe a slightly off topic math-geek kind of question to take time out from the ARIN/death-of-IPv4/IPv6-evangalist thread of the week. Has anyone found any value in examining network utilization numbers with Fourier analyses? After staring at pretty MRTG graphs for a bit too long today, I'm wondering if there are some interesting periodic characteristics in the data that could be easily teased out beyond, Well, the diurnal fluctuations are obvious, but looks like we may have some hourly traffic spikes in there too. And maybe some of those are bigger every fourth hour. A quick Google search turned up nothing at all. With many EE-types who find their way into network operations and wannabe-EEs already there, I found that maybe a little surprising. I know the EEs love Fourier transforms.
Re: IPv6 Operators List (which also covers 6to4 operation ; ) (Was: IPv4 Anycast?)
Shin SHIRAHATA wrote: 192.88.99.0/24, 2002::/16, and 2001::/32 are some notable examples of heterogeneous origin AS. And those prefixes (6to4 Teredo) all come with annoying problems as one never knows which relay is really being used and it is hard to debug how the packets really flow. I agree entirely. As a one of 6to4 relay operator (AS38646), I believe coordination among 6to4 and Teredo operators is needed. Does anyone know is there any operators group who are using 192.88.99.0/24, 2002::/16, and 2001::/32? See http://lists.cluenet.de/pipermail/ipv6-ops/ Next to that: whois -h whois.ripe.net RFC3068-MNT that at at least should give you all the European 6to4 operators directly. Thank you for you information :) RFC3068-MNT is very interesting. Can non-Europian operator register this mainter object? If not, similar system in other region? Cheers, Shin --- No caffeine, No work. Shin SHIRAHATA s...@shirahata.name / t...@sfc.wide.ad.jp
