March 2015 - Test - lists.nanog.org

CHI-NOG 05 Agenda and Registration
by Tom Kacprzynski 18 Mar '15

18 Mar '15

We are pleased to announce that the Chicago Network Operators Group will host their 5th meeting (CHI-NOG 05) on May 14th, 2015 in Chicago, IL. Conference agenda can be found at http://chinog.org/meetings/chi-nog-05/agenda/ <http://chinog.org/meetings/chi-nog-05/agenda/> Registration is still open. For more details please see http://ching.org/meetings/chi-nog-05 <http://ching.org/meetings/chi-nog-05> Thank you.

1 0

Supplier 100/200Mbps on Canarias Is.
by Marco Paesani 18 Mar '15

18 Mar '15

Hi, I need a supplier on Canarias Is, do you have some info ? Please answer direct to me, thanks ! Best regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco(a)paesani.it

2 1

Request for clueful person at Apple's mail operation
by Rich Brown 17 Mar '15

17 Mar '15

Folks, A number of colleagues have been having delayed or rejected mail deliveries (with "451 4.5.3 Too many rejections; try again later." messages) since Saturday morning. Apple's front-line iCloud support people have been helpful, but not terribly clued in. Could someone contact me off-list to talk about this? Many thanks. Rich Brown Blueberry Hill Software richb.hanover(a)gmail.com +1 603-262-3957 (land line)

1 0

RIPE 70 draft programme and CFP 2nd deadline 12 april 2015
by Benno Overeinder 17 Mar '15

17 Mar '15

Dear colleagues, Following the past submission deadline, a Draft Programme for RIPE 70 is now published at: https://ripe70.ripe.net/programme/meeting-plan/draft-programme/ We will accept new proposals until 12 April 2015 for the remaining few slots. You can find the Call for Presentations and guidelines for submissions at: https://ripe70.ripe.net/submit-topic/cpf/ https://ripe70.ripe.net/submit-topic/guidelines/ Kind regards, Benno Overeinder RIPE PC -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

BCOP appeals numbering scheme -- feedback requested
by Yardiel D. Fuentes 16 Mar '15

16 Mar '15

Hello NANOGers, The NANOG BCOP committee is currently considering strategies on how to best create a numbering scheme for the BCOP appeals. As we all know, most public technical references (IETF, etc) have numbers to clarify references. The goal is for NANOG BCOPs to follow some sort of same style. The BCOP committee is looking for feedback and comments on this topic. Currently, the below numbering scheme is being considered: A proposed numbering scheme can be based on how the appeals appeals in the BCOP topics are presented as shown below: http://bcop.nanog.org/index.php/Appeals In the above page, the idea is to introduce a 100-th range for each category and as the BCOPs. This way a 100th number range generally identifies each of the categories we currently have. An example is: BCP Range Area of Practice 100 - 199 EBGPs 200 - 299 IGPs 300 - 399 Ethernet 400 - 499 Class of Service 500 - 599 Network Information Processing 600 - 699 Security 700 - 799 MPLS 800 - 899 Generalized An arguable objection could be that the range is limited...but a counter-argument is that considering more than 100 BCOPs would be either a great success or just a sign of failure for the NANOG community ... Comments or Thoughts ? Yardiel Fuentes

16 20

Searching for a quote
by Jason Iannone 16 Mar '15

16 Mar '15

There was once a fairly common saying attributed to an early networking pioneer that went something like, "be generous in what you accept, and send only the stuff that should be sent." Does anyone know what I'm talking about or who said it?

15 17

Re: BCOP appeals numbering scheme -- feedback requested
by Lee Howard 15 Mar '15

15 Mar '15

