Week 1 Status Report

 Just picking up on a little in this mail.

"Dale S. Johnson" <dsj at merit.edu> writes:
  * 
  * Fine here.  Any mechanism you'd like would be ok.  Perhaps "patch", with
  * full releases the last day of every month, and a patch distribution numbere
  * d
  * the day of the month for the 1st, 2nd, ...  ?  
  * 
This is fine for the DB. For pride tools (which I'm not sure you mean) I
don't want anything too restrictive. Currently it is still quite early days
for the tools so we need flexibility to release as we need rather than
by date or anything else.

  * Since there is nothing sensitive about this info (and since you have
  * other sites who would like it), anonymous ftp might be fine.  How about
  * an "rsh ftp get <filename>" equivalent to cause the transfers to
  * happen?  (Or "ftp put", if you don't mind passwords coded into cron
  * jobs, but the exec gives the power to start processing of the data as
  * well.  We've occasionally done this with a tiny special-purpose server,
  * to avoid the rsh/rcp security problems).
  * 
  * > 
  * >   >  * Are there similar issues that you can think of that we need to res
  * olve
  * >   >  * before announce availability of the conbined service?
  * >   > 
  * >   > Not sure. Maybe Daniel knows some things. I'd make sure you test the
  * >   > whole stuff thoroughly before announcing anything.
  * > 
  * > We need to establish "source:" names and exact descriptions of what they
  * > mean. I suggest something like MERIT-RR for your routing data.
  * 
  * Fine.
  * 
  * > We need to make the tools just a little more configurable in the sense
  * > of how they use different whois servers on "source:"s.
  * 
  * Ok;  should this be on your queue, or should we help?  
  * 
It is on our queue. The whole built-in whois side will allow more configurable
options. 

  * The "-h <hostname>" parameter seems to work, and Andy says it is easy to
  * modify the destination in your setup file.  An environmental variable *migh
  * t*
Agreed - This will be in the next release.

  * be useful.  (?) If these are being changed anyway, how about a "port" flag 
  * for
  * use with debug whois servers.  Other ideas?

Yep this can also be added.
  *  
  * > I would like to make a *joint* announcement about this if this is politic
  * ally
  * > acceptable to you. 
  * 
  * Wonderful!  Elise?
  * 
  * 
  * --Dale

I'd like to bring up one other thing which is important in the tools which
may have been overlooked. That of nets which are DMZs. Network entries
have an attribute known as ias-int. This allows the network owner to register
interfaces on his net belonging to other ASes. This is a special case
and away from the one net / one AS idea we have. This is not guarded 
but should be used wherever possible.
I enclose a documnet which details this attribute. This will also be in the
revised ripe-81 documnet (still in draft).

	--Tony.











            Description of Inter-AS Networks in the RIPE
                          Routing Registry



                             Tony Bates
                         Daniel Karrenberg

                       Document-ID: ripe-103

                            Addendum to
               Representation of IP Routing Policies
                   in the RIPE Database (ripe-81)





What is an Inter-AS Network ?

Inter-AS IP networks are those networks which connect multiple auto-
nomous systems (1).  An inter-AS network exists for the  purpose  of
passing traffic and routing information between different autonomous
systems.  The most simple  example  of  an  inter-AS  network  is  a
point-to-point  link, connecting exactly two ASes.  Each end of such
a link is connected to an interface of router living in each of  the
autonomous  systems.  More  complex examples are broadcast type net-
works with multiple interfaces connecting  multiple  ASes  with  the
possibility of more than one connection per AS.


















_________________________
(1) Inter-AS networks are currently called FIXes, IXFs,
DMZs, NAPs, GIX and other names.




ripe-103.txt              December 3, 1993
                               - 2 -


Which additional information is needed?

Consider the following example of three routers  1,  2  and  3  with
interfaces a through f  connected by two inter-AS networks X and Y:


         X              Y
a1b     ---    c2d     ---    e3f


Suppose that network X is registered in the routing registry as part
of  AS1  and  net  Y  as part of AS3. If traffic passes from left to
right prtraceroute will report the following sequence of  interfaces
and ASes:

        a in AS1
        c in AS1
        e in AS3

The traceroute algorithm enumerates only the receiving interfaces on
the  way  to the destination.  In the example this leads to the pas-
sage of AS2 going unnoticed.  This is confusing to the user and will
also  generate exceptions when the path found is checked against the
routing registry.


For operational monitoring tools such as prtraceroute it  is  neces-
sary to know which interface on an inter-AS network belongs to which
AS.  If AS information is not known about interfaces on an  inter-AS
network,  tools  like  prtraceroute cannot determine correctly which
ASes are being traversed.


Routing Registry Format

All interfaces on inter-AS networks will be described in a new  ias-
int  attribute of the corresponding network object in the RIPE data-
base.  The ias-int attribute has the following syntax:

ias-int:   <interface-address> <autonomous-system>


The <interface-address> must be an address within the  corresponding
intenum  and  <autonomous-system>  must  be  of  the form AS<number>
referring to an aut-num object in the database.












ripe-103.txt              December 3, 1993
                               - 3 -



For example:
inetnum:   193.193.193.0
netname:   INTER-AS-EXAMPLE
descr:     This is a hypothetical inter-as network.
descr:     It might be called a NAP, FIX, GIX, IXF, DMZ,
descr:     Mehrfachdienstanbieterkommunikationseinrichtung or ...
country:   DE
admin-c:   Werner Mueller
tech-c:    Paul Schmitz
tech-c:    Hans Meier
changed:   ripe-dbm at ripe.net 920714
aut-sys:   AS4711
ias-int:   193.193.193.1 AS123
ias-int:   193.193.193.3 AS4711
ias-int:   193.193.193.9 AS789
source:    RIPE

Note that the interface 193.193.193.3 is described although it is in
the same AS as the network.  This is recommended practice.


The update procedure for the ias-int attribute will  be  the  normal
update  procedure  for network objects.  The attribute does not need
to be guarded because it does not influence routing policy of opera-
tional traffic.



In which AS does an Inter-AS Network belong?

Only one AS announces an inter-AS  network  externally.   The  other
ASes connected to the inter-AS network will probably carry this net-
work in their internal routing for redundancy but will not  announce
it to other ASes.

In exceptional cases more than one AS may need to originate external
routing information about the inter-AS network, This kind of routing
setup cannot be described within the framework  of  ripe-81  and  is
generally  discouraged.   Tools  using a ripe-81 type registry could
take heuristic hints from the ias-int attributes when they encounter
such situations.















ripe-103.txt              December 3, 1993




-------- Logged at  Tue Feb 22 15:56:09 MET 1994  ---------