Subject: Re: signing rpls, etc....

From: Curtis Villamizar <[email-masked]>
Date: Sat, 05 Sep 1998 00:07:37 -0400

Mike,

You have yet to make any sort of technical point whatsoever, though
you did manage to throw around a few indirect insults.

Could it be the problem that you are looking at the task of
reinventing the wheel rather than taking some of the work that has
already been done and that is making the problem look daunting?

Curtis

------- Forwarded Messages

To: [email-masked] (Mike O'Dell)
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: signing rpls, etc.... 
Date: Fri, 04 Sep 1998 20:11:59 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Mike O'Dell writes:
> 
> come on people, do we have to endure people
> reinventing all the flat tires over again?
> 
> just stop with this silliness.
> 
> 	-mo

MO,

I think you need to elaborate further.

What exactly are you objecting to?  I hope the answer isn't
"everything".

Curtis

btw- Its RPSL.

------- Message 2

To: [email-masked]
cc: [email-masked] (Mike O'Dell), [email-masked]
Subject: Re: signing rpls, etc.... 
Date: Fri, 04 Sep 1998 21:05:18 -0400
From: "Mike O'Dell" <[email-masked]>

i'm objecting to the monstrosity this has become.

	-mo

------- Message 3

To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: signing rpls, etc.... 
Date: Fri, 04 Sep 1998 21:14:08 -0400
From: "Mike O'Dell" <[email-masked]>

let me elaborate further

what started out as a reasonably simple notation design project
has turned into a secure, distributed database design project,
and a pretty hard one at that.  

the naivete apparent in the resulting design is simply staggering

one can always take issue with RPSL itself because it
cannot make up its mind as to what problem it tries to
solve and hence does several things, none of them very
well. this might be because the requirements are not
clearly understood.

	-mo

------- End of Forwarded Messages

---

From: Randy Bush <[email-masked]>
Date: Fri, 4 Sep 1998 23:02:12 -0700 (PDT)

> you did manage to throw around a few indirect insults.

Curtis,

MO indirect?  :-)

With all due respect, it is not a matter of small technical points.  It is
a monster that got far out of hand, the Ada++ of routing policy and router
configuration registries.  And the distributed database view consistency
and integrity is, shall we say, a novel approach in a field where novel
approaches are rare.

I will again ask a question I asked twice, before bowing out of the WG.  

-----------

What is the *minimum* language and database that will allow an ISP to
publish that part of their routing policy that other ISPs really must see?

-----------

Note that, as N Wirth once said "I did not omit things because I ran out of
ink."  I very intentionally am not asking what information I need to know
about my own universe in order to generate router configurations, and all
those other interesting things.

We are IRR fans.  But the sole data we currently use from the IRR are the
routes an AS originates.

randy

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 05 Sep 1998 10:05:07 -0400

> and integrity is, shall we say, a novel approach in a field where novel

I agree with the 2nd point (distributed) somehow, distributed & replicated
database systems are hairy and they are not as simple as Curtis's presentation
suggested but it's a start. I don't agree with the first. RPSL is not that
hard to implement (having done so) and its structure is clean, far cleaner
than anything else used today to puzzle policies together. It's only complex
in the same sense Postscript is complex compared to ASCII and SQL compared to
ISAM.

> I will again ask a question I asked twice, before bowing out of the WG.

And Einstein said "For every problem there is a simple solution that is wrong"
;-) Let's stay technical ...

> We are IRR fans.  But the sole data we currently use from the IRR are the

putting only all prefixes of your AS into registry all the time for other
people to see is equivalent to running a centralized BGP (I oversimplify here
on purpose) ;-)  whereas RPSL gives you the possibility to figure out what's
going on in term of policies and flows of prefixes in the network on a more
abstract layer and I think it is a necessary step in the same sense Postscript
was a necessary step.  It just takes you further down the road although it
comes at a price.

Just my 2 cents and I hope not to start a flame-war here ...

        thank you

        --- tony

---

From: Mark Prior <[email-masked]>
Date: Sat, 05 Sep 1998 23:33:36 +0930

I'm possibly going to regret this but I'm running away on holiday
for two weeks so ...

