- Test - lists.nanog.org

Re: consistent policy != consistent announcements
by Vince Fuller 14 Mar '97

14 Mar '97

At 11:31 AM -0800 3/13/97, Vince Fuller wrote: >Well, if that "candidate path" is, in fact, one of Randy's customer, then >I would expect him to "cold-potato" route toward it. One would think that >to be part of the service that his customer is purchasing. I think that his internal routing policy and service to his customer is really irrelevant to the question at hand, except insofar as its side-effects affect you. Yup, it isn't my business to care about his internal routing, just to insure that he presents appropriate routing to me (i.e. I care about the functional specification not the design details...) I was merely speculating, perhaps incorrectly, on what might be going wrong so that I don't see what I consider consistant routes. Ah, I finally see the problem. In essence, Randy's (announcement) policy assumes that a destination is either in the set of customer routes OR the set of peer routes, but not both. But in this case we have a destination which is in both. The side-effect ends up making you "cold-potato" route to destinatons in the (customer + peer) intersection. The question is, does it make sense for a destination to be considered to be in both sets? If "peer" is supposed to mean "not-customer" then the answer is probably no, there is (should be) no intersection between "customer" and "not-customer". See your objection above - I really don't care how the routes are handled internally to Randy's net; I just want to see routes for the same prefixes with equal preference (as path length, origin, etc.) at all interconnects. --Vince

1 0

RE: Remote Operations question
by owen＠DeLong.SJ.CA.US 14 Mar '97

14 Mar '97

FWIW, Crestron has some goodies that will do the trick (20 Amps) at about $80/port + controller (per site). We're trying to get them to add some voice-response DTMF control capability. Might be good to call them and tell them you're an ISP that would be interested in what ConXioN has been asking for. Might help to convince them there's a market for it. Their specialty is remote control for theater/auditorium lighting and audio/ visual stuff, but their solution looks pretty keen. They're really close to exactly what I'd want. Owen > Any thoughts on the peering question? > > At 06:09 PM 3/8/97 -0700, Rodney Joffe wrote: > >Thanks Alex...... > > > >As far as why........ well let's see; when the router gets hosed in > >our cage, and we open a ticket with MFS, and it takes 5 hours before > >they arrive..... it seems a lot more logical to be able to power cycle > >it out of band without waiting. Now if MFS's facility was truly a 24 x 7 > >facility, which you would expect for a place that was that important :-) > >By the way, your $500 is much less than the last bill they sent us ... > >$750. > > > >Amazing... and we didn't even see the gun in their hands. > > > >Rodney Joffe > >Genuity Inc., a Bechtel company > >http://www.genuity.net > > > > > >>-----Original Message----- > >>From: Alex Rubenstein [SMTP:alex@nac.net] > >>Sent: Saturday, March 08, 1997 4:22 PM > >>To: Rodney Joffe; 'nanog(a)merit.edu' > >>Subject: Re: Remote Operations question > >> > >> > >>Leviton has some stuff the we use, they have some things that can do 20 > amps. > >> > >>The better question; why? What is the 7513 doing that you need it to be > >>rebooted? I can be paid to go do it for you; lets say, $500 ea time? :-) > >> > >> > >>At 04:18 PM 3/8/97 -0700, Rodney Joffe wrote: > >>>Is anyone using any kind of out of band controlled power system that > >>>will support remote power cycling of multiple devices with high power > >>>ratings? I'd like to be able to cycle individual components in our racks > >>>at NAPs (especially MAE E!) including 7513s. All the devices we've > >>>found are limited to 15 amps total. I think a 7513 requires 20amps on > >>>its own. > >>> > >>>Thanks > >>> > >>>Rodney Joffe > >>>Genuity Inc., a Bechtel company > >>>http://www.genuity.net > >>> > >>> > >>> > > >

1 0

RE: Remote Operations question
by Alex Rubenstein 14 Mar '97

14 Mar '97

