Re: Draft AUP

[Randy Bush <randy@psg.com>]

> 4. Subscribers will make use of a unique Autonomous System Number assigned
> by a suitable registration authority. As of this writing, the top-level
> registration authority in the world is the InterNIC. Details on obtaining
> an Autonomous System Number are available at the following URL:
> ftp://rs.internic.net/templates/asn-template.txt

internic no longer exists.  you get an asn from apnic, arin, or ripe.  i
suggest just saying that the connectee has a properly acquired asn.  see rfc
2901

> 6. Members shall not generate unnecessary route flap, or advertise
> unnecessarily specific routes in peering sessions with other Members
> across the UIXP.

this and many of the following points about bgp, routes, etc., step up to
layers three and above.  at a layer two exchange, these things are usually
left to the bilat agreements between the peers.  your putting them here,
unnecessarily restricts the freedom of the customers' layer three and above
policies.  

fyi, i will append a public peering agreement of a provider i know.  this
gives you an idea of the things the peers like to put in their agreements,
and hence may not appreciate the ix specifying.

> 9.  Members must, on all interfaces connected to the UIXP, disable: Proxy
> ARP, ICMP redirects, CDP, IRDP, Directed broadcasts, IEEE802 Spanning
> Tree, Interior routing protocol broadcasts, and all other MAC layer
> broadcasts except ARP.

cdp is usually not disabled.  other stuff is cool.

> 11. Members shall not announce ("leak") prefixes including some or all of
> the UIXP peering LAN to other networks without explicit permission of the
> UIXP.

you don't mean this.  e.g. i am sure you want members to annouce to their
customers' networks, or traceroutes do not work.

and, if you're following the discussion on the ripe lists, no one has yet to
come up with a clear statement of the goal here.  it's really the tier one
peers (none of which are likely to be at the uixp) who agree not to exchange
ix routes with eachother.

> 15. Members will not install 'sniffers' to monitor traffic passing through
> the UIXP, except through their own ports. The UIXP may monitor any port
> but will keep any information gathered confidential, except where required
> by law or where the UIXP has determined a violation of this Memorandum of
> Understanding.

you may want to phrase this so that you can publish aggregated statistics 

> 16.Members will not circulate confidential correspondence on the UIXP
> mailing lists to non-Members.

i suggest that you instead say that no confidential correspondence may be
posted by anyone to the uixp mailing list.

> 18. Members may not connect more than two wide-area circuits to routers
> housed at the UIXP. This restriction may be overridden on a per-case basis
> at the discretion of the UIXP.

why this restriction?

> 19. Members may not directly connect customers who are not UIXP Members via 
> circuits to their router housed in any UIXP rack. 

i.e. they may not put in private peering inter-member interconnects?  why
not?

> 20. Members should not routinely use the UIXP for carrying traffic between 
> their own routers.

if i have two routers on the mesh (for redundancy i choose to pay for two),
then 50% of the traffic from a peer (unless meds are used) will go to the
'wrong' router.  so 50% of my inbound traffic will be routinely shifted
between two of my own routers.

> 21. Members will be required to install routers that support the full BGP-4 
> standard. A list of recommended routers will be made available online.

i suggest you do not want to start down this path.  aside from other things,
you will preclude testing new things (verio ran an aplha juniper on paix
quite successfully), and you will soon find yourselves in the certification
business (i want to run a dell c600 latitude laptop running freebsd and some
experimental routing software from <beep>).

> 22.The technical committee will set up certain monitoring features on the
> server at the UIXP.  Certain UIXP Members will be asked to have their ops
> departments monitor these features such that any problems can be referred
> to the UIXP technical support personnel as quickly as possible.

the goal here is a distributed customer-supplied noc?  seems a good way to
bootstrap inexpensively.  cool!

> 23.Subscribers will use a standard framing mechanism. For Ethernet
> connections, the framing is specified in RFC 894. Reference URL:
> ftp://ftp.isi.edu/in-notes/rfc894.txt

not sure you want to be this specific, but can't see direct harm.  some nice
generic statement about standards conformance might be good.

> 24.Changes in this policy shall be made through a majority vote of the 
> participants at any annual or special meetings. 

i am not a big fan of technology by democracy.

randy

---

Technical  : for all trouble and problems with established peers
Problems     noc@verio.net  +1 800 551-1630 or +1 214 290-8620

Abuse/SPAM : SPAM and similar abuses
             abuse@verio.net