On 3/13/15 5:14 PM, "mel(a)becknet.com" <mel(a)becknet.com> wrote: >Lee, > >On the contrary, I think RFCs are pretty consistent about always >referring you to any superseding RFCs, and superseding RFCs reference >their predecessors, creating a very useful historical doubly-linked list. >I've served on IEEE committees that follow a decimal/alpha/french >numbering system, in which it is very hard to track the history of a >standard. > >RFCs, on the other hand, tend to be concisely written and well annotated >with background materials. What's more, RFCxxxx makes an excellent unique >internet-global search term. > >You've made the assertion that RFC numbering is terrible. Can you >provide some examples? The canonical version of the RFC is the plain text version. So here's RFC6204: http://www.rfc-editor.org/rfc/rfc6204.txt No notes about being obsolete. If you want, you can find two other versions officially published, the "tools version" and the "datatracker version": https://tools.ietf.org/html/rfc6204 https://datatracker.ietf.org/doc/rfc6204/ Both of those tell you that this RFC has been obsoleted by RFC7084. But here's one: https://tools.ietf.org/html/rfc791 Let's say I want to implement this protocol. Looks pretty straightforward, once I've read the errata and the three RFCs that obsolete it. The first of those three is RFC1349, which also has been obsoleted by RFC2474, which in turn has been obsoleted by RFC3168 and RFC3260, the first of which is obsoleted by RFC4301 and RFC6040. I didn't follow the other chains of obsoleting documents. How many documents do I have to read if I want to implement this protocol? Ha, ha, you say, nobody's trying to write an IP implementation from scratch. Au contraire, IPv6 is defined in https://tools.ietf.org/html/rfc2460, which lists nine RFCs updating it, plus errata. And while I agree with you that "RFC2460" is an easy, unique search term, it isn't exactly memorable. "I need to write an IPv6 stack for my new ThingOS; what do I need to read?" And one of my least favorite comments at the mic at IETF is, "Have you even read RFC6214?" [1] Because the author is standing there with no way to look up what that particular number means. I know, I should really be having this rant in the RFC evolution WG, or with the RFC editor. It just came up here, and I want BCOP to make different mistakes on useful documents. Lee [1] I included this reference in an RFI, to catch vendors who were only cutting and pasting marketing materials. > > -mel beckman > >> On Mar 13, 2015, at 12:50 PM, "Lee Howard" <Lee(a)asgard.org> wrote: >> >> I think the RFC numbering system is a terrible scheme. As Wes >>described, >> you have a document purporting to describe something, with no indicator >> that parts of it have been rendered obsolete by parts of other >>documents. >> I pity implementors who have to figure it all out. >> >> I also agree with Joel, that assigning meaning to index numbers is a bad >> idea. It leads to crossed indexes and unclear references. >> >> For the documents to be useful, one should be able to read a single >> document on a topic. When that topic is too big for a single document, >> split the document. When something in one document supersedes something >>in >> another, confirm consensus and update the canonical document. >> >> If that's too dynamic for people, then maintain the index, and when part >> of a document is obsoleted, the entire updated document should be >> republished with a new number, and the old one marked "obsoleted by >>XXXX." >> >> Under no circumstances would I support a limited number space. >> >> Lee >> >>> On 3/13/15 2:26 PM, "Mel Beckman" <mel(a)beckman.org> wrote: >>> >>> The index scheme has worked very well with RFCs, and has the added >>> advantage of their index numbers becoming handy memes. I strongly urge >>> Nanog to take advantage of the RFC system's success. There is no >>>shortage >>> of monotonically ascending integers :) >>> >>> -mel beckman >>> >>>> On Mar 13, 2015, at 11:19 AM, "Rick Casarez" <rick.casarez(a)gmail.com> >>>> wrote: >>>> >>>> I like the idea of an index better than the proposed numbering scheme. >>>> >>>> ------------------- >>>> Cheers, Rick >>>> >>>> Experiences not things. >>>> >>>>> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong <owen(a)delong.com> wrote: >>>>> >>>>> >>>>>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes <yardiel(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hello NANOGers, >>>>>> >>>>>> The NANOG BCOP committee is currently considering strategies on how >>>>>> to >>>>> best create a numbering scheme for the BCOP appeals. As we all know, >>>>> most >>>>> public technical references (IETF, etc) have numbers to clarify >>>>> references. >>>>> The goal is for NANOG BCOPs to follow some sort of same style. >>>>>> >>>>>> The BCOP committee is looking for feedback and comments on this >>>>>>topic. >>>>>> >>>>>> Currently, the below numbering scheme is being considered: >>>>>> >>>>>> A proposed numbering scheme can be based on how the appeals appeals >>>>>>in >>>>> the BCOP topics are presented as shown below: >>>>>> >>>>>> http://bcop.nanog.org/index.php/Appeals >>>>>> >>>>>> In the above page, the idea is to introduce a 100-th range for each >>>>> category and as the BCOPs. This way a 100th number range generally >>>>> identifies each of the categories we currently have. An example is: >>>>>> >>>>>> BCP Range Area of Practice >>>>>> 100 - 199 EBGPs >>>>>> 200 - 299 IGPs >>>>>> 300 - 399 Ethernet >>>>>> 400 - 499 Class of Service >>>>>> 500 - 599 Network Information Processing >>>>>> 600 - 699 Security >>>>>> 700 - 799 MPLS >>>>>> 800 - 899 Generalized >>>>>> >>>>>> An arguable objection could be that the range is limited...but a >>>>> counter-argument is that considering more than 100 BCOPs would be >>>>> either a >>>>> great success or just a sign of failure for the NANOG community ... >>>>>> >>>>>> Comments or Thoughts ? >>>>> >>>>> The problem with any such numbering scheme is how you handle the >>>>> situation >>>>> when you exhaust the avaialble number space. What happens with the >>>>> 101st >>>>> EBGP BCOP, for example? >>>>> >>>>> I also agree with Joel¹s comment about identifier/locator overload. >>>>> Have >>>>> we learned nothing from the issues created by doing this in IPv4 and >>>>> IPv6? >>>>> >>>>> Instead, how about maintaining a BCOP subject index which contains >>>>> titular >>>>> and numeric information for each BCOP applicable to the subjects >>>>>above. >>>>> >>>>> e.g.: >>>>> >>>>> BCOP Subject Index: >>>>> >>>>> Subjects: >>>>> 1. EBGP >>>>> 2. IGP >>>>> 3. Ethernet >>>>> 4. Class of Service >>>>> 5. Network Information Processing >>>>> 6. Security >>>>> 7. MPLS >>>>> 8. Generalized >>>>> >>>>> >>>>> 1. EBGP >>>>> 104 lorem ipsum >>>>> 423 ipsum lorem >>>>> >>>>> >>>>> >>>>> Then, just like the RFCs, maintain the BCOP appeal numbering as a >>>>> sequential monotonically increasing number and make the BCOP editor >>>>> responsible for updating the index with the publishing of each new or >>>>> revised BCOP. >>>>> >>>>> Note, IMHO, a revised BCOP should get a new number and the previous >>>>> revision should be marked ³obsoleted by XXXXX² and it¹s document >>>>>status >>>>> should reflect ³Obsoletes XXXX, XXXX, and XXXX² for all previous >>>>> revisions. >>>>> The index should probably reflect only BCOPs which have not been >>>>> obsoleted. >>>>> >>>>> Just my $0.02. >>>>> >>>>> Owen >> >> >

