meeting

Joe Abley jabley at nlri.org
Thu Nov 22 18:04:43 UTC 2001


On Thu, Nov 22, 2001 at 04:46:43AM -0800, Randy Bush wrote:
> > Following on from the August WG meeting, I would like to pass
> > draft-huston-nopeer-00.txt to the WG to be adopted as a WG item.
> 
> this initiates a two week wg call on whether this work should become
> draft-ietf-ptomaine-nopeer-... 
> 
> > Does it need consideration in the WG meeting?
> 
> i think the technical details are worth some back and forth.  there are
> subtle alternative semantics, yes?
> 
> so, so far, our agenda would be
>   o agenda bashing
>   o discussion of draft-huston-nopeer-00.txt
>   o administrivia
>     - [how] do we proceed?
>     - any charter changes?
>     - new chair
> 
> more documents needed!

I circulated draft-jabley-edge-policy-propagation-control-01 during
Minneapolis, but there wasn't much discussion, I got distracted, and
it didn't get sent to internet-drafts.

Ben Black and I wrote most of a similar draft, providing the same
propagation control mechanisms using new proposed BGP attributes
(in the context of which draft-jabley was a proof-of-concept using
community strings).

My draft draft can be found at:

  http://buffoon.automagic.org/dist/draft-jabley-edge-policy-propagation-control-02.txt

and is attached below.


Joe

-------------- next part --------------


Network Working Group                                           J. Abley
Internet-Draft                                                 MFN, Inc.
Expires: May 23, 2002                                  November 22, 2001


                    Edge Policy Propagation Control
            draft-jabley-edge-policy-propagation-control-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 23, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   There is a requirement for some multi-homed sites to influence the
   path selected by autonomous systems beyond those that are immediately
   adjacent.

   This draft describes a community-based convention which might be used
   to limit propagation of particular prefixes to those ASes where they
   are required.








Abley                     Expires May 23, 2002                  [Page 1]

Internet-Draft       Edge Policy Propagation Control       November 2001


1. Introduction

   There is a requirement for some multi-homed sites to influence the
   path selected by autonomous systems beyond those that are immediately
   adjacent.

   One of the few generic mechanisms available is to deaggregate and
   advertise long component prefixes to the network, since there can be
   some confidence that the longest prefix will be used, regardless of
   other local policy such as local preference.  Most ASes exhibit
   liberal route import policy with respect to prefix length, which
   facilitates this technique.

   Unfortunately, although the deaggregated prefix set may be required
   to be installed in only a few targeted ASes for the aims of the
   origin to be achieved, there is no reliable mechanism to limit the
   propagation of the prefixes.  This contributes to prefix bloat in the
   default-free zone, which is a concern.

































Abley                     Expires May 23, 2002                  [Page 2]

Internet-Draft       Edge Policy Propagation Control       November 2001


2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].














































Abley                     Expires May 23, 2002                  [Page 3]

Internet-Draft       Edge Policy Propagation Control       November 2001


3. Edge Policy Propagation Convention

3.1 At the Edge

   An edge site deaggregates its advertisements according to the
   required fine-grain policy.  Aggregate prefixes are advertised as
   normal; long prefixes are advertised tagged with community attributes
   which define their scope:

   EPPC_ALLOW:0 -- this prefix should be handled according to the
      convention described in this document.

   EPPC_ALLOW:A -- it is desirable that this prefix should propagate to
      AS A.  Multiple communities of the form EPPC_ALLOW:A may be
      present to define propagation scope.

   EPPC_ALLOW is some 16-bit quantity, well-known amongst the community
   of operators who cooperate according to this convention.  It should
   be chosen from the private-use range of ASNs specified in [2].

3.2 Towards the Other Edge

   ASes which support this convention MUST include additional clauses in
   their advertisement policy to all neighbour ASes, as follows.

3.2.1 Egress Policy

   When announcing prefixes to AS A:

   o  if the community attributes EPPC_ALLOW:0 and EPPC_ALLOW:A are both
      present, then the announcing router MAY advertise the prefix.

   o  If the community attribute EPPC_ALLOW:0 is present, and
      EPPC_ALLOW:A is not present, then the announcing router MUST
      suppress the advertisement.