Any thoughts on the peering question? At 06:09 PM 3/8/97 -0700, Rodney Joffe wrote: >Thanks Alex...... > >As far as why........ well let's see; when the router gets hosed in >our cage, and we open a ticket with MFS, and it takes 5 hours before >they arrive..... it seems a lot more logical to be able to power cycle >it out of band without waiting. Now if MFS's facility was truly a 24 x 7 >facility, which you would expect for a place that was that important :-) >By the way, your $500 is much less than the last bill they sent us ... >$750. > >Amazing... and we didn't even see the gun in their hands. > >Rodney Joffe >Genuity Inc., a Bechtel company >http://www.genuity.net > > >>-----Original Message----- >>From: Alex Rubenstein [SMTP:alex@nac.net] >>Sent: Saturday, March 08, 1997 4:22 PM >>To: Rodney Joffe; 'nanog(a)merit.edu' >>Subject: Re: Remote Operations question >> >> >>Leviton has some stuff the we use, they have some things that can do 20 amps. >> >>The better question; why? What is the 7513 doing that you need it to be >>rebooted? I can be paid to go do it for you; lets say, $500 ea time? :-) >> >> >>At 04:18 PM 3/8/97 -0700, Rodney Joffe wrote: >>>Is anyone using any kind of out of band controlled power system that >>>will support remote power cycling of multiple devices with high power >>>ratings? I'd like to be able to cycle individual components in our racks >>>at NAPs (especially MAE E!) including 7513s. All the devices we've >>>found are limited to 15 amps total. I think a 7513 requires 20amps on >>>its own. >>> >>>Thanks >>> >>>Rodney Joffe >>>Genuity Inc., a Bechtel company >>>http://www.genuity.net >>> >>> >>> >

1 0

Re: consistent policy != consistent announcements
by Vince Fuller 13 Mar '97

13 Mar '97

By the way, this general fact about BGP (external announcements are governed by internal route selection) also means that for Randy to always announce the same route to his peer, he would have to change his own, internal routing policy to do cold-potato routing to one of the two candidate paths. This doesn't seem like a reasonable thing for a peer to demand he do. Well, if that "candidate path" is, in fact, one of Randy's customer, then I would expect him to "cold-potato" route toward it. One would think that to be part of the service that his customer is purchasing. I certainly shouldn't have to do "cold-potato" routing to his customer, as that customer isn't purchasing anything from me. --Vince

2 1

Need Solid Sprintlink Contact
by Patrick J. Chicas 13 Mar '97

13 Mar '97

Greetings All, In one of my current lives, we have a need to establish peering connectivity with Sprintlink at their Anahiem POP. I am looking for a solid Sprintlink Sales Engineer that can help. Please, pass on your recommendations. Regards Patrick J. Chicas

1 0

Re: consistent policy != consistent announcements
by Vince Fuller 13 Mar '97

13 Mar '97

> My first concern is the loss of information when the route to M isn't > announced. This causes unfairness when traffic ends up taking the 'long' > route. My peer fears that and would like me to fix it. I don't understand how I can do that in a simple maintainable fashion. > More than likely your peer is doing the same thing unto you. Quite possibly, but they won't 'fess up to it. And I don't want to whine at them unless I know how to constructively address the opportunity (the peer is a Californian:-). A correction: the peer individual is definitely not a native Californian, though he does reside there. As best I can tell, we present consistant routes to all of our peers. How do I know this? Because I set up test routers to peer with our public interconnect points and run periodically run my consistancy checker against them. If my peer does not agree that my policy is reasonable and a consequence of current tools, their reaction may be to reject inconsistent announcements thereby increasing the likelihood that no path is propagated. >From our point of view, we aren't seeing any route which can be used for shortest-exit to your multi-homed customers. Why? Probably because we don't peer with the other ISP which serves those customers. The result is that we have to backhaul traffic to other interconnect points, something which is expensive for us and inconsistant with our normal peering policy. I can see why you present inconsistant routes to us but I'm not sure that I understand why you'd prefer a customer prefix via a direct connection to them at one point in your network but via a connection to another provider at a different point in your network. That would seem internally inconsistant to me. Is this deliberate behavior to do shortest-exit within your network toward your customer? --Vince

4 3

Re: consistent policy != consistent announcements
by Sean Donelan 13 Mar '97

13 Mar '97