I don't see how this statement relates to your later statement that
you only use the route data from the IRR. It sounds very much like you
announce all routes to a customer and only accept routes originated by
them (ie it's a very simple policy).

RPSL as it stands is a pretty good fit for me in describing the
interaction between Connect and it's BGP customers, peers and
providers. Maybe we just do weird stuff but our customers seem to want
us to be flexible :-) I find RPSL a pretty good fit for what we want
to do (controlling the horizon of the announcement of a route, sending
different amounts of routes to customers, etc) because we can use
RtConfig to generate working configurations from our policy (using all
those route objects, as-sets and route-sets). While it has got
considerably more complex than RIPE 181, RIPE 181 couldn't completely
describe our interactions resulting in sub optimal configurations and
postprocessing of the generated configurations. Even our currently
registered policy is a compromise but that's due to Cengiz's coding
speed rather than shortcomings in RPSL. With the release of RAToolSet
4.2.0 we can finally use our complete policy and the fiddles to the
generated configurations are solely to support internal requirements
(and people don't need to know how/why we do them :-)

When I get back I will be loading the new policy up into my registry
and hopefully the Merit RPSL registry (assuming it's accepting
updates) but I have included it for the curious.

Mark.

aut-num:     AS2764
as-name:     ASN-CONNECT-NET
descr:       connect.com.au pty ltd
import: {
	from AS-ANY
		accept ANY AND NOT { 0.0.0.0/0 };
	} refine {
	from AS-ANY
		action community = {{2764,65408}}; pref=0;
		accept community.contains({2764,65280},{2764,65281},{2764,65282},{2764,65283},{2764,65284},{2764,65285},{2764,65286},{2764,65288},{2764,65289},{2764,65290},{2764,65292},{2764,65408},{2764,65409},{2764,65410},{2764,65411},{2764,65412});
	from AS-ANY
		action community.append({2764,65408}); pref=25;
		accept community.contains({2764,3}) AND NOT AS2764:RS-PROVIDER^-;
	from AS-ANY
		action community.append({2764,65408}); pref=15;
		accept community.contains({2764,4}) AND NOT AS2764:RS-PROVIDER^-;
	from AS-ANY
		action community.append({2764,65408}); pref=5;
		accept community.contains({2764,5});
	from AS-ANY
		action community.append({2764,65408}); pref=0;
		accept ANY;
	} refine {
	from AS2764:AS-GLOBAL
		accept PeerAS AND <^PeerAS+$>;
	from AS2764:AS-DOMESTIC
		action community.append({2764,1});
		accept PeerAS AND <^PeerAS+$>;
	from AS4805
		accept ( AS201 OR AS4634 OR AS4736 OR AS4744 OR AS7567 OR AS7617 ) AND <^AS4805+ [AS201 AS4634 AS4736 AS4744 AS7567 AS7617]+$>;
	from AS7543
		accept ( AS9387 ) AND <^AS7543+ [AS9387]+$>;
	from AS7543
		action community.append({2764,1});
		accept ( AS7584 OR AS7594 ) AND <^AS7543+ [AS7584 AS7594]+$>;
	from AS7586
		accept ( AS7585 OR AS7603 OR AS7604 OR AS7605 OR AS7607 OR AS7609 OR AS7635 OR AS7647 OR AS7704 OR AS7719 OR AS7721 ) AND <^AS7586+ [AS7585 AS7603 AS7604 AS7605 AS7607 AS7609 AS7635 AS7647 AS7704 AS7719 AS7721]+$>;
	from AS7586
		action community.append({2764,1});
		accept ( AS7584 ) AND <^AS7586+ [AS7584]+$>;
	from AS7637
		accept ( AS7175 OR AS7543 OR AS7598 OR AS9314 ) AND <^AS7637+ [AS7175 AS7543 AS7598 AS9314]+$>;
	}
import: {
	from AS-ANY
		accept ANY AND NOT AS2764 AND NOT { 0.0.0.0/0 };
	} refine {
	from AS1221 139.130.49.177 at 203.63.80.17
		action pref=20;
		accept NOT ANY;
	from AS1221 139.130.49.81 at 203.63.80.17
		action pref=20; community={{2764,65412}};
	from AS1221 139.130.32.5 at 203.63.80.19
		action pref=20; community={{2764,65412}};
	from AS1221 203.14.14.5 at 203.63.80.30
		action pref=20; community={{2764,65412}};
		accept ANY AND <^AS1221+ AS1221:AS-PEER-US>;
	from AS1221 139.130.49.81 at 203.63.80.17
		action pref=20; community={{2764,65411}};
	from AS1221 139.130.32.5 at 203.63.80.19
		action pref=20; community={{2764,65411}};
	from AS1221 203.14.14.5 at 203.63.80.30
		action pref=20; community={{2764,65411}};
		accept ANY AND <^AS1221+ AS1221:AS-PEER>;
	from AS1221 139.130.49.81 at 203.63.80.17
		action pref=20; community={{2764,65410}};
	from AS1221 139.130.32.5 at 203.63.80.19
		action pref=20; community={{2764,65410}};
	from AS1221 203.14.14.5 at 203.63.80.30
		action pref=20; community={{2764,65410}};
		accept ANY;
	from AS4433
		action pref=10; community={{2764,65409}};
		accept ANY AND <^AS4433+ [AS-AONE AS4637 AS4740]*$>;
	from AS6992
		action pref=10; community={{2764,65409}};
		accept ANY AND <^AS6992+$>;
	}
import:      protocol STATIC into BGP4 {
	from AS2764
		action community.append({2764,65408});
		accept AS2764;
	} refine {
	from AS-ANY
		action community.append({2764,1});
		accept AS2764:RS-DOMESTIC;
	from AS-ANY
		action community.append({2764,8});
		accept AS2764:RS-SATELLITE;
	from AS-ANY
		accept ANY;
	}
export:      to AS2764:AS-CUSTOMERS
	action community={internet};
	announce community.contains({2764,65408}) AND NOT { 0.0.0.0/0 }
export:      to AS3409
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS4739
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS4802
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS4805
	action community={internet};
	announce community.contains({2764,65409},{2764,65410})
export:      to AS4807
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS4854
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7469
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7477
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7486
	action community={internet};
	announce community.contains({2764,65409},{2764,65410},{2764,65411})
export:      to AS7489
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7492
	action community={internet};
	announce community.contains({2764,65409},{2764,65410})
export:      to AS7496
	action community={internet};
	announce community.contains({2764,65409},{2764,65410})
export:      to AS7498
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7543
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7556
	action community={internet};
	announce community.contains({2764,65409},{2764,65410},{2764,65411})
export:      to AS7566
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7569
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7580
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7586
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7592
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7602
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7611
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7631
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7637
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7647
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7648
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7652
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7701
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7702
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS7716
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS9296
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS9297
	action community={internet};
	announce community.contains({2764,65409},{2764,65410})
export:      to AS9298
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS9300
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS9313
	action community={internet};
	announce community.contains({2764,65409},{2764,65410})
export:      to AS9314
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS9324
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS9330
	action community={internet};
	announce community.contains({2764,65409})
export:      to AS1221
	action med=igp_cost; community={no_export};
	announce { 203.40.0.0/13^-, 203.48.0.0/14^-, 203.52.0.0/15^-, 203.54.0.0/16^- } AND community.contains({2764,65408})
export:      to AS4433
	action med=igp_cost; community={no_export};
	announce { 203.102.0.0/15^- } AND community.contains({2764,65408})
export: {
	to AS-ANY
		announce ANY AND NOT { 203.40.0.0/13^-, 203.48.0.0/14^-, 203.52.0.0/15^-, 203.54.0.0/16^-, 203.102.0.0/15^- };
	} refine {
	to AS1221 139.130.49.177 at 203.63.80.17
		action med=igp_cost;
		announce community.contains({2764,65408}) AND community.contains({2764,8});
	to AS1221 139.130.49.81 at 203.63.80.17
		action med=igp_cost; community={no_export};
	to AS1221 139.130.32.5 at 203.63.80.19
		action med=igp_cost; community={no_export};
	to AS1221 203.14.14.5 at 203.63.80.30
		action med=igp_cost; community={no_export};
		announce community.contains({2764,65408}) AND community.contains({2764,6}) AND NOT community.contains({2764,1},{2764,7});
	to AS1221 139.130.49.81 at 203.63.80.17
		action med=igp_cost;
	to AS1221 139.130.32.5 at 203.63.80.19
		action med=igp_cost;
	to AS1221 203.14.14.5 at 203.63.80.30
		action med=igp_cost;
		announce community.contains({2764,65408}) AND NOT community.contains({2764,1},{2764,7});
	to AS1221
		action med=igp_cost; community={no_export};
		announce <^AS2764*$> AND AS2764:RS-PROVIDER^-;
	to AS4433
		action med=igp_cost; community={no_export};
		announce community.contains({2764,65408}) AND community.contains({2764,6}) AND NOT community.contains({2764,7});
	to AS4433
		action med=igp_cost;
		announce community.contains({2764,65408}) AND NOT community.contains({2764,7});
	to AS4433
		action med=igp_cost; community={no_export};
		announce <^AS2764*$> AND AS2764:RS-PROVIDER^-;
	to AS6992
		announce community.contains({2764,65408}) AND NOT community.contains({2764,7});
	}
admin-c:     CC89
tech-c:      MP151
remarks:     Community support definitions
remarks:     
remarks:     Community  Definition
remarks:     ----------------------------------------------------------------
remarks:     2764:1	Announce to "domestic" rate ASes only
remarks:     2764:2	Don't announce outside local POP
remarks:     2764:3	Lower local preference by 25
remarks:     2764:4	Lower local preference by 15
remarks:     2764:5	Lower local preference by 5
remarks:     2764:6	Announce to non customers with "no-export"
remarks:     2764:7	Only announce route to customers
remarks:     2764:8	Announce route over satellite link
notify:      [email-masked]
mnt-by:      CONNECT-AU
changed:     [email-masked] 19980903
source:      CCAIR

as-set:      AS2764:AS-DOMESTIC
descr:       connect.com.au AS set
members:     AS4860, AS7469, AS7543, AS7569, AS7592, AS7611, AS7648, AS9262, AS9278, AS9298
tech-c:      MP151
admin-c:     CC89
remarks:     Customers with domestic connectivity only
mnt-by:      CONNECT-AU
changed:     [email-masked] 19980903
source:      CCAIR

as-set:      AS2764:AS-DOMESTICTRANSIT
descr:       connect.com.au AS set
members:     AS7584, AS7594
tech-c:      MP151
admin-c:     CC89
remarks:     ASes transiting from customers but with domestic connectivity only
mnt-by:      CONNECT-AU
changed:     [email-masked] 19980903
source:      CCAIR

as-set:      AS2764:AS-GLOBAL
descr:       connect.com.au AS set
members:     AS3409, AS4739, AS4797, AS4802, AS4805, AS4807, AS4854, AS7477, AS7486, AS7489, AS7492, AS7496, AS7498, AS7556, AS7566, AS7579, AS7580, AS7586, AS7600, AS7602, AS7612, AS7631, AS7637, AS7647, AS7652, AS7701, AS7702, AS7703, AS7704, AS7716, AS9280, AS9282, AS9284, AS9296, AS9297, AS9300, AS9313, AS9314, AS9324, AS9330
tech-c:      MP151
admin-c:     CC89
remarks:     Customers with global connectivity
mnt-by:      CONNECT-AU
changed:     [email-masked] 19980903
source:      CCAIR

as-set:      AS2764:AS-GLOBALTRANSIT
descr:       connect.com.au AS set
members:     AS201, AS4634, AS4736, AS4744, AS7175, AS7567, AS7585, AS7598, AS7603, AS7604, AS7605, AS7607, AS7609, AS7617, AS7635, AS7719, AS7721, AS9387
tech-c:      MP151
admin-c:     CC89
remarks:     ASes transiting from customers with global reach
mnt-by:      CONNECT-AU
changed:     [email-masked] 19980903
source:      CCAIR

---

From: Randy Bush <[email-masked]>
Date: Sat, 5 Sep 1998 07:29:55 -0700 (PDT)

Mark,

Thanks for making my point so excellently.  It appears to me that all that
other stuff in your RPSL example is how you wish to configure your routers,
and is not PUBLICATION of your policy that tells me how to configure mine.

One way to think of it is, if your internal routing policies could be used
against you in competitive situations (and I am not suggesting they are),
you would not publish that stuff, no way.  It is internal to your network.

We do all the same stuff and even more (complex business model).  But we see
that as our INTERNAL policy, not something that we publish.  Hence it should
not be in public databases and hence not in this particular formal language.

Leave it for the Router Configuration Language WG.

What, beyond routes, do I really need you to know about my network?  So far,
all I have been able to think of could be solved by a general agreement on
RFC 1998bis as BCP.

randy

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 05 Sep 1998 18:20:49 -0400

Randy Bush wrote:

> > Observe that e.g. set of prefixes you advertise in IRR could be used
> > against you competitively as well & therefore one can make the argument
> > that nothing should be put into IRR.
>
> indeed.  but for my own net's safety, and the safety of the net as a whole,
> i need to know what prefixes to expect/allow from you.  and this need is
> sufficiently strong to justify the risk of publishing my prefixes in
> exchange.
>
> hence i asked what is the mimimal data and hence language we need.  what
> has happened instead is the addition of just about every need and feature
> anybody could want.  the results of this process on language design has
> been known for decades, e.g. see tony hoare's turing award lecture in about
> '72, "the emperor's new clothes."

I definitely won't try to beat you on quote's anymore, Randy ;-)

