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

In message <199503172208.AA12294 at cat.isi.edu>, Cengiz Alaettinoglu writes:
> 
> 
> 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.

A longer term goal is to get rid of the exceptions and have a
consistent policy across most if not all AS, aided by MEDs.

> 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.

I though I already did this (me thinks).  I ignore all routes with 
aconfigure or uconfigure set.

> > 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'm not sure I knew what I was saying either.  See exchange with Dale.

> > 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.

OK.

> > 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.

Spec says manditory.  ?

> 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?)

I'll submit in human readable format.  Reordering is optional.  :-)

> 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

Yuk.  I'll just give you megalines and you can do what you want with
them.  I'm already postprocessing before submitting.

> 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

Megalines until resolved!

> > 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".

I noticed this a little late.

> > 	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.

You have to look closely at the way policy is defined.  For each home
AS, there is one policy description (one or more as-in plus interas-in
if needed that are expressed as:

	... accept ASx AND NOT { ..some set of routes.. }

All other policies for the home AS are expressed as:

	... accept { ..some subset of above set.. }

If a new route is added it falls into the policy:

	... accept ASx AND NOT { ..some set of routes.. }

meaning it gets the same primary, secondary, tertiary, etc, plus the
same treatment relative to preferred routers for a given border AS.

> > 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 }

Thanks for pointing this out.  These are easy.  A different separator
on the final join gets the commas and I already have functions that
chop the net number or extend it back to a full quad.

> :-)
> 
> Policy for 701 was fun.

It was amusing.

> 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.

I'm using interas-in to break ties in as-in and putting the result in
gated's preference.  I'm not using cost for gated preference and
preference for gated preference2.  I'll recheck, but I think the
policy is written such that this always works and what gated will do
will match what ripe rules predict should happen.

> 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.

as-in: from AS3561 1 accept ASx
interas-in: from AS3561 r100 * (pref=1) accept ASx
as-in: from AS200 1 accept ASx				<- **note below
interas-in: from AS200 r128 * (pref=2) accept ASx
interas-in: from AS3561 r111 * (pref=3) accept ASx

Note: after the first time an interas-in line is used, the cost
remains fixed and interas-in lines are used to express the remainder
of the policy.  This is the trick that makes gated rules and ripe
rules come up with the same ordering but for different reasons.  Gated
would see the preferences.  If the first entry didn't use interas-in,
but the second did, cost would lock in as 2, and pref would take over
from 2.

> I hope my comments are useful. 

Yes very.  Thanks.

> I have few more questions. I am asking these as input to RPSL design:

What's an RPSL?  Sorry I'm new to this game.

> 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?

Yes, but I'm managing to work around it.  It's OK to keep it as is,
since it reflects the way costs and type 2 externals work in OSPF and
the way local_pref and MED work in BGP.

> 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)?

Yes.  It would be even better if there was type of as-in with optional
near and far end peer and an optional pref.  I'm afraid it's too late
to change this.

> 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?

Yes.

> 4) any other suggestion that would have made your task easier. (I got
>    the message that pref=reject is useful).

Not sure on this anymore.

> Thanks.
> 
> Cengiz

Thanks for the comments.  I'll try to keep you up to date on
significant progress.

Curtis



-------- Logged at  Mon Mar 20 14:31:57 MET 1995  ---------