Re: RCC data

["Matthew Williams" <]

Hello again,

You are right about the line "Routes from Loc-RIB dump at 2002-05-29
02:44:00". It lists the first insertion on the last day of the specified
time interval. We have now changed it to the last LOC-RIB insertion on
the first day of specified time interval, which is more consistent with
the output. Apologies for the confusion. 

Your other points are related to the prefix (or AS) query only looking
at RIB entries from the first day in the interval specified by the user.
The exact time in hh:mm:ss is ONLY relevant for the updates, which
implies that the query output for the RIB can change throughout the
current day depending on the amount of processed RIB dumps. Please
recall from my previous email:

===============

Prefix 205.136.164.0/22 
From   20020521 23:00:00      
To     20020522 16:30:16   
RRC Box  RRC01, LINX 
Type All 
----
Comment:
This prefix query will retrieve all entries in the RIB table for prefix
205.136.164.0/22 on the 21st of May and all updates observed by the RIS,
starting from 20020521, 23:00:00 until 20020522, 16:30:16. If this is
known then the output should be easier to interpret. Please remember
that all 
timestamps are UTC.

================
The idea is that the RIB entries are the starting point and that
announcements/withdrawals will say something about changes to the
Information Base during the specified time-interval. The downside is the
coarse granularity (up to 24h) for comparisons between RIB dumps using
our tools. I suggest looking at raw files using MRT
(http://www.mrtd.net) if more precise analyses are required.
 
I hope all is clear now ;)

Best regards,
Matthew Williams

Ps. Please cc "ris-users@localhost"

-----Original Message-----
From: ila.dema@localhost [
	    
	    
] 
Sent: 30 May 2002 11:59
To: ris@localhost
Cc: gdb@localhost
Subject: 
Importance: High


Hi,

we are Ilaria De Marinis and Federico Mariani, again.

First of all, thanks a lot for promptly answering our e-mail. However,
we still have some doubts.

Let us consider the following query, performed on May 29 at 11:40.

> Prefix:  61.1.0.0/24
> From  :  2002-05-29  00:00:00
> To    :  2002-05-29  05:00:00	    
> RRC Box: RRC00  
> Type:    All 

The first line of the result was:

> Routes from Loc-RIB dump at 2002-05-29 02:44:00

Actually, which is the exact meaning of that timestamp? 
Is it the time of the last dump of May 29 inserted into the database
before performing the query?

In the result, the last entry of the LOC-RIB was:

> 61.0.0.0/8  2002-05-29 01:54:32	193.0.0.56 333 12859 6461 7336 	

After that line we had the usual list of updates.

We repeated exactly the same query, the same day (May 29), at 15:20. We
had the same result (including the first line):

> Routes from Loc-RIB dump at 2002-05-29 02:44:00

plus the following entries for the LOC-RIB:

> 61.1.0.0/16  2002-05-29 03:28:28  64.211.147.146  3549 4755 9829 	
> 61.1.0.0/20  2002-05-29 03:28:28  64.211.147.146  3549 4755 9829 	
> 61.1.0.0/20  2002-05-29 03:28:31  195.66.224.112  3549 4755 9829 	
> 61.1.0.0/16  2002-05-29 03:28:31  195.66.224.112  3549 4755 9829 	
> 61.1.0.0/16  2002-05-29 03:28:37  193.148.15.34	  1103 3549 4755
9829 

> 61.1.0.0/20  2002-05-29 03:28:37  193.148.15.34	  1103 3549 4755
9829 

> 61.1.0.0/16  2002-05-29 03:28:48  193.148.15.85	  3257 3549 4755
9829 

> 61.1.0.0/20  2002-05-29 03:28:48  193.148.15.85	  3257 3549 4755
9829 

> 61.1.0.0/20  2002-05-29 03:28:58  202.12.29.64	  4608 7474 3561
3549 4755
9829 	
> 61.1.0.0/16  2002-05-29 03:28:58  202.12.29.64	  4608 7474 3561
3549 4755
9829 	
> 61.1.0.0/20  2002-05-29 03:29:03  192.205.31.33	  7018 3549 4755
9829 