> > is there such a thing ?  I presented in Chicago RPCL which is RPSL for
> > policy configuration in routers. I only got mild interest, maybe because
> > it was the last topic on the agenda and other presenters mercilessly blew
> > the schedule ;-)
>
> i suspect this is because the rps wg does not differentiate between router
> configuration and routing policy publication.

this is a correct observation. My (or our) conclusion was that there may be a
need for router configuration work in IETF  but since the interest was not
overwhelming so far to justify e.g. a BOF, I presented the things in RPS ...

    thank you

        --- tony

---

From: "Mike O'Dell" <[email-masked]>
Date: Sat, 05 Sep 1998 22:17:57 -0400

no, curtis, that is not the problem.

the problem is that RPS is building the ultimate weapon
for fighting the last war and it has a textbook case
of the second-system effect.

	-mo

---

From: "Mike O'Dell" <[email-masked]>
Date: Sat, 05 Sep 1998 22:24:05 -0400

you keep talking about "the IRR" as if there can be just one

why do you believe this fantasy??

	-mo

---

From: Randy Bush <[email-masked]>
Date: Sat, 5 Sep 1998 20:29:12 -0700 (PDT)

Hey Cengiz,

> RPSL allows even ISP's whose policy is solely based on prefix length to
> specify it. Yet how many times we saw the question on nanog is it 18 or 19
> that a particular ISP does not accepts longer prefixes for.

