rfc1786.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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:




Bates, et al.                                                  [Page 29]

RFC 1786        Representing IP Routing Policies in a RR      March 1995



   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.1/32 193.0.1.2/32 (pref=9) accept AS4
   interas-in:from AS3 193.0.1.5/32 193.0.1.6/32 (pref=7) accept AS4
    ...



   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-out attributes in the policy representation of
   AS3.


   The interas-out attribute is similar to interas-in as as-out is to
   as-in.  The one major difference being that interas-out allows you to
   associate an outgoing metric with each route. It is important 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 link for its traffic as determined by the sending AS.

   If we look at the corresponding interas-out for AS3 we would see the
   following:

   Example:

aut-num: AS3
as-in: from AS2 10 accept AS1 A2
as-out: to AS2 announce AS3 AS4
interas-out:to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=5) announce AS3
interas-out:to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=9) announce AS4
interas-out:to AS2 193.0.1.6/32 193.0.1.5/32 (metric-out=7) announce AS4
 ...






Bates, et al.                                                  [Page 30]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   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 combined local policies then local preferences for these
   routes are assumed to be equal for all links.

   Any route specified in interas-in/out and not specified in as-in/out
   is assumed not accepted/announced between the ASes concerned.
   Diagnostic tools should flag this inconsistency as an error.  It
   should be noted that if an interas-in or interas-out policy is
   specified then it is mandatory to specify the corresponding global
   policy in the as-in or as-out line. Please note there is no relevance
   in the cost associated with as-in and the preferences used in
   interas-in.

   The interaction of interas-in/interas-out with as-in/as-out

   Although formally defined above, the rules associated with policy
   described in terms of interas-in and interas-out with respect to as-
   in and as-out are worthy of clarification for implementation.

   When using interas-in or interas-out policy descriptions, one must
   always make sure the set of policies described between two ASes is
   always equal to or a sub-set of the policy described in the global
   as-in or as-out policy. When a sub-set is described remember the
   remaining routes are implicitly shared across all connections. It is
   an error for the interas policies to describe a superset of the
   global policies, i.e. to announce or accept more routes than the
   global policies.

   When defining complex interas based policies it is advisable to
   ensure that any possible ambiguities are not present by explicitly
   defining your policy with respect to the global as-in and as-out
   policy.

   If we look at a simple example, taking just in-bound announcements to
   simplify things. If we have the following global policy:


   aut-num: AS1
   as-in: from AS2 10 accept AS100 OR {10.0.0.0/8}

   Suppose there are three peerings between AS1 and AS2, known as L1-R1,
   L2-R2 and L3-R3 respectively. The actual policy of these connections
   is to accept AS100 equally on these three links and just route
   10.0.0.0/8 on L3-R3. The simple way to mention this exception is to
   just specify an interas policy for L3-R3:




Bates, et al.                                                  [Page 31]

RFC 1786        Representing IP Routing Policies in a RR      March 1995



   interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}


   The implicit rule that all routes not mentioned in interas policies
   are accepted on all links with equal preference ensures the desired
   result.

   The same policy can be written explicitly as:

   interas-in: from AS2 L1 R1 (pref=100) accept AS100
   interas-in: from AS2 L2 R2 (pref=100) accept AS100
   interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}


   Whilst this may at first sight seem obvious, the problem arises when
   not all connections are mentioned. For example, if we specified only
   an interas-in line for L3-R3 as below:

   aut-num: AS1
   as-in: from AS2 10 accept AS100 OR {10.0.0.0/8}
   interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}


   then the policy for the other links according to the rules above
   would mean they were equal to the global policy minus the sum of the
   local policies (i.e. ((AS100 OR {10.0.0.0/0}) / (AS100 OR
   {10.0.0.0/0})) = empty) which in this case would mean nothing is
   accepted on connections L1-R1 and L2-R2 which is incorrect.

   Another example: If we only registered  the  policy  for  link  L2-
   R2:

   interas-in: from AS2 L2 R2 (pref=100) accept AS100

   The implicit policy for both L1-R1 and L3-R3 would be as follows:

   interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8}
   interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}


   This is derived as the set of global policies minus the set of
   interas-in policies (in this case just accept AS100 as it was the
   L2-R2 interas-in policy we registered) with equal cost for the
   remaining connection. This again is clearly not what was intended.






Bates, et al.                                                  [Page 32]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   We strongly recommend that you always mention all policies for all
   interas connections explicitly, to avoid these possible errors. One
   should always ensure the set of the interas policies is equal to the
   global policy. Clearly if interas policies differ in complex ways it
   is worth considering splitting the AS in question into separate ASes.
   However, this is beyond the direct scope of this document.

   It should also be noted there is no direct relationship between the
   cost used in as-in and the preference used in interas-in.










































Bates, et al.                                                  [Page 33]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   How to describe the exclusion policy of a certain AS - "as-exclude"

   Some ASes have a routing policy based on the exclusion of certain
   routes if for whatever reason a certain AS is used as transit.
   Whilst, this is in general not good practice as it makes implicit
   assumptions on topology with asymmetry a possible outcome if not
   coordinated, this case needs to be accommodated within the routing
   policy representation.

   The way this is achieved is by making use of the "as-exclude"
   attribute. The precise syntax of this attribute can be found in
   Appendix A along with the rest of the defined syntax for the "aut-
   num" object. However, some explanation of the use of this attribute
   is useful. If we have the following example topology.

   Example:


              AS4--------AS3
    |          |          |
    |          |          |
   AS1--------AS2--------AS5


   With a simple corresponding policy like so:


   Example:

   aut-num: AS1
   as-in:  from AS2 100 accept ANY
   as-out: to AS2 announce AS1
   as-exclude: exclude AS4 to ANY
    ....


   We see an interesting policy. What this says in simple terms is AS1
   doesn't want to reach anything if it transits AS4. This can be a
   perfectly valid policy. However, it should be realized that if for
   whatever reason AS2 decides to route to AS3 via AS4 then immediately
   AS1 has no connectivity to AS3 or if AS1 is running default to AS2
   packets from AS1 will still flow via AS4. The important point about
   this is that whilst AS1 can advise its neighbors of its policy it has
   no direct control on how it can enforce this policy to neighbors
   upstream.






Bates, et al.                                                  [Page 34]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   Another interesting scenario to highlight the unexpected result of
   using such an "as-exclude" policy. If we assume in the above example
   AS2 preferred AS4 to reach AS3 and AS1 did not use default routing
   then as stated AS1 would have no connectivity to AS3. Now lets
   suppose that for example the link between AS2 and AS4 went down for
   some reason. Like so:

   Example:



              AS4--------AS3
                          |
                          |
   AS1--------AS2--------AS5


   Suddenly AS1 now has connectivity to AS3. This unexpected behavior
   should be considered when created policies based on the "as-exclude"
   attribute.

   The second problem with this type of policy is the potential of
   asymmetry. In the original example we saw the correct policy from
   AS1's point of view but if ASes with connectivity through AS4 do not
   use a similar policy you have asymmetric traffic and policy.  If an
   AS uses such a policy they must be aware of the consequences of its
   use. Namely that the specified routes which transit the AS (i.e.
   routing announcements with this AS in the AS path information) in
   question will be excluded.  If not coordinated this can easily cause
   asymmetry or even worse loss of connectivity to unknown ASes behind
   (or in front for that matter) the transit AS in question.  With this
   in mind this attribute can only be viewed as a form of advisory to
   other service providers. However, this does not preclude its use with
   policy based tools if the attribute exists.

   By having the ability to specify a route keyword based on any of the
   four notations given in the syntax it allows the receiving AS to
   specify what routes it wishes to exclude through a given transit AS
   to a network granularity.












Bates, et al.                                                  [Page 35]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


7.  AS Macros

   It may be difficult to keep track of each and every new AS that is
   represented in the routing registry.  A convenient way around this is
   to define an `AS Macro' which essentially is a convenient way to
   group ASes. This is done so that each and every AS guardian does not
   have to add a new AS to it's routing policy as described by the as-in
   and as-out attributes of it's AS object.

   However, it should be noted that this creates an implicit trust on
   the guardian of the AS-Macro.

   An AS-Macro can be used in <routing policy expressions> for the "as-
   in" and "as-out" attributes in the aut-num object. The AS-Macro
   object is then used to derive the list or group of ASes.

   A simple example would be something like:


   Example:

   aut-num: AS786
   as-in:   from AS1755 100 accept AS-EBONE AND NOT AS1104
   as-out   to AS1755 announce AS786
    .....


   Where the as-macro object for AS-EBONE is as follows:


   as-macro:  AS-EBONE
   descr:     ASes routed by EBONE
   as-list:   AS2121 AS1104 AS2600 AS2122
   as-list:   AS1103 AS1755 AS2043
   guardian:  [e-mail]
    ......


   So the policy would be evaluated to:


   aut-num: AS786
   as-in:   from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122
   as-in:   from AS1755 100 accept AS1103 OR AS1755 OR
   as-in:   from AS1755 100 accept AS2043) AND NOT AS1104
    ......





Bates, et al.