> 61.1.0.0/16  2002-05-29 03:29:03  192.205.31.33	  7018 3549 4755
9829 

> 61.1.0.0/20  2002-05-29 03:29:08  192.65.184.3	  513 209 3549
4755 9829
	
> 61.1.0.0/16  2002-05-29 03:29:08  192.65.184.3	  513 209 3549
4755 9829
	
> 61.1.0.0/16  2002-05-29 03:29:21  212.20.151.234  13129 6461 3549 4755
9829 	
> 61.1.0.0/20  2002-05-29 03:29:21  212.20.151.234  13129 6461 3549 4755
9829 	
> 61.1.0.0/16  2002-05-29 03:29:22  193.0.0.56	  3333 9057 3549 4755
9829
	
> 61.1.0.0/20  2002-05-29 03:29:22  193.0.0.56	  3333 9057 3549 4755
9829
	
> 61.1.0.0/16  2002-05-29 03:29:24  202.12.28.190	  4777 2497 3549
4755 9829
	
> 61.1.0.0/20  2002-05-29 03:29:24  202.12.28.190	  4777 2497 3549
4755 9829
	
> 61.1.0.0/20  2002-05-29 03:29:42  212.47.190.1	  9177 6730 5400
3549 4755
9829 	
> 61.1.0.0/16  2002-05-29 03:29:42  212.47.190.1	  9177 6730 5400
3549 4755
9829 	
> 61.0.0.0/8   2002-05-29 08:43:29  202.12.28.190	  4777 2516 6461
7336 

> 61.0.0.0/8   2002-05-29 08:44:00  193.0.0.56	  3333 12859 6461 7336 	
> 61.1.0.0/16  2002-05-29 09:35:20  129.250.0.232	  2914 3549 4755
9829 

> 61.1.0.0/19  2002-05-29 09:35:20  129.250.0.232	  2914 3549 4755
9829 

> 61.1.0.0/20  2002-05-29 09:35:20  129.250.0.232	  2914 3549 4755
9829 


At the same time, looking at the raw data, we observed that a new
LOC-RIB dump was inserted 
into the database (at May 29 10:45). This seems to show that the
timestamp reported at the beginning of the result is not "the last dump
of May 29 inserted into the database before performing the query".

The presence, in the LOC-RIB, of entries until 09:35:20  seems to
confirm that they refer to the dump executed at 10:45.

Also, the fact that the timestamp reported at the beginning of the
result remained the same, seems to say that the LOC-RIB was unchanged.
If it is true, why we had so many new entries in it?

Further, we had, in the LOC-RIB, entries concerning timestamps after
5:00 (five entries from 08:43:29 to 
09:35:20). This seems to be inconsistent with the time interval
specified in the query (0:00 - 5:00).

We repeated exactly the same query, the same day (May 29), at 21:45. We
had "essentially" the same result (including the first line). However,
there were some repeated entries, some new entries, and some entries
were "swapped" in their position with respect to the previous answer.

Again, looking at the raw data in the database we have found a new dump
at 18:45.

At this point we are pretty much confused about the semantics of the
timings reported into the results of the queries. Is there some document
that clearly reports about it?

                                        Ilaria De Marinis
                                        Federico Mariani

-----Original Message-----
From: Matthew Williams [
	    
	    
] 
Sent: 28 May 2002 20:00
To: 'marians@localhost
Cc: 'gdb@localhost 'ila.dema@localhost 'ris@localhost
Subject: RE: RCC data


Mr Marini,

Thanks for your mail. 
We can only improve our services if we get feedback from the community.

Answers to your questions:
==========================
Example:
----
Prefix 205.136.164.0/22 
From   20020521 23:00:00      
To     20020522 16:30:16   
RRC Box  RRC01, LINX 
Type All 
----

Comment:
This prefix query will retrieve all entries in the RIB table for prefix
205.136.164.0/22 on the 21st of May and all updates observed by the RIS,
starting from 20020521, 23:00:00 until 20020522, 16:30:16. If this is
known then the output should be easier to interpret. Please remember
that all timestamps are UTC.

----

RIS DB Query result : rrc01

Routes from Loc-RIB dump at 2002-05-21 23:29:00

Prefix				Last update time 	Peer
AS Path
205.136.0.0/16          	2002-05-16 15:04:28	195.66.224.54
286 3561 	
205.136.0.0/16          	2002-05-16 15:04:28	195.66.224.54
286 3561 	
205.136.0.0/16          	2002-05-16 15:04:28	195.66.224.54
286 3561 	
205.136.164.0/22        	2002-05-21 08:59:48	195.66.224.54
286 3561 9658 	
205.136.164.0/22        	2002-05-21 18:56:09	195.66.224.54
286 209 3561 9658 	

No updates found for 20020521.

No updates found for 20020522.

----

The time mentioned in the statement "Routes from Loc-RIB dump at
2002-05-21 23:29:00" is slightly misleading, because it corresponds to
when the last RIB dump was inserted into the RIS database. Multiple
entries in the query output is a known issue, which we are currently
trying to resolve by adding a column to the RIB table with timestamps of
the dumps. This will help us distinguish between multiple entries for
the same prefix. 

I hope that you find this information helpful. Please let us know if you
detect other RIS irregularities and keep us updated on the FLAP VIEWER
project.

Best regards,
Matthew Williams

---
> Matthew Williams-Bywater (MW243-RIPE)
> Customer Liaison Engineer
> RIPE NCC (www.ripe.net)


-----Original Message-----
From: marians@localhost [
	    
	    
] 
Sent: 28 May 2002 18:19
To: ris@localhost
Cc: gdb@localhost ila.dema@localhost
Subject: RCC data


Hi, 

we are Federico Mariani and Ilaria De Marinis students of the Computer
Networks group of the "Third University of Rome", and we are working on
the FLAPVIEWER project (see
http://www.dia.uniroma3.it/~lombardo/flapviewer/), that perhaps some of
you at RIS already knows.

Currently, we are analyzing the Ris db, using the standard user
interface. We had some trouble analyzing the retrieved data: some
queries have given (maybe) erroneus results. Here is the list of the
problems that we have encountered so far.

1. In the LOC RIB data there are some announcements that are, in our
opinion,  "out of time". Namely, given a loc rib done at a certain time,
we saw , within it, announcements with a timestamp value corresponding
to a time successive with respect to the time of the loc rib (see, e.g.,
the eclosed 32.0.0.08.txt file).

2.  Still in the LOC RIB , sometimes the same route, with the same
timestamp, and with the same peerer, appears several times (see, e.g.,
the route 32.0.0.0/8, timestamp 2002-04-28 01:36:32, from peerer
193.0.0.56, and with as-path 3333 2686 of the enclosed 32.0.0.08.txt
file).

3. Again in the LOC RIB. We submitted three queries to the same route
collector (RRC03) about the same prefix (205.136.164.0/22), concerning
the same day (may 19), with the same starting time (00:00:00), but with
different ending times. The first ending time was 23:00:00, the second
was 15:00:00, and the third was 07:00:00. All the three answers
contained the same LOC-RIB dump, dated May 19 and with timestamp
23:00:00. 
Since the system guarantees three dumps per day (presumably one for each
8-hours interval) we were expecting to have at least two different
timestamps in the dumps (see the enclosed files: from00to07.txt,
from00to15.txt , from00to23.txt).

Thanks in advance, best regards,

 
Federico Mariani
 
Ilaria de Marinis

Attachment: from00to07.txt
Description: Binary data

Attachment: from00to15.txt
Description: Binary data

Attachment: from00to23.txt
Description: Binary data

Attachment: 32.0.0.08.txt
Description: Binary data