AS 690 aut-num progress (LONG!!!)

Hi Curtis,

I went over your mail, well at least the beginning part. I have to say
I am impressed. I think this is a nice way of expressing AS690's
policy. It is a more natural way than db_selects. However, it is not
in the true ripe-181 spirit (which is OK) in that it is still on a per
route/homeas basis. That is as opposed to listing all routes that you
import with preference 1 form 3561 (i.e. 109, 114), you separate them
so that all routes of 109 are listed next to each other. This is
probably the best way considering how prdb is organized.

About the oddball routes. PRDB has 45K routes registered whereas only
21K were actually active when I last checked it in January. I think
these 24K routes which are no longer being announced to the ANSNet
might be contributing to the oddballs. It would be nice to throw them
away, and I think it would make the ANS router configs more efficient,
i.e. smaller network lists.

More comments below.

Curtis Villamizar (curtis at ans.net) on March 13:
> 
> Hi all,
> 
> A first cut of AS 690 inbound policy is done.  I think it is accurate,
> but haven't checked against gated configs, so I can't yet be sure.
> I'd like comments of the method and on some of the syntax extensions
> we will be using internally.  In all cases where the capability exists
> in ripe-181, short cut syntax (like wildcards in interas-in lines)
> will be expanded before sending to a public database.
> 
> I just partially manually rechecked the results and while doing so
> wrote some comments in the current output.  The annotated partial
> aut-num object is below.  Early comments please.
> 
> There is one problem for which there is no way to express the
> requirement in ripe-181.  There is no way to specify an as-in line
> (which is required and has no means restrict to specific peers) and no
> way to specify that certain destinations are not accepted at all at
> some peers using interas-in or as-in lines.  This is need where we
> peer with someone at two interconnects, accept one as primary and
> don't accept the same set of routes from the other peering at all.

I can not say I understand what you mean in the above paragraph. If
you do not want to accept a route, in ripe 181, you do not list it in
your as-in lines. By default it is rejected. There is no explicit way
of saying "reject 128.8/16".

I think like gated, a preference of -1 would be useful.

> 
> The current code currently does not have the ability to make the check
> needed to add the reject, but if we get a syntax, adding the code
> would not be difficult.  One method would be a post processing phase
> which can note that where interas-in lines are used but where some
> peering sessions are not covered by the interas-in lines and will be
> used as last resorts (unintentionally).
> 
> The next step is either outbound policy or partial gated configs to
> check the inet-rtr objects and inbound policy.  Outbound policy looks
> a lot easier than inbound, but I will need the extended syntax that
> supports AS path (at least to specify border AS that we learned the
> route from).  I'm going to use gated syntax and not bother to call the
> field extended-something unless a consensus emerges real quickly.

rtconfig will work if you do not call these attributes
extended-something, but all other tools will give syntax errors. I
reccomend to use extended-something attributes.

> 
> Curtis
> 
> btw-  the complete objects as they now stand are at:
>   http://tweedledee.ans.net:8001/prdb-radb
> 
> These are generated from a PRDB snapshot taken Feb 21.  The idea is to
> build the tool, compare to gated configs of the same vintage, then
> redo the snapshot more recently and compare, then start doing real
> config runs from the ANS-DB and submit our stuff to the RADB.  This
> has to be well coordinated with Merit and others.
> 
> 
> 
> 	This is part of the AS 690 ripe-181 aut-num object, annotated
> 	to show how the lines are derived and why.
> 
> aut-num: AS690
> as-name: ASN-NSFNET-T3-RT
> description: ANSNET (the former NSFNET backbone)
> guardian: as690-guardian at ans.net

I think the guardian attribute is history.

> tech-c: noc at ans.net
> admin-c: config at ans.net
> notify: config-notify at ans.net
> source: ANS


Ripe database reorders attributes. That is all remark lines will
be moved after the (inter)?as-* lines. So the comments will be much
after where they should be. I think we (i.e. rr-impl) should change
this. (Dale is this right?)

Ripe database will also give a syntax error to line continuations with
\. Perhaps we should add this. Currently, to continue, you need to
repeat the last attribute:

remark: homeas policies: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 + 
remark: 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 + 1:3561:5 2:3561:450
remark:  3:200:8 4:200:136 5:1740:450 6:1740:71 + 1:1957

More pain with policy lines, you need to repeat everything upto the
policy expression:

as-in: from AS1 1 accept ANY AND NOT
as-in: from AS1 1 accept AS10

is equivalent to 
as-in: from AS1 1 accept ANY AND NOT \
	AS10

Daniel, is it too hard to support line continuations based on \?

> 
> 	This is all fixed and can easily be changed if the guesses at
> 	reasonable fields are not incorrect.
> 
> 	The remainder of the aut-num object is then the inbound policy
> 	for AS 690.  This is grouped by home AS number.
> 
> remark: homeas policies: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 +  \
>   1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 + 1:3561:5 2:3561:450  \
>   3:200:8 4:200:136 5:1740:450 6:1740:71 + 1:1957
> 
> 	This remark lists the policies for home AS 109.  There are
> 	four policies on this line, separated by plus (+).  Line
> 	continuation uses the backslash.  If that upsets true ripe-181
> 	implementations, then line continuations can be removed and
> 	the very long lines submitted to the RA or other outside database.
> 
> 	The individual policies are then treated in order of the
> 	number of routes which they cover.  I've compressed some white
> 	space out in a few places to avoid some line continuations.
> 
> remark: homeas policy: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 (4/9)
> 
> 	This line indicates that one home AS policy for AS 109 is
> 	being expressed, the policy "1:3561:5 2:3561:450 3:200:8
> 	4:200:136" which covers four of the nine networks for AS 109.
> 	The third value in some tuples is a database index to the ENSS
> 	where the policy entry applies.
> 
> remark: policy item for 109: 1:3561:5
> as-in: from AS3561 1 accept AS109 except { 192.150.49/24 }
> interas-in: from AS3561 DNSS11 * (pref=1) accept AS109 except { 192.150.49/24 }