>It's a BGP design point for a router to only announce the route(s) that >it is actively *using*. In your comment above, > >a. If a router has a route it believes is "best", why isn't it using > it? I believe this is why it is called a "policy routing," to force sub-optimal behavior compared to the normal selection algorithm of the routing protocol. You may have a 'best' route to a destination you use internally, but you don't advertise it outside of your AS because of policy reasons. The standard example is not announcing routes heard from peers to other peers. This keeps all of MCI's traffic from being routed through a small customer in the Northwest. You may also have a 'lessor' path, which you would advertise, except its not the 'best' route according to your policy, i.e. a multi-homed customer with unequal cost lines. Policy: Shortest Path X X A X D X D C X D C +----+ +----+ -----| A |-----| B |----- X A B / +----+ +----+ / | \ | X | \ | \ | \ | \ +----+ +----+ ----| D |-----| C |----- X A C +----+ +----+ X X A X A X D X A B Policy: Fastest/Biggest Path between X & A(T1) & D(T3) X D X D A X X D C X C D +----+ +----+ T1-----| A |-----| B |----- X D A B / +----+ +----+ / | \ | X | \ | \ | \ | \ +----+ +----+ T3-----| D |-----| C |----- X D C +----+ +----+ X X D X A X D A X D A B Policy: Shortest Path/Do Not Announce Peer-to-Peer X X A X D +----+ +----+ -----| A |-----| B |----- X A / +----+ +----+ / | \ | X | \ | \ | \ | \ +----+ +----+ -----| D |-----| C |----- X A +----+ +----+ X X A X A X D Policy: Fastest/Biggest Path between X & A & D/Do Not Announce Peer-to-Peer X D X +----+ +----+ T1-----| A |-----| B |----- No Route / +----+ +----+ / | \ | X | \ | \ | \ | \ +----+ +----+ T3-----| D |-----| C |----- X D +----+ +----+ X X D X A >b. Regardless of the answer, the router should announce the route it is > using for its own forwarding. To do otherwise would be to lie about > the path which traffic will take to the advertised destination. > > If policy forbids it from announcing the route it is using, so be > it. (Or, if that's not acceptable change the policy.) Policy is a business decision, not a technical decision. You can be unfair to C by congesting the line XA. Or you can be unfair to B by announcing a longer path XDAB, or no path. Who do you care more about B or C? All animals are equal, but some animals are more equal than others. Yes, you might be able to play enough games with this simple example, to force things to work 'right.' But the mesh is being extended all the time. >By the way, this general fact about BGP (external announcements are >governed by internal route selection) also means that for Randy to >always announce the same route to his peer, he would have to change his >own, internal routing policy to do cold-potato routing to one of the >two candidate paths. This doesn't seem like a reasonable thing for a >peer to demand he do. In any business negotiation, either side can demand whatever they want. But the other side doesn't have to give it to them. This really isn't an operational issue, other than the engineers need to keep their managers informed of the consequences of managerial decisions. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: consistent policy != consistent announcements
by Vince Fuller 13 Mar '97

13 Mar '97

Vince Fuller writes: >I can see why you present inconsistant routes to us but I'm not sure that >I understand why you'd prefer a customer prefix via a direct connection to >them at one point in your network but via a connection to another provider >at a different point in your network. That would seem internally >inconsistant to me. Is this deliberate behavior to do shortest-exit within >your network toward your customer? We have some customers that have specifically requested this sort of arrangement. Hmm. Do you treat the customer routes received from the other peer to be "customer" routes, i.e. will you provide transit for them and re-advertise them to your interconnect peers? If not, then you'll prevent interconnect peers from using shortest-exit to get to those customer routes, which may be considered a problem by those peers. --Vince

2 1

IP over ATM overhead
by Stephen Balbach 13 Mar '97

13 Mar '97

We are installing an ATM backbone connection and wondering what level of overhead can be expected. Ive read from %10 to %50 - this will be a LAN connection so we can assume almost no cell loss. Our provider has said on average %12 bandwidth is overhead. It will be a Cisco->Cisco LAN configuration. Thanks! Stephen Balbach VP ClarkNet

4 3

Re: IP over ATM overhead
by pkavi＠pcmail.casc.com 13 Mar '97

13 Mar '97

The complete answer is that it depends upon packet size distributions. Let's assume that typical Internet type traffic patterns, which tend to have high percentages of packets at 40, 44, and 552 bytes. If you have a DS3 backbone, and have PLCP turned on, the maximum cell rate is 96,000 cells/sec. If you multiply this value by the number of bits in the payload, you get: 96000 cells/sec * 48 bytes/cell * 8 = 36.864 Mbps But this is unrealistic, as it assumes perfect payload packing. There are two other things that eat into the overhead value, namely the wasted padding, and the 8 byte SNAP header. It's the SNAP header which causes most of the problems, forcing most small packets to consume two cells, with the second cell to be mostly empty padding. This causes a loss of about another 16% from the 36.8 Mbps ideal throughput. So the total throughput ends up being (for a DS3): DS3 Line Rate: 44.736 PLCP Overhead - 4.032 Per Cell Header: - 3.840 SNAP Header & Padding: - 5.900 ========= 30.960 Mbps So, from a DS3 line rate of 44.736 Mbps, the total overhead is about 31%. Hope this helps. Prabhu Kavi Manager, Network Architecture Group Cascade Communications. ______________________________ Reply Separator _________________________________ Subject: IP over ATM overhead Author: Stephen Balbach <stephen(a)clark.net> at SMTPLINK Date: 3/13/97 10:47 AM We are installing an ATM backbone connection and wondering what level of overhead can be expected. Ive read from %10 to %50 - this will be a LAN connection so we can assume almost no cell loss. Our provider has said on average %12 bandwidth is overhead. It will be a Cisco->Cisco LAN configuration. Thanks! Stephen Balbach VP ClarkNet

1 0