From internet-drafts@ietf.org Fri Sep 16 14:09:03 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ED021F8C3C; Fri, 16 Sep 2011 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGYVasO7UzAj; Fri, 16 Sep 2011 14:09:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D64E21F8B7C; Fri, 16 Sep 2011 14:09:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-ospfv3-pece-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110916210903.32652.70577.idtracker@ietfa.amsl.com> Date: Fri, 16 Sep 2011 14:09:03 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 21:09:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Work= ing Group of the IETF. Title : OSPFv3 as a PE-CE routing protocol Author(s) : Padma Pillay-Esnault Peter Moyer Jeff Doyle Emre Ertekin Michael Lundberg Filename : draft-ietf-l3vpn-ospfv3-pece-09.txt Pages : 20 Date : 2011-09-16 Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ospfv3-pece-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-ospfv3-pece-09.txt From ben@niven-jenkins.co.uk Sat Sep 17 04:06:34 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CB221F855F for ; Sat, 17 Sep 2011 04:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.237 X-Spam-Level: X-Spam-Status: No, score=-103.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbv8sS3I6PtI for ; Sat, 17 Sep 2011 04:06:33 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 67CD821F8549 for ; Sat, 17 Sep 2011 04:06:33 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1R4slN-0005De-Hm for l3vpn@ietf.org; Sat, 17 Sep 2011 12:08:50 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: Please publish draft-ietf-l3vpn-ospfv3-pece-09 Date: Sat, 17 Sep 2011 12:08:48 +0100 References: To: L3VPN WG mailing list Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 11:06:34 -0000 FYI. Ben Begin forwarded message: > From: Ben Niven-Jenkins > Date: 17 September 2011 12:06:40 GMT+01:00 > To: Stewart Bryant > Cc: iesg-secretary@ietf.org, = draft-ietf-l3vpn-ospfv3-pece.all@tools.ietf.org > Subject: Please publish draft-ietf-l3vpn-ospfv3-pece-09 >=20 > Stewart, >=20 > I've included the document shepherd write up for = draft-ietf-l3vpn-ospfv3-pece-09 below. I will be the document shepherd. >=20 > Thanks > Ben >=20 > Intended Status: Standards Track >=20 > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the=20 > document and, in particular, does he or she believe this=20 > version is ready for forwarding to the IESG for publication?=20 >=20 > Ben Niven-Jenkins is the Document Shepherd for = draft-ietf-l3vpn-ospfv3-pece. I have personally reviewed the -09 version = of the document and believe that this version is ready for forwarding to = the IESG for publication as a Standards Track RFC. >=20 > (1.b) Has the document had adequate review both from key WG members=20 > and from key non-WG members? Does the Document Shepherd have=20 > any concerns about the depth or breadth of the reviews that=20 > have been performed? =20 >=20 > Publication of the document was originally requested in September 2009 = and approved by the IESG in December 2009. >=20 > In response to comments received since the approval, the authors = decided to make a further update to the document and the unusual step of = unapproving this document was taken and the document was returned to the = WG for additional work.=20 >=20 > The document was updated and jointly WG Last Called in OSPF and L3VPN = which led to further updates and a second joint WG Last Call. >=20 > No outstanding comments exist and it is my opinion that the document = has received extensive review and is now ready to be published. >=20 > (1.c) Does the Document Shepherd have concerns that the document=20 > needs more review from a particular or broader perspective,=20 > e.g., security, operational complexity, someone familiar with=20 > AAA, internationalization or XML?=20 >=20 > No >=20 > (1.d) Does the Document Shepherd have any specific concerns or=20 > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he=20 > or she is uncomfortable with certain parts of the document, or=20 > has concerns whether there really is a need for it. In any=20 > event, if the WG has discussed those issues and has indicated=20 > that it still wishes to advance the document, detail those=20 > concerns here. Has an IPR disclosure related to this document=20 > been filed? If so, please include a reference to the=20 > disclosure and summarize the WG discussion and conclusion on=20 > this issue.=20 >=20 > No concerns and no IPR disclosures have been filed. >=20 > (1.e) How solid is the WG consensus behind this document? Does it=20 > represent the strong concurrence of a few individuals, with=20 > others being silent, or does the WG as a whole understand and=20 > agree with it? =20 >=20 > There were no objections during the joint OSPF and L3VPN WG Last Calls = on the document. >=20 > (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20= > discontent? If so, please summarise the areas of conflict in=20 > separate email messages to the Responsible Area Director. (It=20 > should be in a separate email because this questionnaire is=20 > entered into the ID Tracker.)=20 >=20 > No, not to my knowledge. >=20 > (1.g) Has the Document Shepherd personally verified that the=20 > document satisfies all ID nits? (See the Internet-Drafts Checklist=20= > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20 > not enough; this check needs to be thorough. Has the document=20 > met all formal review criteria it needs to, such as the MIB=20 > Doctor, media type and URI type reviews?=20 >=20 > The idnits tools reports "There are 2 instances of lines with = non-RFC5735-compliant IPv4 addresses in the document. If these are = example addresses, they should be changed." However the instances = referred to are references to sections in another RFC and so this is a = false error on the part of the idnits tool and not a failing of the = document. >=20 > There are no MIB or other elements in the document that would warrant = review. As such, I have no concerns here. >=20 > (1.h) Has the document split its references into normative and=20 > informative? Are there normative references to documents that=20 > are not ready for advancement or are otherwise in an unclear=20 > state? If such normative references exist, what is the=20 > strategy for their completion? Are there normative references=20 > that are downward references, as described in [RFC3967]? If=20 > so, list these downward references to support the Area=20 > Director in the Last Call procedure for them [RFC3967].=20 >=20 > The document splits its references into normative and informative. All = normative references are to published RFCs. There are no downward = references. >=20 >=20 > (1.i) Has the Document Shepherd verified that the document IANA=20 > consideration section exists and is consistent with the body=20 > of the document? If the document specifies protocol=20 > extensions, are reservations requested in appropriate IANA=20 > registries? Are the IANA registries clearly identified? If=20 > the document creates a new registry, does it define the=20 > proposed initial contents of the registry and an allocation=20 > procedure for future registrations? Does it suggest a=20 > reasonable name for the new registry? See [RFC5226]. If the=20 > document describes an Expert Review process has Shepherd=20 > conferred with the Responsible Area Director so that the IESG=20 > can appoint the needed Expert during the IESG Evaluation?=20 >=20 > The document does not specify any protocol extensions that require the = creation of new IANA registries or that require allocation of code = points in existing registries. >=20 > However, A early draft of this document resulted in the allocation of = OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific = Extended Community. This allocation is no longer required. IANA is = requested to mark the OSPFv3 Route Attributes (0x0004) entry in the BGP = IPv6 Address Specific Extended Community registry as deprecated. >=20 > (1.j) Has the Document Shepherd verified that sections of the=20 > document that are written in a formal language, such as XML=20 > code, BNF rules, MIB definitions, etc., validate correctly in=20 > an automated checker?=20 >=20 > No section of this document is written in a formal language. >=20 > (1.k) The IESG approval announcement includes a Document=20 > Announcement Write-Up. Please provide such a Document=20 > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval=20 > announcement contains the following sections:=20 >=20 > Technical Summary=20 > Relevant content can frequently be found in the abstract=20 > and/or introduction of the document. If not, this may be=20 > an indication that there are deficiencies in the abstract=20 > or introduction.=20 >=20 > The initial BGP/MPLS IP VPN specification enabled PE routers to learn = routes within customer sites through static routing, or through a = dynamic routing protocol instantiated on the PE-CE link. >=20 > Specifically, RFC4364 includes support for dynamic routing protocols = such as BGP, RIP, and OSPFv2. The OSPFv2 as the Provider/Customer Edge = Protocol for BGP/MPLS IP Virtual Private Networks specification = (RFC4577) further updates the operation of OSPFv2 as the PE-CE routing = protocol by detailing additional extensions to enable intra-domain = routing connectivity between OSPFv2-based customer sites. >=20 > This document defines the mechanisms required to enable the operation = of OSPFv3 as the PE-CE Routing Protocol in BGP MPLS/IP VPNs. In doing = so, it reuses, and extends where necessary, the "BGP/MPLS IP VPN" method = for IPv6 VPNs defined in RFC4659, and OSPFv2 as the PE-CE routing = protocol defined in RFC4577. This document also includes the = specifications for maintaining intra-domain routing connectivity between = OSPFv3-based customer sites across a SP backbone. >=20 > Working Group Summary=20 > Was there anything in WG process that is worth noting? For=20 > example, was there controversy about particular points or=20 > were there decisions where the consensus was particularly=20 > rough?=20 >=20 > This document is a product of L3VPN WG. The document underwent WG Last = Calls in both the L3VPN and OSPF WGs. >=20 > Document Quality=20 > Are there existing implementations of the protocol? >=20 > I am aware of one existing implementation. >=20 > Have a significant number of vendors indicated their plan > to implement the specification? >=20 > I do not know. However there is already one implementation that I am = aware of. >=20 > Are there any reviewers that merit special mention as > having done a thorough review, e.g., one that resulted in > important changes or a conclusion that the document had no > substantive issues? >=20 > Not to the best of my knowledge. >=20 > If there was a MIB Doctor, Media Type or other expert > review, what was its course (briefly)? In the case of a > Media Type review, on what date was the request posted? >=20 > No such review was conducted as it was not considered necessary. From ben@niven-jenkins.co.uk Sat Sep 17 04:12:25 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88FC21F891D for ; Sat, 17 Sep 2011 04:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELrLwNl2mNwh for ; Sat, 17 Sep 2011 04:12:25 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75921F8A4B for ; Sat, 17 Sep 2011 04:12:25 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1R4sr3-0005qH-26; Sat, 17 Sep 2011 12:14:41 +0100 Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-wldcds-cmbind-00 as a L3VPN WG document? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <5E84490C-9456-4E33-B57B-6DEF29195A5B@niven-jenkins.co.uk> Date: Sat, 17 Sep 2011 12:14:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E84490C-9456-4E33-B57B-6DEF29195A5B@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: L3VPN WG mailing list X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 11:12:26 -0000 Colleagues, We have consesnus to adopt draft-rosen-l3vpn-mvpn-wldcds-cmbind-00 as a = L3VPN WG document, can the authors please re-submit it as = draft-ietf-l3vpn-mvpn-wldcds-cmbind-00. Thanks Ben On 30 Aug 2011, at 16:58, Ben Niven-Jenkins wrote: > L3VPNers, >=20 > We have a milestone in our charter to "Submit S-PMSI A-D route = Wildcard selection specification to IESG as PS". >=20 > Previously we had two individual drafts = (draft-rekhter-mvpn-wildcard-spmsi & draft-rosen-l3vpn-mvpn-wildcards) = that addressed this topic. The authors of those drafts have now produced = a single combined draft: draft-rosen-l3vpn-mvpn-wldcds-cmbind-00 >=20 > This e-mail is to start a poll on whether the L3VPN WG should adopt = the new combined draft-rosen-l3vpn-mvpn-wldcds-cmbind-00 as a L3VPN WG = document. >=20 > Please indicate your support or otherwise by responding to this = message (with yes/support or no/do not support) or by e-mailing the WG = chairs privately. >=20 > If you do not support the adoption of the document it would be useful = if you could also state the reason for your objection. >=20 > Please send your responses by midnight 13th September PT. >=20 > Thanks > Ben From internet-drafts@ietf.org Wed Sep 21 09:52:18 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2172D1F0C80; Wed, 21 Sep 2011 09:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlRaXOx1IbhP; Wed, 21 Sep 2011 09:52:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB3B1F0C47; Wed, 21 Sep 2011 09:52:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-wildcards-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110921165217.10824.47113.idtracker@ietfa.amsl.com> Date: Wed, 21 Sep 2011 09:52:17 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 16:52:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Work= ing Group of the IETF. Title : Wildcards in Multicast VPN Auto-Discovery Routes Author(s) : Eric C. Rosen Yakov Rekhter Ray (Lei) Qiu Filename : draft-ietf-l3vpn-mvpn-wildcards-00.txt Pages : 18 Date : 2011-09-21 In "Multicast Virtual Private Networks" (MVPNs), customer mult= icast flows are carried in "tunnels" through a service provider'= s network. The base specifications for MVPN define BGP multicast VPN "auto-discovery" routes", and specify how to use an auto-= discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" element= s in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows, or even to all customer flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-wildcards-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-wildcards-00.txt From wwwrun@rfc-editor.org Fri Sep 23 16:06:41 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305E921F8CAC; Fri, 23 Sep 2011 16:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.18 X-Spam-Level: X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44B0OZukJEhJ; Fri, 23 Sep 2011 16:06:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A8DB921F8C94; Fri, 23 Sep 2011 16:06:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3223998C246; Fri, 23 Sep 2011 16:09:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6368 on Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) From: rfc-editor@rfc-editor.org Message-Id: <20110923230916.3223998C246@rfc-editor.org> Date: Fri, 23 Sep 2011 16:09:16 -0700 (PDT) Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 23:06:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6368 Title: Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) Author: P. Marques, R. Raszuk, K. Patel, K. Kumaki, T. Yamagata Status: Standards Track Stream: IETF Date: September 2011 Mailbox: pedro.r.marques@gmail.com, robert@raszuk.net, keyupate@cisco.com, ke-kumaki@kddi.com, to-yamagata@kddi.com Pages: 14 Characters: 29938 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-ibgp-08.txt URL: http://www.rfc-editor.org/rfc/rfc6368.txt This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK] This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ccie15672@yahoo.com Mon Sep 26 09:58:39 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E1511E80C5 for ; Mon, 26 Sep 2011 09:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1Q74usVbAMB for ; Mon, 26 Sep 2011 09:58:39 -0700 (PDT) Received: from nm25-vm0.bullet.mail.bf1.yahoo.com (nm25-vm0.bullet.mail.bf1.yahoo.com [98.139.213.156]) by ietfa.amsl.com (Postfix) with SMTP id DE01011E80B6 for ; Mon, 26 Sep 2011 09:58:38 -0700 (PDT) Received: from [98.139.214.32] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2011 17:01:21 -0000 Received: from [98.139.212.219] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2011 17:01:21 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 26 Sep 2011 17:01:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 717740.41705.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 88443 invoked by uid 60001); 26 Sep 2011 17:01:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317056481; bh=cED/DknkWZkkQM7oo8p//9rHfTXTdJ6Yd5Dz1fJtVxw=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=sgWVtIeJ3Ky4//sR+qqNnqbXFyNkM0BVPglD5CGYyaNr6uGOtNWOCcmA+BrfE67KWjJcaXSiV3hy6+yS5oOZyeiAFMuXdMggvjTMPaAUdOxXLkCeIDXGHfvxGY51SjzdulDhyBmwxU5y+Yy2hFv7viodzMf/dDqRDYZrftanW+E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=EU6jf62tMUJ0wgybSoypFzSCLVY5vFqhGtiJ0QhsPLoJMPTksEsPwagdZ1XqDUBrcukxTw9Bl0QOxngDGRTMKPx2/nFQ3pDWcUs8ISqoqScWEkIinFwubLVMDHUPIUHYzEVPiVJ+9O6PTML704zlefGdYtt2NQjssEcc8sCiDTo=; X-YMail-OSG: 7XKlYEIVM1m0qfTh6zJvn8F0DhYc5pfZSkTJvOtR.X2R9DB Kn_hEcqUwQ_gI8iLxaEhjNYS9hEmvQ1nYEQeDXf9F__JywcKXh1S_3bJuDSZ op..mt82EkTiCqxeA_PTt4VcyFdg8cuDuYob1A0nCx9Zbgl6sv.ny4pNwIhj 5OvvTPjdZOhyKoa6IkWNt8CSKofac_Cwp.nO.RMw7_Pt_2axzwVR_ATHDxiQ cK6Lr2kwPMVAyOTTBS4hHRXEJp65zJc67w1Jof2630tqiUbgh5DYqeKo5B_Q ZDK695_ITssi5IHdqsvzxVilN9H463wE7bmbu_sAzJ9DK8WcPGOkkWFNk31F Ers.4fC0ZZ2KBoTEfwDTnF5.sYXb0DzQd0KKhSHLIhxsdEBq0RCSyYObfcwa MU_qpHPdlmDrcl01ZKCW.ALcu_A65nwGXLpo7tFMK2Z8- Received: from [76.194.43.66] by web161806.mail.bf1.yahoo.com via HTTP; Mon, 26 Sep 2011 10:01:21 PDT X-Mailer: YahooMailWebService/0.8.113.315625 Message-ID: <1317056481.87975.YahooMailNeo@web161806.mail.bf1.yahoo.com> Date: Mon, 26 Sep 2011 10:01:21 -0700 (PDT) From: Derick Winkworth Subject: General question re: VRFs and FIBs... To: "l3vpn@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1665047788-259880989-1317056481=:87975" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Derick Winkworth List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 16:58:39 -0000 --1665047788-259880989-1317056481=:87975 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All:=0A=0AI'm trying to find an archived discussion or presentation discuss= ing why exactly the industry generally settled on having a separate FIB tab= le for each VRF vs having one table with a column that identifies the VRF i= nstance?=0A=0AI'm not finding it, but I'm guessing its because of performan= ce issues? =A0=0A=0AAny pointers would be great or perhaps someone on the l= ist knows why?=0A=0AThanks!=0A=0ADerick --1665047788-259880989-1317056481=:87975 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All:=

I'm trying to find an archived discussion or pres= entation discussing why exactly the industry generally settled on having a = separate FIB table for each VRF vs having one table with a column that iden= tifies the VRF instance?

I'm not finding it, but I= 'm guessing its because of performance issues?  

<= div>Any pointers would be great or perhaps someone on the list knows why?

Thanks!

Derick
= --1665047788-259880989-1317056481=:87975-- From robert@raszuk.net Mon Sep 26 10:37:39 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D02221F8D4B for ; Mon, 26 Sep 2011 10:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqc1XuZTbCGF for ; Mon, 26 Sep 2011 10:37:38 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 5F8AA21F8C0B for ; Mon, 26 Sep 2011 10:37:38 -0700 (PDT) Received: (qmail 6729 invoked by uid 399); 26 Sep 2011 17:40:20 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.31.234.68) by mail37.opentransfer.com with SMTP; 26 Sep 2011 17:40:20 -0000 Message-ID: <4E80B903.4090303@raszuk.net> Date: Mon, 26 Sep 2011 19:40:19 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Derick Winkworth Subject: Re: General question re: VRFs and FIBs... References: <1317056481.87975.YahooMailNeo@web161806.mail.bf1.yahoo.com> In-Reply-To: <1317056481.87975.YahooMailNeo@web161806.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 17:37:39 -0000 Hi Derick, As I recall main driver for separate RIB and FIB structures (as opposed to single one with index used for sharing) was customer isolation and separation. If you crash one customer's RIB/FIB rest of customers can't be impacted. It is as close as virtual/logical routers without multiplying all other router's resources N number of times. Rgs, R. > All: > > I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one table with a column that identifies the VRF instance? > > I'm not finding it, but I'm guessing its because of performance issues? > > Any pointers would be great or perhaps someone on the list knows why? > > Thanks! > > Derick From lufang@cisco.com Mon Sep 26 12:11:12 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8011D21F8CF2 for ; Mon, 26 Sep 2011 12:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g0x71Tb-6u5 for ; Mon, 26 Sep 2011 12:11:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D821321F8CEF for ; Mon, 26 Sep 2011 12:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=3783; q=dns/txt; s=iport; t=1317064435; x=1318274035; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=8tPwMWyuCRoX0rXEgTJrFcUORub/vLWfQUX20S6s95E=; b=C2O+ckBE/7d9t/WAA+CdG9a1kBZeqwJrGGWq3VR9Cm/sdCqyCuAN/FYl fzPO0s7S6lbWv/ZB3CfhC3bgN1Pjvh8dYKmRCLzp4GMg7xqQ1SrcI+QjW 4a6ELpdptusqguHu+JmtHfAGlN0itVmYPRcbEyE1pPjARkHfGNOXB3E3r E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEBAKfNgE6tJV2b/2dsb2JhbABCmQ8Pjnh4gVMBAQEBAgEBAQEPAR0KFCAQBwQCARkDAQEBCwIBAxcBBgEmChQBCQgBAQQTCAEUBAGHVgacUwGeMIYrYASHcpELhGyHOg X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="24126062" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 26 Sep 2011 19:13:55 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8QJDtdt029414 for ; Mon, 26 Sep 2011 19:13:55 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 14:13:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: General question re: VRFs and FIBs... Date: Mon, 26 Sep 2011 14:14:02 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2506EC3357@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: General question re: VRFs and FIBs... Thread-Index: Acx8fwGB1aCAaCDgTvOk+/9hzz09hwAAM+sw References: From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 26 Sep 2011 19:13:54.0568 (UTC) FILETIME=[6EEE7080:01CC7C80] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 19:11:12 -0000 Derick, Rob is right.=20 It is for VPN security/protection to have separate RIB and FIB structures. Cheers, Luyuan -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of l3vpn-request@ietf.org Sent: Monday, September 26, 2011 3:00 PM To: l3vpn@ietf.org Subject: L3VPN Digest, Vol 87, Issue 5 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/l3vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L3VPN mailing list submissions to l3vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l3vpn or, via email, send a message with subject or body 'help' to l3vpn-request@ietf.org You can reach the person managing the list at l3vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L3VPN digest..." Today's Topics: 1. General question re: VRFs and FIBs... (Derick Winkworth) 2. Re: General question re: VRFs and FIBs... (Robert Raszuk) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Sep 2011 10:01:21 -0700 (PDT) From: Derick Winkworth To: "l3vpn@ietf.org" Subject: General question re: VRFs and FIBs... Message-ID: <1317056481.87975.YahooMailNeo@web161806.mail.bf1.yahoo.com> Content-Type: text/plain; charset=3D"iso-8859-1" All: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? ? Any pointers would be great or perhaps someone on the list knows why? Thanks! Derick -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Mon, 26 Sep 2011 19:40:19 +0200 From: Robert Raszuk To: Derick Winkworth Cc: "l3vpn@ietf.org" Subject: Re: General question re: VRFs and FIBs... Message-ID: <4E80B903.4090303@raszuk.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi Derick, As I recall main driver for separate RIB and FIB structures (as opposed=20 to single one with index used for sharing) was customer isolation and=20 separation. If you crash one customer's RIB/FIB rest of customers can't be impacted. It is as close as virtual/logical routers without multiplying all other=20 router's resources N number of times. Rgs, R. > All: > > I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one table with a column that identifies the VRF instance? > > I'm not finding it, but I'm guessing its because of performance issues? > > Any pointers would be great or perhaps someone on the list knows why? > > Thanks! > > Derick ------------------------------ _______________________________________________ L3VPN mailing list L3VPN@ietf.org https://www.ietf.org/mailman/listinfo/l3vpn End of L3VPN Digest, Vol 87, Issue 5 ************************************ From saku@ytti.fi Mon Sep 26 23:46:04 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237E921F8DE0 for ; Mon, 26 Sep 2011 23:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT7gt2bjmFVl for ; Mon, 26 Sep 2011 23:46:03 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBB221F8DDE for ; Mon, 26 Sep 2011 23:46:02 -0700 (PDT) Received: by qyk32 with SMTP id 32so505454qyk.10 for ; Mon, 26 Sep 2011 23:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.37.207 with SMTP id y15mr2565098qcd.151.1317106127275; Mon, 26 Sep 2011 23:48:47 -0700 (PDT) Received: by 10.229.88.199 with HTTP; Mon, 26 Sep 2011 23:48:46 -0700 (PDT) In-Reply-To: <238542D917511A45B6B8AA806E875E2506EC3357@XMB-RCD-201.cisco.com> References: <238542D917511A45B6B8AA806E875E2506EC3357@XMB-RCD-201.cisco.com> Date: Tue, 27 Sep 2011 09:48:46 +0300 Message-ID: Subject: Re: General question re: VRFs and FIBs... From: Saku Ytti To: "Luyuan Fang (lufang)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 06:46:04 -0000 On 26 September 2011 22:14, Luyuan Fang (lufang) wrote > Rob is right. > It is for VPN security/protection to have separate RIB and FIB > structures. Disclaimer, I have very little understanding of router internals. I guess this is hardware dependent? And pretty much same problem domain as VLAN in switches, which already should give us clue there isn't exactly single solution to the problem. Some switches don't even allow colliding MAC addresses in unique VLAN, which speaks volumes of implementation in that device. But if we do have single flat FIB, how do we perform lookup against it? Do we offer IP address as key to trie lookup and declare miss if ultimate hit was for wrong VRF? This would be very costly lookup. And if VRF A has two entries and VRF B has two million entries, does VRF A suffer due to aggregate FIB? What is cost of changing this aggregate FIB? If we first do lookup for VRF/VLAN then lookup in single structured FIB which contains only eligible addresses, the lookup itself can be implemented exactly same as if you had no VLAN/VRF support at all, no new magic need to be implemented in hardware for that part (only the previous part of looking up the VLAN/VRF). But exactly how this FIB will look in some modern chip like ezchip, xelerated or trio probably does not 100% translate to either of these (I've understood that allowing FIB to live in relatively slow DRAM has needed some changes how the data is presented). It would be interesting if CSCO/JNPR/ALU or someone who has designed modern routers would give presentation in nanog/ripe on how modern routers works. > > Cheers, > Luyuan > > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of l3vpn-request@ietf.org > Sent: Monday, September 26, 2011 3:00 PM > To: l3vpn@ietf.org > Subject: L3VPN Digest, Vol 87, Issue 5 > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. =C2=A0To do so, go to > > https://www.ietf.org/mailman/listinfo/l3vpn > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. =C2=A0You can set this option > globally for all the list digests you receive at this point. > > > > Send L3VPN mailing list submissions to > =C2=A0 =C2=A0 =C2=A0 =C2=A0l3vpn@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/l3vpn > or, via email, send a message with subject or body 'help' to > =C2=A0 =C2=A0 =C2=A0 =C2=A0l3vpn-request@ietf.org > > You can reach the person managing the list at > =C2=A0 =C2=A0 =C2=A0 =C2=A0l3vpn-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of L3VPN digest..." > > > Today's Topics: > > =C2=A0 1. General question re: VRFs and FIBs... (Derick Winkworth) > =C2=A0 2. Re: General question re: VRFs and FIBs... (Robert Raszuk) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 26 Sep 2011 10:01:21 -0700 (PDT) > From: Derick Winkworth > To: "l3vpn@ietf.org" > Subject: General question re: VRFs and FIBs... > Message-ID: > =C2=A0 =C2=A0 =C2=A0 =C2=A0<1317056481.87975.YahooMailNeo@web161806.mail.= bf1.yahoo.com> > Content-Type: text/plain; charset=3D"iso-8859-1" > > All: > > I'm trying to find an archived discussion or presentation discussing why > exactly the industry generally settled on having a separate FIB table > for each VRF vs having one table with a column that identifies the VRF > instance? > > I'm not finding it, but I'm guessing its because of performance issues? > ? > > Any pointers would be great or perhaps someone on the list knows why? > > Thanks! > > Derick > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 8/attachment.htm> > > ------------------------------ > > Message: 2 > Date: Mon, 26 Sep 2011 19:40:19 +0200 > From: Robert Raszuk > To: Derick Winkworth > Cc: "l3vpn@ietf.org" > Subject: Re: General question re: VRFs and FIBs... > Message-ID: <4E80B903.4090303@raszuk.net> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Hi Derick, > > As I recall main driver for separate RIB and FIB structures (as opposed > to single one with index used for sharing) was customer isolation and > separation. > > If you crash one customer's RIB/FIB rest of customers can't be impacted. > > It is as close as virtual/logical routers without multiplying all other > router's resources N number of times. > > Rgs, > R. > > >> All: >> >> I'm trying to find an archived discussion or presentation discussing > why exactly the industry generally settled on having a separate FIB > table for each VRF vs having one table with a column that identifies the > VRF instance? >> >> I'm not finding it, but I'm guessing its because of performance > issues? >> >> Any pointers would be great or perhaps someone on the list knows why? >> >> Thanks! >> >> Derick > > > > ------------------------------ > > _______________________________________________ > L3VPN mailing list > L3VPN@ietf.org > https://www.ietf.org/mailman/listinfo/l3vpn > > > End of L3VPN Digest, Vol 87, Issue 5 > ************************************ > --=20 =C2=A0 ++ytti