Summary of small meeting with merit of the last ripe-81++ issues
Jessica Yu
Thu Aug 4 00:28:56 CEST 1994
Tony,
We got our bits here.
Basically, we just used your draft as base and changed relevant parts on top of
that. The text below is relevant part of on page 26,27,50 and 51. The
paragraph which marked with ** are modified. The major changes are the same
as outlined by your message. The <local-info> are broke into two pieces.
Since the order is yet to be decided, what's in the text below is just a
place holder so the sematic meantings of that particular part is not checked.
It will be done as soon as the order is decided. Thanks!
--Jessica
On Page 26:
**Description of routing policies between ASs with multiple connections-
"interas-in/interas-out".
Description of multiple connections between ASs defines how two
ASs have chosen to set different policies for the use of each or
some of the connections between the ASs. This description is necessary
only if the ASs are connected in more than one way and the routing policy
and differs at these two connections.
Example:
LINK1
193.0.1.1 +-------------+ 193.0.1.2
| |
AS1------AS2== ==AS3-----AS4
| |
193.0.1.5 +-------------+ 193.0.1.6
LINK2
** NOTE: LINK here denotes to connection points between ASs. It is not
necessary just a serial link as it may be interpreted. It could be ethernet
or other type of connection as well.
**It may be that AS2 wants to use LINK2 only for traffic towards AS4.
LINK1 is used for traffic to AS3 and as backup to AS4, should LINK2 fail.
To implement this policy, one would use the attribute "interas-in"
and "interas-out." This attribute permits ASs to describe their local
decisions based on its preference such as multi-exit-discriminators (MEDs)
and to communicate those routing decisions. This information would be
useful in resolving problems when some traffic paths changed from traversing
AS3's gateway in Timbuktu rather than the gateway in Mogadishu. The exact
syntax is given in Appendix A. However, if we follow this example
through in terms of AS2 we would represent this policy as follows:
Example:
aut-num: AS2
as-in: from AS3 10 accept AS3 AS4
as-out: to AS3 announce AS1 AS2
**interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref=5) accept AS3
**interas-in: from AS3 193.0.1.2/32 193.0.1.2/32 (pref=15) accept AS4
**interas-in: from AS3 193.0.1.6/32 193.0.1.2/32 (pref=10) accept AS4
...
On page 27:
**Here we see additional policy information between two ASs in terms of the
IP addresses of the connection. The parentheses and keyword are syntactic
placeholders to add the readability of the attributes. If pref=MED is
specified the preference indicated by the remote AS via the multi-exit-
discriminator metric such as BGP is used. Of course this type on
inter-AS policy should always be bilaterally agreed upon to avoid asymmetry
and in practice there may need to be corresponding interas-in attributes
in the policy representation of AS3.
The interas-out attribute is similar to interas-in in the same way
as as-out to as-in. The one major difference being that interas-out
allows the association of an outgoing metric with each route. It is
imporant to note that this metric is just passed to the peer AS and
it is at the peer AS's discretion to use or ignore it. A special value
of IGP specifies that the metric passed to the receiving AS will be
derived from the IGP of the sending AS. In this way the peer AS can
choose the optimal connection for its traffic as determined by the
sending AS.
'Descriptions of interas policies do not replace the global policy
described in as-in, as-out and other policy attributes which should
be specified too. If the global policy mentions more routes than
the local policy then local preferences for these routes are assumed
to be equal for all links. If a route is only referenced in some
interas-in/out attributes and not in others it is assumed not
announced/accepted on the links concerned (see the example above).'
**(Replace the above paragraph with the paragraph below)
** When both as-in,as-out and interas-in,interas-out are used, for
the routes mentioned in both set of attributes, the preference
defined in interas-in and interas-out will take precedence for the particular
interas connection point identified by <local-rid> and <remote-rid>. For
the routes which are not mentioned in interas-in and interas-out, their
preference will be using what defined in as-in. If a route is only
referenced in some interas-in/out attributes and not in others it is
assumed not announced/accepted on the connection concerned.
**The key difference between interas-in/interas-out and as-in/as-in
attributes is the former describes a more specific inter-AS policy
based on multiple connections between ASs and the latter the general
inter-AS policy. The general policy should
always be defined. The more specific inter-AS policy
should only be defined when such a policy really exists and the
implications of setting such policies are fully understood.
On Page 51:
interas-in:
Describes incoming local preferences on an inter AS connection.
Format:
** from <aut-num> [<local-rid>] [<neighbor-rid>] <preference> accept
<routing policy expression>
The keywords from and accept are optional and can be omit-
ted.
<aut-num> is an autonomous system as defined in as-in.
** <local-rid> contains the IP address of the border router
in the AS describing the policy. IP address must be
in prefix length format. This field is optional.
** <neighbor-rid> contains the IP address of neighbor AS's border
router from which this AS accept routes defined in the <routing
policy expression>. IP addresses must be in prefix length
format. Like <local-rid>, this field is optional.
** <preference> is defined as follows:
** (<pref-type>=<value>)
It should be noted the parenthesis ``('' and ``)'' and the
keywords of <pref-type> must be present for this preference
to be valid.
** <pref-type> currently only supports "pref". It could be expanded
to other type of preference such as tos/qos as routing technology
matures.
<value> can take one of the following values:
<cost>
<cost> is a positive integer used to express a rela-
tive cost of routes learned. The lower the cost the
more preferred the route. This <cost> value is only
relevant to other interas-in attributes, not to as-in
attributes.
** MED
This indicates the AS will use the MED metric,
as implemented in BGP, sent from its neighbor AS.
"NOTE: Combinations of MED and <cost> should be
avoided for the same destinations".
CAVEAT: The pref-type values may well be enhanced in
the future as more inter-ASs routing protocols intro-
duce other metrics.
<routing policy expression> is an expression as defined in
as-in above.
Examples:
** interas-in: from AS1104 192.87.45.254/32 192.87.45.80/32 (pref=10) accept AS786 AS987
** interas-in: from AS1104 192.87.45.254/32 192.87.45.79/32 (pref=20) accept AS987
** interas-in: from AS1103 192.87.45.254/32 192.87.45.32/32 (pref=MED) accept ANY
Status: optional, multiple lines allowed
On Page 52:
interas-out:
Format:
** to <aut-num> [<local-rid>] [<neighbor-rid>] announce [<metric>]
<routing policy expression>
The keywords to and announce are optional and can be omit-
ted.
** The definitions of <aut-num>, <local-rid> <neighbor-rid> and
<routing policy expression> are identical to those defined in
interas-in.
<metric> is an optional field and is defined as follows:
** (<metric-type>=<value>)
** It should be noted the parenthesis ``('' and ``)'' and the
The keywords of <metric-type> must be present for this metric to
be valid.
** <metric-type> currently only supports "metric-out". It could be
expanded to other type of preference such as tos/qos as routing
technology matures.
<value> can take one of the following values:
<num-metric>
<num-metric> is a pre-configured metric for outbound
routes. The lower the cost the more preferred the
route. This <num-metric> value is only relevant to
other interas-out attributes, not to as-out attri-
butes.
IGP
This indicates that this means that the metric
reflects the ASs internal topology cost. The topology
is reflected here by using MED which is derived from
the AS's IGP metric.
"NOTE: Combinations of IGP and <num-metric> should be
avoided for the same destinations."
CAVEAT: The metric-out values may well be enhanced in
the future as more interas protocols make use of
metrics.
Examples:
interas-out: to AS1104 192.87.45.254/32 192.87.45.80/32 (metric-out=10
) announce AS23 AS10
** interas-out: to AS1104 192.87.45.80/32 (metric-out=15) announce AS10
** interas-out: to AS1103 192.87.45.254/32 (metric-out=IGP) announce ANY
Status: optional, multiple lines allowed
-------- Logged at Thu Aug 4 03:26:03 MET DST 1994 ---------
[ rr-impl Archive ]