3.2.2 Ingress Policy

   When AS B receives announcements from any other AS:

   o  if the community attribute EPPC_ALLOW:B is present, the receiving
      router MUST drop the advertisement.

   An implementation of this policy for cisco and Juniper routers can be
   found in Section 5.





Abley                     Expires May 23, 2002                  [Page 4]

Internet-Draft       Edge Policy Propagation Control       November 2001


3.3 Related Work

   A similar approach based on a new BGP attribute is described in the
   companion document draft-black-prop-path-00.txt.















































Abley                     Expires May 23, 2002                  [Page 5]

Internet-Draft       Edge Policy Propagation Control       November 2001


4. Example

   Consider the following internetwork:


               +------+
         +-----+ AS B +-----+
         |     +---+--+     |
     +---+--+      |     +--+---+    +------+
     | AS A |      |     | AS D +----+ AS F |
     +---+--+      |     +--+---+    +------+
         |     +---+--+     |
         +-----+ AS C +-----+
               +---+--+
                   |
               +---+--+
               | AS E |
               +------+


   AS A requires a particular set of prefixes to propagate within AS B,
   D and F, but not elsewhere.

   AS A therefore advertises the set of prefixes with the community
   attributes EPPC_ALLOW:0, EPPC_ALLOW:D and EPPC_ALLOW:F.

   AS B suppresses the advertisements towards AS C, since the community
   attribute APPC_ALLOW:0 is present without APPC_ALLOW:C.  AS B
   advertises the prefixes towards AS D.

   Similarly, AS D suppresses the advertisements towards AS C, and
   advertises the prefixes towards AS F.

   AS F suppresses the advertisements towards all peers, since
   APPC_ALLOW:0 is present without any other matching APPC_ALLOW:*
   community.

   The result is that the long prefix routes only propagate to AS B, AS
   D and AS F, in accordance with the policy specified by AS A.












Abley                     Expires May 23, 2002                  [Page 6]

Internet-Draft       Edge Policy Propagation Control       November 2001


5. Sample Implementations

5.1 Juniper JUNOS


   policy-options {
     /* EPPC policy towards A. */
     policy-statement eppc-to-A {
       /* If this route is an EPPC route and is for A, then delete
        * EPCC:A and continue.
        */
       term is-A {
         from community [ comm-eppc-zero comm-eppc-A ];
         then {
           next policy;
         }
       }
       /* If this route is an EPPC route, then drop it. */
       term is-eppc {
         from community comm-eppc-zero;
         then reject;
       }
       /* Otherwise continue as normal. */
         then next policy
     }
     /* The EPPC:0 community */
     community comm-eppc-zero members EPPC_ALLOW:0;
     /* The EPPC:A community meaning send to AS A */
     community comm-eppc-A members EPPC_ALLOW:A;
   }





















Abley                     Expires May 23, 2002                  [Page 7]

Internet-Draft       Edge Policy Propagation Control       November 2001


5.2 cisco IOS


   ip community-list EPPC-0 permit EPPC_ALLOW:0
   ip community-list EPPC-200 permit EPPC_ALLOW:200
   !
   route-map AS200 permit 10
    match comm-list EPPC-0 EPPC-200
   !
   route-map AS200 deny 20
    match comm-list EPPC-0
   !
   route-map AS200 permit 30
   !





































Abley                     Expires May 23, 2002                  [Page 8]

Internet-Draft       Edge Policy Propagation Control       November 2001


6. Acknowledgements

   Thanks to Andrew Partan for excellent envelope-scribbling and for the
   Juniper config fragment.















































Abley                     Expires May 23, 2002                  [Page 9]

Internet-Draft       Edge Policy Propagation Control       November 2001


References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [2]  Hawkinson, J. and T. Bates, "Guidelines for creation, selection,
        and registration of an Autonomous System (AS)", RFC 1930, March
        1996.

   [3]  Huston, G., "Analyzing the Internet's BGP Routing Table",
        January 2001.


Author's Address

   Joe Abley
   MFN, Inc.
   10805 Old River Road
   Komoka, ON  N0L 1R0
   Canada

   Phone: +1 519 641 4368
   EMail: jabley at mfnx.net




























Abley                     Expires May 23, 2002                 [Page 10]

Internet-Draft       Edge Policy Propagation Control       November 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Abley                     Expires May 23, 2002                 [Page 11]



More information about the Ptomaine mailing list