and how will knowing that foonet filters on /42 help me configure my router
in a way i REALLY care about?

> It is a ISP coordination issue, nevertheless...

indeed it is.  at the noc level and nanog level.  now if rpsl could really
replace the nanog list, you might get my support for all the cruft. :-)

> Should the IRR be distributed with authorization and consistency checking?

yes.  but only as a backup to view consistency assurance by design.  you
know, all that ugly real distributed database stuff, like two phase commit
and other techniques for real distributed databases on which we can bet our
networks.

randy

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Sat, 5 Sep 1998 20:59:26 -0700 (PDT)

Mike,

IRR is a name, hence my english teacher would insist that I use
"the". That is all there is to it.

Whether I believe if there can not be more than one, I did not
say. But for a hint, check out -s, -f and -h options of RAToolSet.

> why do you believe this fantasy??

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
http://www.isi.edu/~cengiz    University of Southern California

---

From: "Mike O'Dell" <[email-masked]>
Date: Sun, 06 Sep 1998 09:21:44 -0400

my english teacher would insist on using the plural in this case,
and "the" is not plural

	-mo

---

From: Randy Bush <[email-masked]>
Date: Mon, 7 Sep 1998 22:07:35 -0700 (PDT)

> Arguments that RPSL is way too incredibly complicated do sound rather
> hollow considering it is already about 98% implemented and in use.