Way to say "except" in ripe 181 is to say "AND NOT". AND/OR/NOT are
actually set operations intersection/union/complement. except which is
set-minus is equivalent to "AND NOT".

> 
> 	The first item in the policy can be expressed as an AS list
> 	with one exception.  All of the policies contain the tuple
> 	1:3561:5, except one policy, 1:1957, which contains one
> 	network 192.150.49/24.  Any new route objects for AS 109 will
> 	be handled by this policy entry.  An as-in line is needed to
> 	cover the interas-in line.  There is no way in ripe-181 to
> 	state that these nets are accepted at no other AS 3561 peering.

I am not sure if I understand what you mean. But I think it is not
true. That is:

as-in: from AS3561 1 AS1
interas-in: from AS3561 ENSS218 * (pref=1) AS1

ensures that AS1 is not accepted in any other peering but ENSS218 *. 
There is an exception, that is if it is explicitly specified like:

interas-in: from AS3561 ENSS99 * (pref=1) AS1

In which case it is also accepted on ENSS99.

In other words, if you combine all routes that are accepted in
interas-in lines, these routes are not imported on any other interface
than the interfaces specified on the interas-in lines.  Lets call this
set of routes as combined-interas-in-routes.

If you also combine all the routes accepted on as-in lines, and if you
subtract the combined-interas-in-routes from this, the remaining
routes are accepted on all peerings. I call these routes as left-over
routes.

> 
> 	Note that the from expression includes a wildcard.  The
> 	expression "AS3561 DNSS11 *" indicates all AS 3561 peers at
> 	DNSS11.  This is a ripe-181 extension and must also be
> 	expanded based on the inet-rtr object before submitting to a
> 	public database like the RA.
> 
> 	The name DNSS11 must also be changed.  DNSS in the router
> 	names must be changed to CNSS.  Many of the peer routers have
> 	no names at all in the PRDB.  DNS is being used to create a
> 	name translation table to address this but hasn't been
> 	applied.  When it is, DNSS11 will be cnss11.t3.ans.net and the
> 	interas-in line will be a bit longer.
> 
> remark: policy item for 109: 2:3561:450
> interas-in: from AS3561 ENSS218 * (pref=2) accept AS109 except {192.150.49/24}
> remark: policy item for 109: 3:200:8
> as-in: from AS200 3 accept AS109 except { 192.150.49/24 }
> interas-in: from AS200 ENSS128 * (pref=3) accept AS109 except {192.150.49/24}
> remark: policy item for 109: 4:200:136
> interas-in: from AS200 ENSS144 * (pref=4) accept AS109 except {192.150.49/24}
> 
> 	The reamining three backup preferences are expressed using the
> 	same AS expression with an exception of one network, since two
> 	of the policies simply add a fifth and sixth preference.
> 	These also require an as-in and interas-in line and suffer the
> 	same problem of not being able to negate peerings.
> 
> remark: homeaspolicy:109: 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 (3/9)
> 
> 	This is the next policy.  All of the policy expressions have
> 	already been covered except the fifth one.
> 
> remark: policy item for 109: 5:1740:71
> as-in: from AS1740 5 accept { 131.108/16 192.31.7/24 198.93.160/19 }
> interas-in: from AS1740 ENSS135 * (pref=5) accept \
>   { 131.108/16 192.31.7/24 198.93.160/19 }

Minor syntax problems. Ripe 181 requires four-quads, i.e.
131.108.0.0/16 instead of 131.108/16. Also, you are missing commas in
your network lists: { 131.108.0.0/16, 192.31.7.0/24, 198.93.160.0/19 }

> 
> 	The first four expressions are suppressed since they are
> 	already covered by the AS109 specified in the first policy
> 	group.  Only the fifth entry in this policy must be stated.  A
> 	net list is used so new route objects don't inherit this.


> [ ... ]
> 
> 	Are we getting bored yet.  If not look at the complete file
> 	and add your own silly comments.  :-)

:-)

Policy for 701 was fun.

Curtis,

The way you assigned preferences to interas-in lines and costs to
as-in lines is interesting. In that you can impose "override
as-in costs with interas-in preferences" and have the desired
behavior. Without overriding, it is still the correct policy, however
the preferences in the config files will reflect both the as-in
costs and interas-in preferences and be different numbers than that
appear on your policy.

In your aut-num object, I have not seen a policy like:
	1:3561:100 2:200:128 3:3561:111
which is not really expressible in ripe-181. Is this because there
were not such policies or did you approximate those to something else.

I hope my comments are useful. 

I have few more questions. I am asking these as input to RPSL design:
1) would it be easier if interas-in preferences were comparable to
   as-in costs and override as-in costs for the set of routes
   specifies in interas-in lines?
2) would it be easier if you did not need to specify an as-in to cover
   each interas-in line (kind of like an as-in line was there by
   default for each interas-in line)?
3) would it be easier if there was only as-in and no interas-in
   attributes but as-in allowed you to specify optional interface
   addresses. If the interface addresses are present, it would mean
   import criteria on this peering, if not present, it would mean
   import criteria on all other peerings?
4) any other suggestion that would have made your task easier. (I got
   the message that pref=reject is useful).

Thanks.

Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California



-------- Logged at  Fri Mar 17 23:12:29 MET 1995  ---------