Security   : for all other security-related issues
             security@verio.net

Peering    : for negotiations of changes in peering points etc
             peering@verio.net
             do NOT send to this address for technical problems with
             existing circuits

---

AS         : 2914
AS-macro   : AS-VERIO
MFS-East   : 192.41.177.121   r00.mclnva01 Vienna FDDI
             192.41.177.196   r01.mclnva01 Vienna FDDI
             198.32.187.223   r00.mclnva01 VPI/VCI:0/323 aal5snap [0]
MFS-West   : 198.32.136.80    r00.snjsca01 San Jose FDDI [1]
             198.32.136.126   r01.snjsca01 San Jose FDDI [1]
NASA-Ames  : 198.32.136.89    r00.mtvwca02 Sunnyvale FDDI [1]
PAIX       : 198.32.176.14    r06.plalca01 GigE
             198.32.176.47    r05.plalca01 GigE
AADS       : 206.220.243.34   r00.chcgil01 VPI/VCI:3/40 aal5snap
LINX       : 195.66.224.138   r00.londen02 100baseT
             195.66.224.139   r01.londen02 100baseT


[0] - Verio is using WorldCom's new version of Peermaker for MAE-ATM.
      We are currently limiting the test to MAE-East ATM.  For the test we
      will be requesting the PVCs to be built.  Our peers simply need to
      accept the request at <https://peermaker.wcom.com>.  Peers use their
      regular peermaker username and password.  Below is the relevant data
      on Verio's MAE-East ATM connection, and the provisioning parameters.

      ISP Name:      Verio
      Circuit ID:    o281b81b0052
      ASN:           2914
      IP Address:    198.32.187.223
      Verio's VPI:   0
      Verio's VCI:   323 (4th octet of our address + 100)
      Peer's VPI:    0
      Peer's VCI:    4th octet of peer's ip address + 100
      Bandwidth:     100 cps
      Service class: Best Effort

      We are currently only using best effort for our PVCs, and will not be
      provisioning guaranteed bandwidth across the MAE-ATM.  We set the
      bandwidth to the same rate on all PVCs, 100 cps.

      Beware that, if you have a connection to Verio on the MAE-East FDDI,
      and if you insist on disconnecting the FDDI, that Verio may decide
      MAE-East ATM is not suitable (remember, we are using it in test mode),
      and you may no longer meet our two-coast peering condition and thus
      become in danger of losing Verio peering.

[1] - Please peer with MFS-West or Ames only in the same location.  Do not
      use the overburdened inter-site links.

---

To initiate peering, you need to send email agreeing to the following:

General policy for public peering

    The Verio backbone peers with other transit ISPs, and only at the global
    exchange points to which the Verio backbone is connected.

    Verio does not peer with any ISP which is a Verio transit customer.

    In the United States, peering must be at least on both coasts, or one
    coast and Europe, with the peer having sufficient connectivity between
    points to support closest exit routing.

    In Europe, one peering is sufficient for now.  Verio may choose to
    announce the same routes in Europe as the States, but Verio reserves the
    right to announce only that subset of our routes which are local.  Of
    course, peer may choose to do either.

    Peer agrees to peer locally with Verio at any non-US peering points at
    which both appear.

    Peer is responsible for keeping Verio informed of their current contact
    information.  Please send infomation and updates to:
       peering@verio.net
       noc@verio.net

Technical Policy:

    Verio requires all BGP sessions have MD5 signature configured.

    Verio requires that peers permit LSR, loose source routing, at least at
    the routers bordering the peering.

    Verio requires that peers announce the same routing policy at all points
    where they peer with Verio.

    Peers are encouraged to, have NOCs with email addresses, phone numbers,
    and 24x7 coverage.

    Peers must agree to actively cooperate chasing security violations,
    denial of service attacks, and similar incidents.

    Peers must agree to actively respond to all technical issues within 48
    hours.  Non-response may result in depeering and other attention-getting
    mechanisms.

    Peers must not abuse the peering relationship by doing any of the
    following non exhaustive list: pointing default, resetting next hop,
    selling or giving next hop to others, etc.

    Verio reserves the right to not peer with anyone as Verio sees fit and
    to terminate any peering at any time with 30 days notice.

    Verio reserves the right to change this peering policy with 30 days
    notice.

-30-

--
This is the techies mailing list. The list archives can be found at http://uixp.co.ug/archives .