i do not thing the complexity argument was that it was unimplementable,
but that it should not be implemented.  i have helped implement complers
for languages that should not have been implemented.  most died rather
quickly, which was considered a good thing.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 8 Sep 1998 04:24:38 -0700 (PDT)

> As I said earlier, you can ...

Given a design which is the union of all desires, as opposed to the
intersection, "You can" is always the response.  What got lost was
the "Do you REALLY need to?"

randy

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Sep 1998 13:36:00 -0400

> the "Do you REALLY need to?"

Whether you need to register policy depends on whether it is desirable
to base policy and aggregations on observed AS paths and email
advisories as ANS does or whether it is more desireable to be able to
base this on analysis of the registry.  The latter is more desireable,
but without a critical mass of information, it is infeasible.

Whether you need to represent your policy in RPSL is up to you.  

ANS doesn't find RIPE-181 adequate to represent policy.  We represent
our import policy in an internal format that routghly translates into
RIPE-181.  For export RIPE-181 isn't close enough to adequate to even
attempt a translation.  For aggregation we've had to make up some IRR
community names with special meaning to our own config software.  RPSL
is more powerful than the internal syntax we use so for us conversion
to RPSL actually satisfies some outstanding requests for increased
flexibility in our config software.  RPSL is also provides sufficient
capabilities to allow us to remove our internal hacks for export and
aggregation.

ANS happens to also publish our import routing policy in all its gory
details.  With RIPE-181 the translation from our internal format sort
of reads like machine code after we are done.  Simple expressions have
to be expanded out multiple times yielding a great deal of repitition
(and a very long aut-num).  RPSL should also very significantly reduce
the external representation of ANS policy.

So there are two questions:

  1.  Do you need to publish your policy in RPSL?

  2.  Is there sufficient motivation to use RPSL to represent your
      policy and aggregation for the configuration of your routers
      regardless as to whether you publish it or not?

This leads to another question:

  3.  Even if you choose not to publish you policy, and you decide
      that some other representation of policy is more suitable to
      your needs, if others find RPSL policy capabilities useful and
      find the exchange of RPSL policy information useful, should you
      interfere the progress of RPSL policy and aggregation
      capabilities just because you chose not to use them?

Regardless of the answers to the first two questions, the answer to
the third is clearly "no".

Curtis

---

From: Daniel Karrenberg <[email-masked]>
Date: Tue, 08 Sep 1998 22:13:37 +0200

> Randy Bush <[email-masked]> writes:

Dear all, 

especially mo (past area director).  My intention (and role) as co-cair
of rps always was to ask the latter question at every juncture. 
Unfortunately my day-job exploded at the time when this began to really
matter.  At first had no time to give rps serious enough attention and
then I had to quit altogether.  With hindsight I now believe I should
have quite my day job and stayed on rps.  Without hindsight I did not. 

Looking at the current state I think the question needs to be asked more
seriously than ever and those asking it should be heared and not be
shouted down by the "experts" in a gut reaction. "What does the typical
user really need?" and "What can we reasonably teach typical users?" are
*extremely* pertinent questions to any engineering effort seeking
widespread *deployment*.

Daniel

---

From: Geoff Huston <[email-masked]>
Date: Wed, 09 Sep 1998 16:14:54 +1000

Once again there is this difference between oeprational imperatives
and IETF Standards.

Asking the AD's is, imho, asking the wrong question to the wrong folk.

Geoff

At 10:59 PM 9/8/98 -0700, Randy Bush wrote:
>> Now, from experience, very few ISPs register routing policy anywhere
>> because:
>> - there is no incentive to - the Internet works anyhow
>> - too complicated - Internet works anyhow
>> - lack of training
>> - which RR of the IRR today?
>> - it's only information
>
>You omitted
>- some folk view anything other than what routes they originate as
>  confidential data
>
>> So please can we separate the two issues.  We carry on with RPSL here for
>> the folks who want it, but separately discuss the route origin problem.
>
>Aha!  That's it!  I accidentally wandered into the wrong WG, or maybe the
>IRTF.  My apologies to everyone for blundering into the china.
>
>Dear AD(s), where does a poor BFSS ISP engineer who is just trying to keep
>their little bit of this silly net running somewhat reliably supposed to go
>to discuss such mundane things?  I have this little I-D, ...
>
>randy
>

---

From: Bill Manning <[email-masked]>
Date: Tue, 8 Sep 1998 23:41:43 -0700 (PDT)

> the route origin problem. It only needs a *simple*, secure, distributed 
> method for the IANA, the address registries, and their delegatees, to 
> document who owns an AS, and who should announce which networks from that 
> AS. 
> 
> Philip Smith                         ph: +61 7 3238 8202 

I've done the AS mapping into the DNS and am more than willing, nay
encouraging ISPs to take the AS zone inhouse. Once there, they can
code (from their own sources) which prefixes they are willing to announce.
As a publication method, this is just fine. It does not answer "who should"
but only who is willing.  This is only half the equation.  Within the
prefix delegation, there should be some marker to indicate the prefered
ASN for announcement, if any.  Both of these steps must be done by the
ISPs as no-one else will be able to do it for them.

