August 1996 - Test - lists.nanog.org

Re: Customer AS
by Sean Doran 17 Aug '96

17 Aug '96

-----BEGIN PGP SIGNED MESSAGE----- Curtis Villamizar <curtis(a)ans.net> writes: > The answer is clearly to number into an aggregate if you are dual > homed. Sprint will take the aggregate and at least have one path to > your prefix, very likely two if your two providers exchange your more > specific route between each other. We will route long prefixes across customer connections. Therefore, if a customer is dual-homed to another provider and has a long prefix from that other provider, we will listen to that long prefix across the customer connection. When it goes away, we will hear the aggregate, and route towards that. This, as Curtis says, is a clear win. I would note, though, that there is the risk that the other provider has contractual language wrt the non-portability of that provider's addresses that might make this not work. That, as Paul says, might be catch-22. However, I am sure that this would not be an insoluble problem, since, as I said in an earlier note, a price for an exception might be found through negotiation, even though an "official" PIARA experiment has not been started. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMhZA+kSWYarrFs6xAQGQHAQAkon2lq0lovouN6IwxMouN1vx2IqXtN2i ZK6N5QF584IcHjyJVVnU5PIrTKytapCDj9hE9Jqd1VuKzepakIuvRM0v4JYbBHXv id8ZqbjFoQTY12etRI7ztXeVTAXNBy01LMKq1NES+S2/CvOhgaAe+rpNCJVuOGfi d0mgbdfALe8= =fUBJ -----END PGP SIGNATURE-----

1 0

Re: Customer AS
by Sean Doran 17 Aug '96

17 Aug '96

Curtis Villamizar <curtis(a)ans.net> writes: > I think the percentage of dual homed /24s is small compared to the > number of prefixes that have not been aggregated with no good reason > at all. Yes. Moreover, most of the dual-homed /24s are also firmly in the second camp. Sean.

1 0

Re: Customer AS
by Per Gregers Bilse 17 Aug '96

17 Aug '96

What would happen if the customer used private address space and NAT & ALGs to hook this into the two providers' CIDR space? At worst, address space consumption would be doubled (if the customer really needs a full /24 internally), but when we're talking about a couple of /24s versus routing yet another prefix, I think that's preferable. Has anybody noticed that the net global routing table has bumped 40k a couple of times recently? Would the registries have problems with this approach? Another issue is that the I-must-be-multihomed-to-different-providers mantra frequently isn't anything else than a funny idea in somebody's head. -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: bilse(a)EU.net

2 1

Re: Customer AS
by Paul Ferguson 17 Aug '96

17 Aug '96

At 07:44 AM 8/17/96 -0400, Curtis Villamizar wrote: >From a purely pragmatic standpoint, what good is having a dual homed >prefix if Sprint and other major providers drops your prefix and you >can't get to places? Better to number into one of the provider's >aggregates. The more specific will go to everyone willing to take it >and anyone not willing to take the more specific can still get there. > Well, that was my point, in a roundabout way. :-) This is a Catch-22. - paul

2 1

MAE-West FDDI ring split.
by rmg＠ranma.com 16 Aug '96

16 Aug '96

Uhhh, do all of you know that MFS is splitting the shared FDDI ring tonite (Fri nite / Sat early AM) due to congestion? rob. ---------- From: owner-mae-west[SMTP:owner-mae-west@nsipo.arc.nasa.gov] Sent: Thursday, August 15, 1996 5:12 PM To: mae-west Subject: MAE WEST outage notification There will be a short outage at MAE WEST Saturday morning, approximately between 12:00am and 12:15am. The outage should last no longer than five minutes. During this time, we will be splitting the shared FDDI ring at MFS into two segments, each on a separate Gigaswitch port. This should alleviate congestion on the shared FDDI which has been causing packet loss recently. Peering to and from some of the stations on the shared FDDI and switched Ethernet ports will be affected while the cables are being moved. Steve

2 1

Re: Customer AS
by Chris MacFarland 16 Aug '96

16 Aug '96

Tim Crowell (GTE.NET) wrote- > Howdy folks, > > I would like to pose a question to the group about the best way > to implement the following; > > GTE has a customer who is a content provider that we have > allocated a class C out of our CIDR block. > > They have subsequently also ordered a second transit service > from ISP XYZ. > I would make them renumber with a new class c that was not in your CIDR block. Maybe they could get a class C from the swamp? > Our assumptions are: > 1. Customer will obtain an AS number to do BGP with both GTE and > XYZ. > 2. BGP will be established with both ISPs > 3. GTE will announce the class 'C' as both a part of our > aggregate CIDR block and as a specific /24 No you would just advertise the aggregate CIDR block, they should advertise the more specific route so when you peer with them their route is propagated with their AS number. > 4. XYZ will announce the class 'C' as a /24 only. XYZ should peer with them just as you have done. > 5. Both GTE and XYZ will supply a default route. If the client is carrying the full routing table should be default free, if they chose not to then they will have to decide on which provider should be the default route. Anyway my thoughts on an entity having multiple ISP's would want to have an autonomous system number routing his class C. I guess you could strip his AS and route is as your own but I dont think his would fall in line with current RFC's. I may be wrong though. Someone from this mailing list I am sure can enlighten us. > Explanation/Questions; > 1. Does this AS number have to be an officially registered AS or > can it be a reserved number? If they are advertising the route the rest of the world it would have to be registered. > The thought is that the Class 'C' > will be announced by both ISPs and strip the customers AS. The > AS would only be used to connect between ISPs. > It seems extremely wasteful for every little company that wishes > a dual homed network would have to get a registered AS. > They have registered domain names and a 24 bit network? Just kidding. This is beyond my political domain. > 2. We first had major heartburn with carving the 'C' out because > we just couldn't see having to add 2 additional announcements to > the internet routing tables but we have come to the conclusion > that there is no other way to do it. Would not there be just one additional route that is propagated by you? > We assume that we have to > announce the /24 in addition to our aggregate otherwise XYZ's > more specific announcement of our network would route all > traffic through them from the internet. That is correct > It just seems that if > there were a large number of these multi-homed Class 'C's that > the internet routing table would be flooded. (Maybe thats a > part of the problem. > > Now you understand why everyone is using Cisco 7500 series routers with 64 to 128 megs of RAM. > 3. As a followup, what would you do if a subnetted class 'C' > customer who only requires a dozen or so addresses but orders > connections to two ISP's. Do you burn a whole Class 'C' ???? Yeah. I dont think anyone will accept nor propagate a route larger than 24 bits. > 4. Is there anyway to accomplish what the customer wants that we > haven't considered. If it was me I would first of all register for a class C network address from the NIC in order to not break up you CIDR block. As I said before stripping their AS and adverstising the route with your origin and another ISP would not be thing to do. If I am wrong somebody please correct me. > > 5. I understand that we will have to submit the Class C to RADB > and create a "hole" in our aggregate to effectively represent > the network topology. > It would actually just be a more specific route that would seem seemless to you. > > PS. If i'm just being stupid about this feel free to say so. I > don't pout too long. Don't worry, everyone has BGP nightmares. Unfortunately it is one of the nightmares that reoccur every once a while.. Chris MacFarland President CompuNet 214.994.0190 chris(a)computek.net

2 1

Re: ANNOUNCEMENT: NANOG Registration
by William B. Norton 16 Aug '96

16 Aug '96

At 04:14 PM 8/15/96 -0400, Paul Ferguson wrote: >Bill, > >Can we register now and 'pay' on-site, similar to the IETF >registration process? We'd much prefer that you pay in advance; otherwise, there will be some delay in getting you fully registered on site. We'd rather deal with on-site payment as an exception. >- paul > >At 03:58 PM 8/15/96 -0400, William B. Norton wrote: > >>Looking forward to seeing you at the next NANOG, to be held Oct. 24-25 >>in Ann Arbor. Info about hotels, the University of Michigan, and Ann >>Arbor is available from: >> >> http://www.ra.net/~nanog >> >>At the past couple of NANOG meetings, we've discussed the possibility of >>implementing a registration fee to help offset the costs of hosting and >>running the meetings. With the increasing size of the conferences, it's >>become more and more difficult for organizations other than large >>corporations to cover the cost of hosting a NANOG. Our survey at the San >>Diego meeting indicated that most of you wouldn't find it a problem to pay >>a registration fee. For these reasons, we'll be implementing a $100 fee >>starting at the Ann Arbor NANOG. Our hope is to help offset host expenses, >>particularly for non-commercial hosting agencies. We will also use the funds >>to improve the consistency of the meeting by, for example, providing a >>high-power projector for laptop presentations. >> >>When you register for the NANOG there will be four ways to pay the >>registration fee: 1) by entering a credit card in the web form, 2) by >>faxing the credit card info, or 3) by calling it in and reading the >>necessary information, or 4) by mailing the registration information with a >>check. Details about how to do these are on the NANOG registration page. >> >>Cheers - >> >>Bill >>---------------------------------------------------------------------- >>William B. Norton <wbn(a)merit.edu> (313) 936-2656 >> > > > ---------------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 936-2656

1 0

Customer AS
by Tim Crowell 15 Aug '96

15 Aug '96

Howdy folks, I would like to pose a question to the group about the best way to implement the following; GTE has a customer who is a content provider that we have allocated a class C out of our CIDR block. They have subsequently also ordered a second transit service from ISP XYZ. Our assumptions are: 1. Customer will obtain an AS number to do BGP with both GTE and XYZ. 2. BGP will be established with both ISPs 3. GTE will announce the class 'C' as both a part of our aggregate CIDR block and as a specific /24. 4. XYZ will announce the class 'C' as a /24 only. 5. Both GTE and XYZ will supply a default route. Explanation/Questions; 1. Does this AS number have to be an officially registered AS or can it be a reserved number? The thought is that the Class 'C' will be announced by both ISPs and strip the customers AS. The AS would only be used to connect between ISPs. It seems extremely wasteful for every little company that wishes a dual homed network would have to get a registered AS. 2. We first had major heartburn with carving the 'C' out because we just couldn't see having to add 2 additional announcements to the internet routing tables but we have come to the conclusion that there is no other way to do it. We assume that we have to announce the /24 in addition to our aggregate otherwise XYZ's more specific announcement of our network would route all traffic through them from the internet. It just seems that if there were a large number of these multi-homed Class 'C's that the internet routing table would be flooded. (Maybe thats a part of the problem. 3. As a followup, what would you do if a subnetted class 'C' customer who only requires a dozen or so addresses but orders connections to two ISP's. Do you burn a whole Class 'C' ???? 4. Is there anyway to accomplish what the customer wants that we haven't considered. 5. I understand that we will have to submit the Class C to RADB and create a "hole" in our aggregate to effectively represent the network topology. Thanks for any assistance, PS. If i'm just being stupid about this feel free to say so. I don't pout too long. -- Tim Crowell - GTE Intelligent Network Services tcrowell(a)gte.net Voice: 214.751.3881

2 1

Re: ANNOUNCEMENT: NANOG Registration
by Paul Ferguson 15 Aug '96

15 Aug '96

Bill, Can we register now and 'pay' on-site, similar to the IETF registration process? - paul At 03:58 PM 8/15/96 -0400, William B. Norton wrote: >Looking forward to seeing you at the next NANOG, to be held Oct. 24-25 >in Ann Arbor. Info about hotels, the University of Michigan, and Ann >Arbor is available from: > > http://www.ra.net/~nanog > >At the past couple of NANOG meetings, we've discussed the possibility of >implementing a registration fee to help offset the costs of hosting and >running the meetings. With the increasing size of the conferences, it's >become more and more difficult for organizations other than large >corporations to cover the cost of hosting a NANOG. Our survey at the San >Diego meeting indicated that most of you wouldn't find it a problem to pay >a registration fee. For these reasons, we'll be implementing a $100 fee >starting at the Ann Arbor NANOG. Our hope is to help offset host expenses, >particularly for non-commercial hosting agencies. We will also use the funds >to improve the consistency of the meeting by, for example, providing a >high-power projector for laptop presentations. > >When you register for the NANOG there will be four ways to pay the >registration fee: 1) by entering a credit card in the web form, 2) by >faxing the credit card info, or 3) by calling it in and reading the >necessary information, or 4) by mailing the registration information with a >check. Details about how to do these are on the NANOG registration page. > >Cheers - > >Bill >---------------------------------------------------------------------- >William B. Norton <wbn(a)merit.edu> (313) 936-2656 >

1 0

ANNOUNCEMENT: NANOG Registration
by William B. Norton 15 Aug '96

15 Aug '96

Looking forward to seeing you at the next NANOG, to be held Oct. 24-25 in Ann Arbor. Info about hotels, the University of Michigan, and Ann Arbor is available from: http://www.ra.net/~nanog At the past couple of NANOG meetings, we've discussed the possibility of implementing a registration fee to help offset the costs of hosting and running the meetings. With the increasing size of the conferences, it's become more and more difficult for organizations other than large corporations to cover the cost of hosting a NANOG. Our survey at the San Diego meeting indicated that most of you wouldn't find it a problem to pay a registration fee. For these reasons, we'll be implementing a $100 fee starting at the Ann Arbor NANOG. Our hope is to help offset host expenses, particularly for non-commercial hosting agencies. We will also use the funds to improve the consistency of the meeting by, for example, providing a high-power projector for laptop presentations. When you register for the NANOG there will be four ways to pay the registration fee: 1) by entering a credit card in the web form, 2) by faxing the credit card info, or 3) by calling it in and reading the necessary information, or 4) by mailing the registration information with a check. Details about how to do these are on the NANOG registration page. Cheers - Bill ---------------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 936-2656

1 0