From insidethebiz at hotmail.com Sun Nov 4 22:33:39 2001 From: insidethebiz at hotmail.com (Inside The Biz) Date: Sun, 4 Nov 2001 22:33:39 Subject: ARISTA, UNIVERSAL, JIVE AND 13 OTHER LABELS .... Message-ID: <200111050330.fA53UPm25428@guelah.shrubbery.net> An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/ptomaine/attachments/20011104/bf901c22/attachment.html From jhaas at nexthop.com Thu Nov 15 18:07:20 2001 From: jhaas at nexthop.com (Jeffrey Haas) Date: Thu, 15 Nov 2001 13:07:20 -0500 Subject: draft-hardie-bounded-longest-match-01.txt Message-ID: <20011115130720.D23673@nexthop.com> I was reading through draft-hardie-bounded-longest-match-01.txt and was struck by something. The base BGP document declares in strong terms: : The function that calculates the degree of preference for a given : route shall not use as its inputs any of the following: the existence : of other routes, the non-existence of other routes, or the path : attributes of other routes. Ted's draft specifically changes this. Does anyone know the original reasons for this section in the BGP document? As Ted notes in his draft, route churn/explosion is probably the biggest reason. Removing a covering aggregate may lead to several "new" prefixes to show up in a otherwise "stable" routing system with the relevant convergence effects on the entire Internet. I would also note that "How Might this work" covers many of the same checks needed to properly implement ATOMIC_AGGREGATE. I don't believe ATOMIC_AGGREGATE is implemented by many vendors. This is likely due to the extra overhead involved. Comments? -- Jeff Haas NextHop Technologies From jhaas at nexthop.com Thu Nov 15 22:40:00 2001 From: jhaas at nexthop.com (Jeffrey Haas) Date: Thu, 15 Nov 2001 17:40:00 -0500 Subject: draft-hardie-bounded-longest-match-01.txt In-Reply-To: <20011115130720.D23673@nexthop.com>; from jhaas@nexthop.com on Thu, Nov 15, 2001 at 01:07:20PM -0500 References: <20011115130720.D23673@nexthop.com> Message-ID: <20011115174000.J23673@nexthop.com> On Thu, Nov 15, 2001 at 01:07:20PM -0500, Jeffrey Haas wrote: > I would also note that "How Might this work" covers many of the same > checks needed to properly implement ATOMIC_AGGREGATE. I don't > believe ATOMIC_AGGREGATE is implemented by many vendors. This is > likely due to the extra overhead involved. I should have said "properly implemented by many vendors" -- Jeff Haas NextHop Technologies From randy at psg.com Mon Nov 19 18:09:53 2001 From: randy at psg.com (Randy Bush) Date: Mon, 19 Nov 2001 10:09:53 -0800 Subject: meeting Message-ID: there will be a ptomaine wg meeting in salt lake. unless one of you nice folk volunteer, i will do it. agenda items needed, please randy From gih at telstra.net Wed Nov 21 22:39:39 2001 From: gih at telstra.net (Geoff Huston) Date: Thu, 22 Nov 2001 09:39:39 +1100 Subject: meeting In-Reply-To: Message-ID: <4.3.2.7.2.20011122093455.00c0f840@kahuna.telstra.net> At 11/20/01 05:09 AM, Randy Bush wrote: >there will be a ptomaine wg meeting in salt lake. unless one of you nice >folk volunteer, i will do it. > >agenda items needed, please 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. Abstract This document proposes the use of a scope control BGP community. This new well-known advisory transitive community is intended to allow an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, termed here as NOPEER, allows the origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. Does it need consideration in the WG meeting? (a summary of the draft was presented at the August meeting) regards, Geoff From randy at psg.com Thu Nov 22 12:46:43 2001 From: randy at psg.com (Randy Bush) Date: Thu, 22 Nov 2001 04:46:43 -0800 Subject: meeting References: <4.3.2.7.2.20011122093455.00c0f840@kahuna.telstra.net> Message-ID: > 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! randy From jabley at nlri.org Thu Nov 22 18:04:43 2001 From: jabley at nlri.org (Joe Abley) Date: Thu, 22 Nov 2001 13:04:43 -0500 Subject: meeting In-Reply-To: References: <4.3.2.7.2.20011122093455.00c0f840@kahuna.telstra.net> Message-ID: <20011122130443.Z2101@buffoon.automagic.org> 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] From joel at stevecrocker.com Thu Nov 22 23:27:59 2001 From: joel at stevecrocker.com (Joel M. Halpern) Date: Thu, 22 Nov 2001 18:27:59 -0500 Subject: meeting In-Reply-To: References: <4.3.2.7.2.20011122093455.00c0f840@kahuna.telstra.net> Message-ID: <4.2.2.20011122182606.00d0a340@mail.stevecrocker.com> Given that I have recently seen indications that a number of significant service providers already have this capability, the question is: 1) Is it used by the customers of those providers much 2) Is it actually helping to reduce the amount of advertisements that those providers which have it produce. To put this another way, we already have the running code out there, and it would be nice to know if it is producing the desired result before we start working on encouraging more people to use it. Thank you, Joel M. Halpern At 04:46 AM 11/22/01 -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! > >randy