Once DNS is secure, you have the chain of custody that you want in a
publication method that insists on ISPs keeping their own data updated.  

I am still leary of the nlri draft since it places, to my mind, a circular
dependency on the DNS and that is not yet a problem where there is agreement
on a solution.

--bill

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Sep 1998 13:37:40 -0400

> ISPs as no-one else will be able to do it for them.

Bill,

This allows anyone with a valid AS number to announce any prefix they
please.  This is less than what RPS is striving for and there are
people interested in deploying what RPS is working on.  It is worth
bringing this to the attention of the RPS WG.  If you want to pursue
this further, please redirect this to another WG or create one *if*
there is sufficient interest.

Curtis

---

From: [email-masked]
Date: Wed, 9 Sep 1998 10:41:52 -0700 (PDT)

> there is sufficient interest.

Er, not really.  It allows anyone to announce thier intent. And, as
has been shown historically (check the MERIT daily stats) that AS 
operators do, in fact, announce all kinds of prefixes that they should
not. What is not always clear is why they should not.

Its not clear that there is a need for a WG, since there is little in the
way of new protocol here. Its more an operational thing, since its
just a publication method.  The method is different in many respects
to the existing RIPE-181 model, but it can (and in some cases does)
use RPSL syntax.

--bill

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Wed, 9 Sep 1998 15:26:58 -0400

>to the existing RIPE-181 model, but it can (and in some cases does)

Should there be a session on this at the October NANOG?

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Sep 1998 16:06:33 -0400

> not. What is not always clear is why they should not.

Gee Bill.  If you had any idea what this WG was doing you'd know that
this is the reason for the existance of the rps-auth draft.  Now that
you've pointed out the need for it, would you care to comment on the
content of that draft?  It would be useful to know whether you feel it
will be effective at stopping AS operators from "announcing all kinds
of prefixes that they should not" which you have at least implied is
something we should be striving for.

> to the existing RIPE-181 model, but it can (and in some cases does)

There are some people that see a need for this WG.  If you don't
please unsubscribe to the mailing list.

Thank you,

Curtis

---

From: [email-masked]
Date: Wed, 9 Sep 1998 12:50:11 -0700 (PDT)

Perhaps. Its not all that much different than other methods that
have been discussed and the method has been posted to the NANOG
list. There has been some interest by those holding ASNs and 
I expect that once the bugs are hammered out that more people 
will use it, if there is perceived value.

-- 
--bill

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Sep 1998 00:24:32 -0400

In message <v0300780ab21c86e58d62@[168.143.1.215]>, "Howard C. Berkowitz" write
> Should there be a session on this at the October NANOG?

At the Michigan NANOG about 150-200 people were at the RPSL tutorial
on Sunday afternoon.  Is that what you mean by a session at NANOG?
Cengiz could provide the URL for slides.  (Sorry, I forgot).

The rps-auth/rps-dist stuff was mentioned in a presentation that was
more focused on milestones and progress than protocol.  Slides are at
ftp://engr.ans.net/pub/slides/nanog/jun-1998/rps-nanog-1998-06.ps

If you meant the BGP/DNS stuff, that was presented at NANOG, RPS, and
IDR and there didn't appear to be much support.  If there is support,
then a BOF and an IETF WG should be started for it.  If there is not,
let it die.  So far each time it comes up it has been dismissed.
Vince gave an IOPS perspective.

Curtis

---

From: Mark Prior <[email-masked]>
Date: Mon, 21 Sep 1998 10:35:33 +0930

I did warn you I was on leave for two weeks ...

I do not consider this to be internal policy. This is the policy that
our customers have requested that we use in exchanging routing
information with them and so the RPSL description is a public
confirmation of that request. It does not document how we get traffic
from point A on our network to point B, nor how I might filter routing
inside a POP (that I consider internal).

From our perspective our customers want to know what subset of the
global routing table we are sending them (we bill them for bytes
they receive from us so they don't want to pay for stuff they don't
want) and what we are doing with their routes. This is documented in
the policy. If you aren't a customer (or peer) then maybe the
information is useful in association with something like AOE to
determine why you might see a route that has our AS in the AS path but
that's not the driving force behind the policy.

Mark.