3 2

Rerouting of UK traffic
by Jonathan Tomek 14 Mar '15

14 Mar '15

Hello Everyone, DYN put out an interesting report on how 14 British telecom routes (167 prefixes) were routed through Ukraine for a good portion of time. The ASN in question is AS12883 (Vega in Kiev, Ukraine). Do you think this could be a mistake? Does anyone have any additional information to back this up? The full report is here: http://research.dyn.com/2015/03/uk-traffic-diverted-ukraine/ Respectfully, Jonathan Tomek

1 0

Re: Searching for a quote
by Larry Sheldon 14 Mar '15

14 Mar '15

On 3/13/2015 08:47, Karl Auer wrote: > On Fri, 2015-03-13 at 06:14 -0700, Stephen Satchell wrote: >> what I was taught is that one has to be >> able to handle *correctly* malformed input, and not yield astonishing >> results. > > "No program should leave its sanity at the mercy of its input". PJ > Plauger, I think. I have no idea where I learned it but early in my career as a programmer and later as a manager of programmers I preached that "Above all else, programmer, your duty and responsibility is to protect your program from its input and its environment." I may very well owe that to somebody smarter than me, but I think the idea solidified in my first paid programming job I got embroiled in a battle with programmers from another district in a huge batch system, Their allegation was that bad input from a program I was responsible-for had caused a massive and expensive outage down-stream of us. (They had amassed a collection of file-dump snap-shots that they said showed that the records from us had errors in them--we were able to show that the file-dumps were fraudulent in and of themselves, but my main argument was an early rendition to the thing quoted above.) Parenthetically, one of my favorite management quotations came out of that when the District Manager that my boss reported to (We called him "The Senator" behind his back) stood up at his desk and announced to us and to the folks from the other District that "we would have a solution to the problem by four PM today or there will be a series of Nine O'Clock Announcements tomorrow morning." (Big company, big inventory of thoroughly distasteful assignments for ambitious managers-on-the-climb.) -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes

1 0

What happened to Schprokits?
by Scott Whyte 14 Mar '15

14 Mar '15

Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ doesn't look too good. What happened?

6 6