MAE-East - Operational question

Mailman List Mirror (Read Only)
1

Alex -

  When I have seen packet loss between two providers peering
  across the various shared medium FDDI interconnects, it has
  almost always been due to one or more of the following
  situations :

   - Network A has congested pipe(s) into the L2 thing.
   - Network B has congested pipe(s) into the L2 thing.
   - Network A has congested pipe(s) to the rest of
     their network.
   - Network B has congested pipe(s) to the rest of
     their network.
   - The peering session between Network A and Network B
     is traversing the network of FDDI switches at the IX,
     as the networks are not peering across a FDDI switch
     that they have in common, and the links are congested.

  The above situations are mostly correctable, assuming :

   - Additional FDDI ports are available.
   - Additional capacity to their network is obtainable.

  Other things one can do :

   - FD-FDDI
   - Peering session can be moved to a FDDI switch that
     the two networks have in common.

  Don't get me wrong-- certainly one should explore means
  of interconnecting beyond the shared medium FDDI option.
  The various ATM public peering services seem a viable
  way of scaling public peering as it exists today... while
  also affording a network the opportunity to put "private
  [atm-vc] peering" on their marketing web pages. :wink:

  This is my personal observation- hope it helps.

- jsb

2

The others, as you've observed are reasonably fixable problems, given
inclination, but this last problem is non-trivial to fix, because of
the physically distributed nature of some interconnects.

I'm not yet certain as to whether ATM replacement of FDDI is the right
solution to this problem.

-dorian

3

I'm not yet certain as to whether ATM replacement of FDDI is the right
solution to this problem.

-dorian

  Denial, it's not just a river in Africa....... :\

(I know, it is *not* that cut and dry, but I couldn't resist :wink:

My two cents.....
  
  The ATM exchanges/naps, while certainly not as taxed as
MAEE, are presenting me with better paths.... ATM's ability
to isolate damage to the individual that has oversubscribed
seems to scale...

  It seems the philosophy:

  "If I oversubsribe, I make more money, yet trash my neighbors
   paths, as well as mine" doesn't produce the altruistic
   behavior one might expect....

   However, "If I oversubscribe, I trash MYSELF and ANYONE
   trying to get to ME, and no one else"
   seems to work somewhat better.....

   *Pure* communism was a great ideaology! However,
   its failure, for the most part, was cited
   as "not accounting for human nature"

   Go figure :\

  Not that this will help if it is NAP trunks that are saturated,
but, production capable OC12 and up interfaces, do. And don't forget,
most carrier class switches have *non-blocking* backplanes..... :slight_smile:
At least that puts the solution back into *your* hands....

     I, for one, have an 0C3-C awaiting your descision.

  (And a religion :wink:

4

Communism, *NOT* marxism.

   Lets see:

     > conf t
     > int nanog 0
     > no ip directed-communism
     > access-group 66 IN
     >^z
     >
     > access-list 66 deny MARXISM
     > access-list 66 deny _POLITICS_
     > access-list 66 deny POLITICAL_PARTIES
     > access-list 66 permit PHILOSOPHY
     > access-list 66 permit IDEAOLOGY
     >
    
   And now I leave the remainder of this discussion to OFF NANOG.
(and your local Poli-SCI PHD)

This config doesn't seem to be helping my routing much.... But,
in your defense, I am actually saying the opposite of what you *think*.

(I am saying it *doesn't* work , but making a distinction between
the ideology, and "supposed" implementations going by that name,
that *fine grained* distinction *is* the point :frowning:
  
  The depths of greed that *some* of humanity exhibit,
  being the fatal flaw for both plans. (FDDI&COMMUNISM)

.)

(Darn lasers!)

foo wrote: