Subject: [Crisp] Question on routing policy databases

From: Ted Hardie <[email-masked]>
Date: Thu, 4 Aug 2005 09:34:45 +0200

Howdy,
	This is just a repeat of the question I asked at the mic:

Is it worth taking up the query protocol side of a routing policy
database mechanism if we're not taking up the provisioning side?
That is, are the existing mechanisms for keeping the data up to date
and useful sufficient for the operational need?  If they aren't, it seems
like building a query mechanism will end up being half a bridge.  It won't
get used because there won't be operationally useful data to query.

Note: I don't mean the "we" to mean CRISP or to imply that IRIS would do
the update bit; it's a query protocol and should stay that.  But the interested
community and/or the IETF might need to do additional work on the other
half of the bridge to make this useful.

				Ted
				(No hats!)

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: William Leibzon <[email-masked]>
Date: Thu, 4 Aug 2005 08:24:29 -0700 (PDT)

y

> database mechanism if we're not taking up the provisioning side?

Can't the same question be asked about AREG? There's after all no
standardized provisioning protocol for ip registries with RIPE and
ARIN both having their own custom system to allow ISPs to update their 
assignment data and add new data (SWIPs) for their customers.

One of the reasons standardization has not have happened is that there
are not enough registries to make it reasonably needed for compatibility
(although those of us creating ip allocation database tools for ISPs
  would prefer standardized version and protocol that works for both
  RIPE and ARIN and possibly for country IR as well).

In practice similar situation exists with RR (routing registries) as
well because even though there are multiple RRs, on the server side all 
the ones I know of use the same software created by RIPE.

Now this maybe opening a can of worms but I think if we want to go into
developing provisioning system for RREG we might as well consider 
developing provisioning system for AREG because they are going to be
very similar and share the same base and likely implemented by the
same software.

> and useful sufficient for the operational need?

They are not sufficient, but this is not due to RPSL software not 
providing the capability. Its more of the policy and setup of how
RRs are used right now. I can't see new protocol seriously changing
this unless we want to change RPSL from ad-hoc run system to centralized
model like this is done with ip allocations. Considering that all
largest RRs are in fact run by RRs (with exception of north american
regional where merit historically done it instead of ARIN) this 
is not impossible but you need to consult network operators if
this would be acceptable.

---
William Leibzon
   mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
   http://www.elan.net/~william/emailsecurity/
Whois & DNS Network Investigation Tools:
   http://www.completewhois.com

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 9 Aug 2005 16:00:54 +0200

Ted,

> get used because there won't be operationally useful data to query.

This logic I can't completely follow: Isn't that data there now and is 
being already queried because someone considers it useful? And isn't that 
people asking for an standardized way to query it?

Best,
Marcos

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Aug 2005 10:11:19 -0400

>half of the bridge to make this useful.

As usual, I propose here to expand the question and not answer it.

There have been comments/rumors that the "failure" of routing 
registries (acting as trusted third parties in providing data to 
authenticate a route advertisement) has been because the registries 
were out of date or too slow to respond to changes in the routing 
realities.

If that is true and if better automation were the important 
ingredient - including a technological advance such as IRIS as a 
means to disseminate ancillary routing data, then working on this is 
beneficial - but only *useful* if the input side also experiences a 
technological advance, **such** as using EPP to input the data from 
the operators into the trusted third party element.

I'm expanding the question to include: has the "problem" with routing 
security been something that will be improved by working on 
this/these protocols?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Aug 2005 10:18:09 -0400

At 8:24 -0700 8/4/05, William Leibzon wrote:
>Content-Type: MULTIPART/signed;
>	BOUNDARY="-1747394880-845632319-1123169069=:1453";
>	protocol="application/x-pkcs7-signature"; micalg=sha1
>
>y

I think there's a distinct difference between address registration 
and routing registration on the input side.  So I don't think the 
question is as germane.

Briefly put, no one needs an address allocation in an instant (like 
within a hour or day).  We can quibble about how well a registrant 
may plan ahead, or how much of a supply of space an RIR/NIR/LIR 
buffers, but realistically, you will know ahead of time.  On the 
other hand, routing problems happen in an instant.

My presumption is that the speed of the provisioning process 
determines how much you need to automate the interface.  Provisioning 
numbers takes more time than names, more time than routes.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Andrew Newton <[email-masked]>
Date: Tue, 9 Aug 2005 10:27:21 -0400

> As usual, I propose here to expand the question and not answer it.

Consistency is very important. :)

> were out of date or too slow to respond to changes in the routing  

I must have missed the part about routing registries being failures.

Perhaps the questions of "do we also need EPP?" should instead be  
"does the input side, as it is today, not work?"

And one more thought.  At the meeting, a slide was shown with a tree  
structure.  I wonder if the intent of the presenter was to simply  
show the "assignment" path of the data and not the routing path of  
how the data was accessed.  In other words, the data may come from  
the server at foo.example, but the data itself shows an assignment  
path from l1.example to l2.example to isp1.example.

I expect that I am using extremely bad terminology here. I'll quit  
rambling now and get some more coffee.

-andy

---

From: Nagahashi Kengo <[email-masked]>
Date: Tue, 9 Aug 2005 15:50:04 +0100

Andy,

On Tue, 9 Aug 2005 10:27:21 -0400
> path from l1.example to l2.example to isp1.example.

Out intention is to provide this tree structure is 
to show the "assignment" path where an ISP assigns 
prefix to customers, not routing path.

cheers.

-kengo

---

From: Andrew Newton <[email-masked]>
Date: Tue, 9 Aug 2005 11:00:49 -0400

> prefix to customers, not routing path.

Kengo,

I just want to make sure we are all on the same page (due to the fact  
that I'm throwing around terminology in rather bad ways):

   When you mean "routing" path, you are talking about how the  
information is retrieved, as in which IRIS server the information  
comes from?  Am I correct?  Therefore I could get the information  
from a server that is not in the "assignment" path of the data.  Am I  
correct?

-andy

---

From: Nagahashi Kengo <[email-masked]>
Date: Tue, 9 Aug 2005 16:24:51 +0100

Andy,

On Tue, 9 Aug 2005 11:00:49 -0400
> that I'm throwing around terminology in rather bad ways):

understand:) 

> from a server that is not in the "assignment" path of the data.  Am I  

yes, correct. it may happen in case.

cheers.

-kengo

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Aug 2005 12:10:35 -0400

>I must have missed the part about routing registries being failures.

This is an indication of what I was referring to:

   http://www.merit.edu/mail.archives/nanog/2005-05/msg00592.html

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 Aug 2005 10:06:54 -0700

>people asking for an standardized way to query it?

Howdy,
	I think this has been answered by others, but just to close
the loop:  I think it would be useful for the WG to confirm that the output
would get used if it cooks up an IRIS flavor for routing policy databases.
Part of that is ensuring that the other ingredients for the service are
available--in particular, is the data that would be retrieved being maintained
in ways that would enable the service?  If not, is the issue technical (so that
taking on additional technical work, like an epp flavor, would solve the problem)?
			regards,
				Ted

---

From: Kuniaki Kondo <[email-masked]>
Date: Tue, 23 Aug 2005 14:45:16 +0900

Hi, All.

>other hand, routing problems happen in an instant.

Yes, routing problems happen in an instant. And when routing problems
happen, operators must solve the problems as soon as possible: 
for example, operators immediately derive route filters from IRRs
and set them on their border routers. If ISP-A does not register
their route information into some IRR, other ISPs ignore the ISP-A's
routes because the route filters derived from IRRs do not contain
the ISP-A's route information: this means ISP-A loses reachability.

Registering routing information to IRR and keeping IRR up-to-date
is quite important, but it does not solve all the problems.

The most important problem is the overall architecture of IRRs.
In some cases, registering a route information to an IRR cannot be
referred from another IRR. I believe this problem MUST be solved,
and CRISP and EPP can help to solve the problem.

Here I describe the reason and real story:

Currently, IRR has NRTM mechanism referring to mutual information.
However, in the NRTM mechanism, IRRs must be configured with FULL MESH
mirroring, and each IRR must have copies of all the other IRRs' data.
I believe that this mechanism does not scale. Furthermore, NRTM does
not support propagating IRR information. That is, IRR must have 
complete full mesh mirroring. Actually, I found some case in Japan
what ISP-A registered AS information to IRR-A. After a while, IRR-A 
deleted ISP-A's AS information. Then, ISP-A lost reachability 
to anywhere. ISP-A try to register ISP-A's information to IRR-B,
but the problem was not solved. Because, one ISP refers to IRR-C
to make route filter, and IRR-C mirror with IRR-A, and IRR-C does
not mirror with IRR-B. This problem can be avoided if IRRs have
hierarchical topology and information transport mechanism between IRRs.

I believe that CRISP is a good solution to solve these problems.

--
kuniaki,
Regards.