From l3vpn-bounces@ietf.org Tue Dec 7 20:46:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28416 for ; Tue, 7 Dec 2004 20:46:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbr1U-0007UK-KR for l3vpn-web-archive@ietf.org; Tue, 07 Dec 2004 20:53:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbqsx-00047e-O8; Tue, 07 Dec 2004 20:44:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbqiz-0002ED-Ra; Tue, 07 Dec 2004 20:34:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26846; Tue, 7 Dec 2004 20:34:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbqpg-000790-2N; Tue, 07 Dec 2004 20:41:32 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CbqfX-0001PY-EQ; Tue, 07 Dec 2004 20:31:03 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 07 Dec 2004 20:31:03 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Internet Architecture Board , l3vpn mailing list , l3vpn chair , l3vpn chair , RFC Editor Subject: Document Action: 'Security Framework for Provider Provisioned Virtual Private Networks' to Informational RFC X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The IESG has approved the following document: - 'Security Framework for Provider Provisioned Virtual Private Networks ' as an Informational RFC This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. Russ Housley also obtained a security review from the Security Directorate. RFC Editor Note: In the references section: [Beard] D. Beard and Y. Yang, "Known Threats to Routing Protocols," draft-beard-rpsec-routing-threats-00.txt, Oct. 2002. Is actually for: draft-ietf-rpsec-routing-threats-07.txt And [GDOI] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of Interpretation," draft-ietf-msec-gdoi-07.txt, December 2002. has been published as RFC 3547. From l3vpn-bounces@ietf.org Thu Dec 9 16:44:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13716 for ; Thu, 9 Dec 2004 16:44:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcWCg-0001li-6u for l3vpn-web-archive@ietf.org; Thu, 09 Dec 2004 16:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVMJ-0005DM-1Y; Thu, 09 Dec 2004 15:57:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVAM-0007IC-Lf for l3vpn@megatron.ietf.org; Thu, 09 Dec 2004 15:45:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02574 for ; Thu, 9 Dec 2004 15:45:33 -0500 (EST) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcVHO-0006U8-RD for l3vpn@ietf.org; Thu, 09 Dec 2004 15:52:52 -0500 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 20:44:59 +0000 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Dec 2004 15:44:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Dec 2004 15:44:56 -0500 Message-ID: <1E8ACF422ADD1A458AAFFAD2E6FF70C801017E88@proton.jnpr.net> Thread-Topic: CE Authentication Drafts Thread-Index: AcTeL/E4qXiNpsEcSGylF36fveB19g== From: "Ronald Bonica" To: X-OriginalArrivalTime: 09 Dec 2004 20:44:57.0961 (UTC) FILETIME=[F2168D90:01C4DE2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: CE Authentication Drafts X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Folks, At IETF 58, Michael Behringer and I agreed to merge the following drafts: - draft-behringer-mpls-vpn-auth - draft-ietf-l3vpn-l3vpn-auth Merging these drafts was more difficult than we expected, essentially because the two drafts solve two different problems. So, we have decided to proceed as follows: - refresh both drafts - initiate discussion on the mailing list to determine whether one, the other, or both drafts should progress Ron /as individual contributor From l3vpn-bounces@ietf.org Fri Dec 10 19:59:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16527 for ; Fri, 10 Dec 2004 19:59:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcvjJ-0005Fd-SA for l3vpn-web-archive@ietf.org; Fri, 10 Dec 2004 20:07:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccvaz-0006Cf-Vb; Fri, 10 Dec 2004 19:58:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcvXh-0004xG-6b for l3vpn@megatron.ietf.org; Fri, 10 Dec 2004 19:55:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16093 for ; Fri, 10 Dec 2004 19:55:23 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccvez-00059a-4m for l3vpn@ietf.org; Fri, 10 Dec 2004 20:02:57 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id iBB0sr981286 for ; Fri, 10 Dec 2004 16:54:53 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.24.236.2]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iBB0sle73999 for ; Fri, 10 Dec 2004 16:54:47 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20041210144032.03398ce0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 10 Dec 2004 14:43:50 -0500 To: l3vpn@ietf.org From: Ross Callon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.7 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Subject: Text version of L3VPN minutes X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Here is a text version of the working group minutes. The slightly better looking Word version and those presentations that I have will appear in the proceedings. Thanks, Ross ------------------------------------------------------------- L3VPN meeting minutes IETF-61 Mon 8 Nov 2004 =================== Thanks to Mark Duffy for minutes. Agenda Agenda bashing and scribe discovery. Working group document status Multicast Requirements (Thomas Morin / Elodie Hemon) Multicast Approach (Eric Rosen) Multicast Approach (Rahul Aggarwal) Multicast Approach (Seisho Yasukawa) --------------------------------------------------------------------- Working Group Document Status (Ross Callon) Ross went through the status of various working group documents. Note that we have had several approved by the IESG since the last IETF, and have multiple additional documents that have passed working group last call and are currently being reviewed by the IESG and/or being updated in response to IESG comments. Generic requirements - has been published as rfc3808 L3 Framework - in rfc editors queue for 18 mos, waiting normative ref on service reqts (wrt which we have good news) L3 Service requirements - has been approved by the IESG and is now in rfc editor queue. This is good both in its own right, and also because it frees up the L3 Framework to be published. Security framework - almost done. 1 or 2 issues remain. BGP/MPLS VPN Spec and Applicability Statement - these have been approved by iesg, and are therefore now in the rfc editor's queue. Virtual Router Architecture and associated Applicability Statement - these are still under IESG review. CE / IPsec Architecture and associated Applicability Statement - these are still under IESG review. Terminology draft - Has been approved by iesg, in rfc editor's queue Thomas Narten: Texts need to make it more clear that some of these docs are frameworks etc. not standards. Framework for l3vpn oam - This has just passed working group last call and been sent to iesg Textual conventions - Ditto (has just been sent to iesg) MPLS / BGP MIB - This has passed wg last call and been submitted to the IESG. Virtual Router MIB - This is waiting for an update by the document authors. BGP auto discovery - Has passed working group call and been submitted to iesg. ospf as pe/ce protocol - Has passed working group last call in both L3VPN and OSPF working groups, and been sent to iesg bgp/mpls for IPv6 vpn - This is ready for wg last call. PE-PE IPsec for 2547 - in working group last call, an update is needed to respond to comments received. PE-PE GRE/IP for 2547 - Has been submitted to iesg. CE-CE Member Verification - draft has timed out; the chairs have prodded authors. Constrained VPN Route Distribution - Has passed working group last call and been submitted to iesg. Eric Rosen: 2547bis is waiting in the RFC editor queue for BGP Extended Communities to be published, which in turn is waiting for the base BGP spec. Question from the working group chairs: Who here is interested in IS-IS as CE-PE protocol for 2547? There was no response. -------------------------------------------------------------------------------------- Requirements for multicast in Provider Provisioned IP VPNs (Elodie Hemon, France Telecom) draft-morin-l3vpn-ppvpn-mcast-reqts-00 Many solutions have been proposed for multicast over L3VPNs. No multicast requirements document has been written yet. Operator feedback may help in developing and chosing between multicast solutions. The requirements are intended to be solution-agnostic, and will serve as a guideline for solution drafts. There is a tradeoff between use of Bandwidth vs state in routers Need: scalability, tunability, traffic engineering, versatility (vis-a-vis tunneling modes), inter-AS, inter-provider support monitor/troubleshoot capabilities robustness and infrastructure security Open questions: Extranet support? Fragmentation issues? MTU management. Control mechanisms Need use cases Carrier's carrier Next steps: Integrate received feedback Want more feedback! Questions: (???): Tunnel mode agnostic: is it v4/v6 agnostic? (Chen Yin Lee): Is it layer agnostic too :-) ? Some of this may apply to L2 also. (John Ryan?, Cisco): this is useful work. Solutions should say which requirements are met. (???) - What are the important applications? A: We don't care what the content is. Q: But from providers' POV, what is the application, what are the bandwidth reqts? (Jamie Miles, L3 Communications): Multicast is very important! We *Need* inter-provider; including all 3 2547 inter-provider approaches. (???, Cisco): Requirements should be application-agnostic. (???, Cisco): Should Internet multicast as a transit service be included? Fragmentation should be avoided completely. In IPv6 mcast should default to 1280 MTU; this is a good practice for v4 too. (Luyuan Fang): This is good, should continue this effort. This effort should focus on VPN, not Internet multicast. Doesn't see many customers for Internet multicast. (Alex Zinin): The security requirements section is empty! about long list of tunnelling protocols. Ross: show of hands to interested to make wg doc: many in favor, none/few opposed. ----------------------------------------------------------------- Multicast in MPLS/BGP IP VPNs (Eric Rosen, Cisco) draft-rosen-vpn-mcast-07 Mcast for 2547: New to wg charter, but the work has been ongoing since 1998 Many proposals now, all based on same basic architecture There is significant (but not massive) deployment There are multiple vendors with deployed multicast over L3VPNs (but "less than 3" :-) The new proposals extend, generalize, improve scalability. How to proceed: Break arch into a few pieces and look at them separately Focus on producing standard, not battle between exisiting implementations. Contentious issues: Mcast distribution trees in SP backbone Not much Internet mcast but fair amount of enterprise mcast Scaling issues. There is a tradeoff between: state in P routers packets carried more than once over the same link packets sent to PEs that have no receivers Single vs multi provider Traffic engineering PE-PE PIM adjacencies in PE's PIM C-Instance "Just as bad as the Virtual Router approach!" PIM hellos overhead PIM join/prune messages overhead Transparency to existing enterprise multicast structure. MDT in SP: P-State Scaling Base proposal uses hierarchical aggregation All groups from one VPN share a tree Requires state in P routers ... Further scaling needs further aggregation by hierarchy? seems elegant but no proposal. by some sort of TE? figure out how some VPNs can share a tree. other ways? Traffic load scaling Unaggregated MDTs are better at scaling traffic load (reduce multiple transmissions per link, packets sent to uninterested PEs) What's with all the aggregation, de-agregation, reaggregation? Are we thrashing? Reaching the limits of the technology? ... Proposal for demux using mpls encap Requires enhancement to mpls arch: context label, upstream label distribution Need to worry about IP-based encaps as well. Do default MDTs provide enough aggregation? Not enough to support unlimited growth. Need more aggregation. Scaling conclusion: One size doesn't fit all. The most scalable schemes may be too expensive in traffic loading. Technology to create the MDT? PIM-based solutions: PIM-SM - extremely complicated. Source trees. PIM-SSM - much simpler. Needs bgp-based source discovery BIDIR - best P-state scaling for intra-AS. Explicitly routed MDTs (p2mp rsvp-te) Might be useful in some environments Unicast tunnels with replication at ingress Optimizes P-state, poor for traffic load Doesn't think we can throw any of these approaches out! Scaling PE-PE interaction in PIM C-instance Some optimizations that can be made ... Should bgp be used to distribute mcast routes across the backbone? tempting but... ------------------------------------------------------------------------------------------------ Multicast in BGP/MPLS VPNs and VPLS (Rahul Aggarwal, Juniper) draft-raggarwa-l3vpn-mvpn-vpls-mcast-01 Components of 2547 mcast: control plane. PE-CE; PE-PE data plane forwarding Issues raised at last ietf: PE control plane state PE control plane processing load P state Comparison of costs of 2547 unicast vs multicast why multicast doesn't scale as well ... Design objective Optimize bandwidth Packet traverses a given link only once Deliver mcast packets only to interested PEs Deliver customer mcast traffic along optimal paths (support different algorithms to compute the trees) Optimize state: Amount of state and processing to maintain it should not exceed those for unicast. Solution Existing solutions are insufficient This is a work in progress This solution tries to be reusable across L3 and L2 (VPLS) VPN But this presentation is only re l3vpn. Use BGP to do PIM neighbor maintenance Discover MVPN membership via BGP Reliable delivery of C-Join/Prune Allow multiple VPNs to share a single SP MDT ("Aggregate Data Trees") Set up via PIM or P2MP MPLS TE LSPs, or etc. Requires an inner label to demux a particular vpn State in SP network does not grow proportionate to # of vpns. Ingress Replication - has its place. Aims to meet the requirements and have scaling properties similar to 2547 unicast. ------------------------------------------------------------------------------------------ BGP/MPLS IP Multicast VPNs (Seisho Yasukawa, NTT) draft-yasukawa-l3vpn-p2mp-mcast-00 Motivations: Qos, reliable mcast, adequate operation and mgmt Focus on L3 Scalable arch avoid PIM adjacency maintenance avoid suboptimal IP packet distribution Flexible operation Basic model: Adopt BGP/MPLS network model (CE peers with PE, use BGP for membership discovery) Extend bgp for exchange of mcast routing information Proxy-Source/RP model: all PEs act as proxy-source/RP P2MP TE based MDT interconnects PEs BGP Use MDT-SAFI to discover PEs of same vpn ... Characteristics PIM-SM, PIM-SSM supported with same model Multiple topologies of MDT Multi-AS operation ... Open issues Applicability of PIM-DM and PIM-BIDIR Optimize default/data p2mp tree operation ... Next steps Resolve open issue Need wg input Is p2mp te mpls applicable to MVPN? Cooperate with other solution teams to develop a SINGLE solution. --------------------------------------------------------------- Questions on all 3 approach presentations: (???, Cisco): Q for Rahul: We should try to make PIM more efficient. ... Source replication seems to just be moving complexity from core to PEs. PIM join suppression improves scalability. (??? Japan Telecom): ...(minute taker didn't record comment) (Ali Sajassi, Cisco): re data tree and aggregating it. As # of sites goes up, chances of PE receiving packets not interested in goes up. Would like to see a description of this congruency mapping in the draft. Will customer's tree be moved from one aggregate to another? Also, issue re VPLS - treatment of customer data vs customer bridge protocol. (Phil Zeckert???): Need metrics to compare the different costs we are trading off. Suggestion: average bandwidth per tree: if over a particular level, then perhaps give it its own tree. Are we over-engineering now, especially given the rollout rate? (Yakov Rehkter): Re the last comment: It served us well in 2547 to engineer for a large scale! And anyway it will take years to roll out whatever we do now. We should worry only about L3 traffic here. Aggregation: avoid artificial boundaries about what can be aggregated. (Eric Rosen): Yes, keep L2 and L3 separate. Re aggregation toolkit: Easier for equipment vendor, but just passes the buck to the SP to decide what to do. Re Yasukawa proposal: is this just PIM refresh reduction? Making PE a RP brings a lot of complications with it. Also a problem if enterprise has its own PIM infrastructure. (Yakov): The Yasukawa approach is not just PIM refresh reduction; each PE is a separate PIM domain which is very different than the Aggarwal and Rosen approaches. Could extend this scheme to not create MDT until there is data traffic. (???, cisco): For Yasukawa-san: question about putting Joins into bgp? Since Join/Prune are modeled as SAFIs, how will route reflectors handle them? Wants to see more in the draft on this. (??? cisco): Question for Rahul ...(minute taker did not record question) (???): Communications between multicast people and mpls people has not been that great. Will talk mode at mboned BOF this afternoon. The authors of the three proposals agreed to try to work together offline. The meeting was ajourned. From l3vpn-bounces@ietf.org Tue Dec 14 12:54:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26510 for ; Tue, 14 Dec 2004 12:54:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeH13-0000WB-3E for l3vpn-web-archive@ietf.org; Tue, 14 Dec 2004 13:03:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeGj1-00049H-4m; Tue, 14 Dec 2004 12:44:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeGbN-0001k8-Sk for l3vpn@megatron.ietf.org; Tue, 14 Dec 2004 12:36:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24560 for ; Tue, 14 Dec 2004 12:36:43 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeGjQ-0008Hk-KS for l3vpn@ietf.org; Tue, 14 Dec 2004 12:45:06 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iBEHa8sO014464 for ; Tue, 14 Dec 2004 11:36:09 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Dec 2004 23:06:07 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D21073BB2B@ii0015exch002u.iprc.lucent.com> From: "Gorla, Veeranjaneyulu (Veeranjaneyulu)" To: "'l3vpn@ietf.org'" Date: Tue, 14 Dec 2004 23:06:06 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: BGP Decision process on vpnv4 routes when Different Route Disting uishers are used two VRFs of same VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hello ! CISCO "MPLS VPN Architecture" book 10th chapter Fig 10.8 says if you use two different RDs for VRF's located at two PEs of same VPN BPG table contains two paths one with a rd of received one(from PE2) and another with rd of local vrf at PE1 for same route. i.e two enties in bgp vpnv4 table. Question here is why we need to have one more route with local rd prepended in BGP table which is received from another PE Thanks Veer From l3vpn-bounces@ietf.org Tue Dec 14 17:19:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28539 for ; Tue, 14 Dec 2004 17:19:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeL9a-0000mU-Ii for l3vpn-web-archive@ietf.org; Tue, 14 Dec 2004 17:28:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeKxt-0006uF-IX; Tue, 14 Dec 2004 17:16:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeBlR-0004El-P5 for l3vpn@megatron.ietf.org; Tue, 14 Dec 2004 07:26:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18714 for ; Tue, 14 Dec 2004 07:26:46 -0500 (EST) Received: from web210.biz.mail.re2.yahoo.com ([68.142.224.172]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CeBjV-0006Dr-Ua for l3vpn@ietf.org; Tue, 14 Dec 2004 07:24:53 -0500 Message-ID: <20041214121601.1809.qmail@web210.biz.mail.re2.yahoo.com> Received: from [219.238.141.92] by web210.biz.mail.re2.yahoo.com via HTTP; Tue, 14 Dec 2004 04:16:01 PST Date: Tue, 14 Dec 2004 04:16:01 -0800 (PST) From: Joseph Laria To: internet-drafts@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-8481934-1103026561=:1466" X-Spam-Score: 0.0 (/) X-Scan-Signature: a9d67c3f17f3c6e4e04fa40d2f302fe3 X-Mailman-Approved-At: Tue, 14 Dec 2004 17:16:16 -0500 Cc: l3vpn@ietf.org Subject: draft-ietf-l3vpn-vr-mib-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7cba333b42e3309724702706fe1b210b --0-8481934-1103026561=:1466 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Hi, Attached is the latest version of draft-ietf-l3vpn-vr-mib. The Virtual Router MIB is a work item of the Provider Provisioned Virtual Private Networks (L3) Working Group. Title: Virtual Router Management Information Base Using SMIv2 Author(s): Elwin Stelzer, Sam Hancock, Benson Schliesser, Joseph Laria Filename: draft-ietf-l3vpn-vr-mib-03.txt Pages: XX Date: December 2004 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). The changes which have been made include: 1) The references split into normative and informational. 2) Included the new IPR and disclaimer text 3) Added IANA consideration section 4) Minor typos Thanks Joe Laria --0-8481934-1103026561=:1466 Content-Type: text/plain; name="draft-ietf-l3vpn-vr-mib-03.txt" Content-Description: draft-ietf-l3vpn-vr-mib-03.txt Content-Disposition: inline; filename="draft-ietf-l3vpn-vr-mib-03.txt" INTERNET-DRAFT Elwin Stelzer draft-ietf-l3vpn-vr-mib-03.txt Corona Networks, Inc. Expires: May 2005 Sam Hancock ACM Systems Benson Schliesser SAVVIS Communications Joseph Laria Level Stream Research December 2004 Virtual Router Management Information Base Using SMIv2 1.0 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. 2.0 Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). 3.0 Table of Contents 1.0 Status of this Memo 2.0 Abstract Layer-3 VPN Group Expires May 2005 [Page 1] Draft Virtual Router MIB December 2004 3.0 Table of Contents 4.0 Terminology 5.0 Introduction 6.0 The Internet-Standard Management Framework 7.0 Overview of the Virtual Router MIB 7.1 SNMP Contexts for Management for Virtual Routers 7.2 VR Indexing 7.3 Creation and Deletion of VRs 7.4 Administrative and Operational Status of VRs 7.5 Binding interfaces to a VR 7.6 Setting per VR limits 7.7 Per VR Statistics 7.8 Traps 8.0 Sample VR MIB Configuration Scenario 8.1 Creation of a VR 9.0 Definition of the Virtual Router MIB 10.0 Acknowledgments 11.0 Security Considerations 12.0 References 12.1 Normative References 12.2 Informative References 13.0 Authors' Addresses 14.0 Intellectual Property Considerations 15.0 Full Copyright Statement 16.0 IANA Considerations for L3VPN-VR-MIB 4.0 Terminology This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR]. 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, reference [RFC2119]. 5.0 Introduction This memo defines a MIB for the Virtual Router [PPVPN-VR, PPVPN-VR-AS] model of Provider Provisioned VPNs [PPVPN-FW]. Following are the goals, in defining this MIB: - To have a means for Service Providers to provision VPN service for subscribers, at the PE device. - To make the agent-side implementation simple, by not modifying the existing standard MIBs. - Define all the gluing tables that are needed toward this end. Layer-3 VPN Group Expires May 2005 [Page 2] Draft Virtual Router MIB December 2004 6.0 The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 7.0 Overview of the Virtual Router MIB 7.1 SNMP Contexts for Management for Virtual Routers There is a need for a single agent to manage multiple Virtual Routers. The Architecture for describing SNMP Management Frameworks [RFC3411] provides a way to support such cases. Managing multiple virtual routers requires that the PE management plane be subdivided into logical VR management domains. In the VR model of PPVPNs a single PE device may contain many virtual routers. Different management entities SHOULD be able to manage specific virtual routers and associated services. The Service Provider MUST be able to manage all virtual routers and associated services. Using SNMP contexts to group a collection of management information provides the following benefits: (1) Uses a standard framework defined by the IETF, allowing the product to remain flexible to all implementations of virtual router devices. (a) Use SNMPv2c Community String's (b) Use SNMPv3 contextName's (2) Prevents vendors from having to modify the standard MIBs, allowing the implementation to remain standards compliant. (3) Provides a framework that will work for RIP, OSPF, IS-IS, BGP, IP-FORWARDING, MPLS, and any other MIB that can be administratively grouped with a VR. Layer-3 VPN Group Expires May 2005 [Page 3] Draft Virtual Router MIB December 2004 The SNMP context for the Virtual Router instance can be specified in the VrConfigTable. The VrContextName columnar object is used to set the SNMPv2c Community String or the SNMPv3 contextName for a given VR. A virtual router context represents the set of MIB objects that could be administratively grouped within a VR. For example, each VR would maintain its own instance of routing protocol MIB tables. However, the ADMIN context would contain single instances of objects and tables that pertain to system wide configuration such as the Entity, Interfaces, and ATM MIBs. A management system using the SNMP context of a particular virtual router MUST be able to manage the virtual router without disrupting other virtual routers in the same PE device. For example, a PE can be subdivided into two 2 VRs running the OSPF routing protocol. Each VR will maintain a unique instance of the OSPF-MIB. Therefore, the ospfAreaTable of VR-A is distinct from the ospfAreaTable of VR-B. +-----------------------------------------------------------------+ | +------------------------------------------------------------+ | | | SNMP entity (including Engine, Applications) | | | | | | | | example contextNames: | | | | | | | | "vr01" "vr09" "admin" | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context=vr01 | | context=vr09 | | context=admin | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | OSPF MIB | | | | OSPF MIB | | | | VR MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | BGP MIB | | | | BGP MIB | | | | ATM MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | IP MIB | | | | IP MIB | | | | ENTITY MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | other MIB | | | | other MIB | | | | IF MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | ... | | ... | | ... | | | +-----------------------------------------------------------------+ Layer-3 VPN Group Expires May 2005 [Page 4] Draft Virtual Router MIB December 2004 Filtering mechanisms based on the SNMP context of a particular virtual router may implemented to allow different management entities to manage those objects and services provisioned the 'Admin' context. 7.2 VR Indexing While the standard protocol MIB tables are instantiated in the context specified using SNMP contexts, there may be tables that are defined with the VRID as index. The VRID is of local significance to a particular PE device, and need not be globally unique. Thus a particular VRID value assigned to a VR in one PE device may indicate a different VR in another PE device. The VRID has an Unsigned32 value, and this value is assigned by the management station. To aid the management station in assigning a VRID without conflict, the management station can get the 'NextAvailableVRID' from the PE device. A SNMP manager SHOULD NOT assume global significance of any VRID value other than 0. For those MIB tables instantiated in the virtual router context, indexing can only be assumed unique for that particular VR. However those indices in the "ADMIN" context are unique across the entire system, including all VRs. 7.3 Creation and Deletion of VRs The VR Config Table is used for this purpose. This is a read-create table and adding an entry into this table will create a VR. Removing an entry from this table marks the deletion of a VR. VRID 0 is assigned to the Administrative VR, which exists by default, and need not be created. Deletion of the Administrative VR will not be permitted. The VRID of the Administrative VR (VRID 0) should be a reserved VRID number. VRID 0 could be termed the "null VR" and it could be the context that manages the resource pool of unattached interfaces. Routing would then not exist in the context of Administrative VR. 7.4 Administrative and Operational Status of VRs VRs can be administratively turned down. When this is done, no packet forwarding via the VR takes place. VrOperStatus denotes the operational status of a VR. Currently the VrOperStatus is expected to change along the VrAdminStatus unless an error condition exists. Layer-3 VPN Group Expires May 2005 [Page 5] Draft Virtual Router MIB December 2004 7.5 Binding interfaces to a VR Interfaces are bound to a VR, using vrIfConfigTable. This is a read-write table, and note that interfaces are not created through this table. The vrIfConfigTable MIB table is used to indicated the relationship between interfaces and virtual router IDs. For each interface present in the system, this table is used to provide the mapping from IfIndex to a unique VR. The table show which interfaces are ?attached or connected? to a virtual router. An interface can not be attached to more than one VR. The "Admin" VR could be used to manage the resource pool of unattached interfaces. However interfaces would not be attached to VRID 0. 7.6 Setting per VR limits VRs consume resources on a device, and hence the following parameters defined in vrConfigTable are used to specify an upper bound of resource utilization: VrMaxRoutes - Specify the maximum number of routes that will be permitted in VR. This includes all routes, such as the statically configured routes, and the routes learnt via dynamic routing protocols. 7.7 Per VR Statistics In addition to those statistics available through the VR instantiated MIB tables, there are some per-VR statistics available through vrStatTable. 7.8 Traps This memo defines that VrUp and VrDown traps are generated just after VrOperStatus leaves, or just before it enters, the down state, respectively. (1) A transition into the down state will occur when an error is detected on a VR instance. (2) Departing the down state generally indicates that the VR is going to up, which is considered a "healthy" state. An exception to the above generation of VrUp/VrDown traps on changes in VrOperStatus, occurs when an VR is "flapping", i.e., when it is rapidly oscillating between the up and down states. If traps were generated for each such oscillation, the network and the network management system would be flooded with unnecessary traps. In such a situation, the agent should limit the rate at which it generates traps. This memo defines that enabling and disabling the VR traps is achieved by setting the VrTrapEnable to true(1) or false(2), respectively. By default, this object should have the value true(1). Layer-3 VPN Group Expires May 2005 [Page 6] Draft Virtual Router MIB December 2004 8.0 Sample VR MIB Configuration Scenario 8.1 Creation of a VR Creating VR instances can be achieved using the following example. (1) Get the next available Virtual Router Id using the NextAvailableVrId, to create a VR: Using a context with 'read' access for system level entities. GetRequest { NextAvailableVrId.0 } Response { NextAvailableVrId.0 = 5555 } (2) In VrConfigTable, create VR Instance using VrRowStatus: Using a context with 'read-write' access for system level entities SetRequest { VrRowStatus.5555 createAndGo(4), VrName.5555 "BigTelcoVR", VrContextName.5555 "vr5555", VrTrapEnable.5555 true(1), VrAdminStatus.5555 up(1) } 9.0 Definition of the Virtual Router MIB -- -- VIRTUAL-ROUTER-MIB -- VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN IMPORTS InterfaceIndex FROM IF-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- RFC Ed.: VPN-TC-MIB in Last Call in L3VPN WG VPNId FROM VPN-TC-MIB OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF experimental, Unsigned32, OBJECT-TYPE, MODULE-IDENTITY, TimeTicks, NOTIFICATION-TYPE FROM SNMPv2-SMI TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC; virtualRouterMIB MODULE-IDENTITY LAST-UPDATED "200412161200Z" ORGANIZATION "IETF L3VPN WG" CONTACT-INFO Layer-3 VPN Group Expires May 2005 [Page 7] Draft Virtual Router MIB December 2004 " Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3832 Email: elwinietf@yahoo.com Samuel Hancock ACM Systems 3034 Gold Canal Drive Rancho Cordova, CA 95670 USA Phone: +1-916-463-7949 Email: hancoc_s@yahoo.com Benson Schliesser SAVVIS Communications 1 Savvis Parkway Town and Country, MO 63017 USA Phone: +1-314-628-7036 Email: bensons@savvis.net Joseph Laria Level Stream Research Wilmington, MA 01887 USA Phone: +1-978-884-3537 Emain: jlaria@levelstream.com " DESCRIPTION "The MIB is the definition of the managed objects for the Virtual Router." REVISION "200412161200Z" -- 16 December 2004 12:00:00 GMT DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { experimental xxxx } -- To be assigned -- RFC Ed.: replace xxxx with IANA-assigned number & remove this note -- -- Textual conventions -- VrIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Virtual Router Identifier. Layer-3 VPN Group Expires May 2005 [Page 8] Draft Virtual Router MIB December 2004 VRID 0 is reserved for the Administrative VR and cannot be used to create VR's. " SYNTAX Unsigned32 -- -- Node definitions -- vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 } vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 } vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 } vrConfigNextAvailableVrId OBJECT-TYPE SYNTAX VrIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "The next available Virtual Router Id (index). This object provides a hint for the vrID value to use when administratively creating a new vrConfigEntry. A GET of this object returns the next available vrId value to be used to create an entry in the associated vrConfigTable; or zero, if no valid vrId value is available. A value of zero(0) indicates that it is not possible to create a new vrConfigEntry This object also returns a value of zero when it is the lexicographic successor of a varbind presented in an SNMP GETNEXT or GETBULK request, for which circumstance it is assumed that ifIndex allocation is unintended. Successive GETs will typically return different values, thus avoiding collisions among cooperating management clients seeking to create table entries simultaneously. Unless specified otherwise by its MAX-ACCESS and DESCRIPTION clauses, an object of this type is read-only, and a SET of such an object returns a notWritable error." ::= { vrConfigScalars 1 } vrConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF VrConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is for creating the new Virtual Routers." ::= { vrConfig 2 } Layer-3 VPN Group Expires May 2005 [Page 9] Draft Virtual Router MIB December 2004 vrConfigEntry OBJECT-TYPE SYNTAX VrConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries in this table can be added/deleted using the vrRowStatus." INDEX { vrId } ::= { vrConfigTable 1 } VrConfigEntry ::= SEQUENCE { vrId VrIdentifier, vrRowStatus RowStatus, vrName DisplayString, vrContextName DisplayString, vrTrapEnable TruthValue, vrMaxRoutes Unsigned32, vrAdminStatus INTEGER, vrVpnId VPNId, vrRpTrigger Unsigned32 } vrId OBJECT-TYPE SYNTAX VrIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique id of this virtual router instance. A Virtual Router cannot not be created with vrId = 0. VRID 0 is reserved for the Administrative VR. " ::= { vrConfigEntry 1 } vrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status column has three defined values: - `active', which indicates that the conceptual row is available for use by the managed device; Layer-3 VPN Group Expires May 2005 [Page 10] Draft Virtual Router MIB December 2004 - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row." ::= { vrConfigEntry 2 } vrName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The Name of the Virtual Router.. " ::= { vrConfigEntry 3 } vrContextName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The SNMPv2 Community String or SNMPv3 contextName denotes the VR 'context' and is used to logically separate the MIB management." ::= { vrConfigEntry 4 } vrTrapEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This objects is used to enable the generation of the VrUp and VrDown traps. true(1) - VR Traps Enabled false(2) - VR Traps Disabled" DEFVAL { true } ::= { vrConfigEntry 5 } vrMaxRoutes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the maximum number of routes that this VR can support. The default value is 4 Gig (meaning unlimited)." DEFVAL { 4294967295 } ::= { vrConfigEntry 6 } Layer-3 VPN Group Expires May 2005 [Page 11] Draft Virtual Router MIB December 2004 vrAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), testing(3), unknown(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the Virtual Router." DEFVAL { down } ::= { vrConfigEntry 7 } vrVpnId OBJECT-TYPE SYNTAX VPNId MAX-ACCESS read-create STATUS current DESCRIPTION "The Virtual Private Network Identifier of the Virtual Router." ::= { vrConfigEntry 8 } vrRpTrigger OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Routing Protocol Triggers on the Virtual Router. This can be used to initiate or shutdown routing protocols on a VR. The 32 bits are divided into: 16 bits of RP bitmap, 15 bits reserved (0), and 1 bit of action-code. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |RP bitmap (MSB)| +-+-+-+-+-+-+-+-+ |RP bitmap (LSB)| +-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+ |*| Reserved | +-+-+-+-+-+-+-+-+ *=action-code The RP bitmap specify the RP that is to be initiated or Layer-3 VPN Group Expires May 2005 [Page 12] Draft Virtual Router MIB December 2004 shutdown. Multiple RPs can be acted on simultaneously. Also, individual RPs can be brought up in steps, which should not affect the RPs that were running. Action-code specify what needs to be done for the RPs in the RP bitmap. The actions are: initiate or shutdown. The running status of the RP shall be available in the VR stats table's vrRpStatus, which has a similar format, but represent the status." ::= { vrConfigEntry 9 } vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 } vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 } vrConfiguredVRs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRs configured on this network element." ::= { vrStatScalars 1 } vrActiveVRs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRs that are active on the network element. These are VRs for which the vrStatOperationalStatus = up(1)" ::= { vrStatScalars 2 } vrStatTable OBJECT-TYPE SYNTAX SEQUENCE OF VrStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistics for the Virtual Router." ::= { vrStat 2 } vrStatEntry OBJECT-TYPE SYNTAX VrStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table a per vrId." INDEX { vrId } ::= { vrStatTable 1 } VrStatEntry ::= SEQUENCE { Layer-3 VPN Group Expires May 2005 [Page 13] Draft Virtual Router MIB December 2004 vrStatRouteEntries Unsigned32, vrStatFIBEntries Unsigned32, vrStatUpTime TimeTicks, vrOperStatus INTEGER, vrRpStatus Unsigned32, vrRouterAddressType InetAddressType, vrRouterAddress InetAddress } vrStatRouteEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of routes for this VR." ::= { vrStatEntry 1 } vrStatFIBEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of FIB Entries for this VR." ::= { vrStatEntry 2 } vrStatUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time in (in hundredths of a second) since this VR entry has been operational." ::= { vrStatEntry 3 } vrOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state of the Virtual Router." ::= { vrStatEntry 4 } Layer-3 VPN Group Expires May 2005 [Page 14] Draft Virtual Router MIB December 2004 vrRpStatus OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "List of Routing Protocols on this VR." ::= { vrStatEntry 5 } vrRouterAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Router Address Type of this VR." ::= { vrStatEntry 6 } vrRouterAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Router Address of this VR. It is derived from one of the interfaces. If loopback interface is present, the loopback interface address can be used. However, loopback interface is optional." ::= { vrStatEntry 7 } vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 } vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 } vrIfConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF VrIfConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is for configuring VR Interfaces." ::= { vrIfConfig 2 } vrIfConfigEntry OBJECT-TYPE SYNTAX VrIfConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table correspond to the entries in the ifTable that apply to the Virtual Router." INDEX { vrId, vrIfId } ::= { vrIfConfigTable 1 } Layer-3 VPN Group Expires May 2005 [Page 15] Draft Virtual Router MIB December 2004 VrIfConfigEntry ::= SEQUENCE { vrIfId InterfaceIndex, vrIfConfigRowStatus RowStatus } vrIfId OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Virtual Router Interface Index." ::= { vrIfConfigEntry 1 } vrIfConfigRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION " This object is used to create, delete or modify a row in this table." ::= { vrIfConfigEntry 2 } -- ********************************************************************* -- Module Traps/Notifications -- ********************************************************************* vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 } vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 } vrUp NOTIFICATION-TYPE OBJECTS { vrRowStatus } STATUS current DESCRIPTION "This notification is generated when the specified VR is about to initialized or change the status from down to up." ::= { vrNotifications 1 } vrDown NOTIFICATION-TYPE OBJECTS { vrRowStatus } STATUS current DESCRIPTION "This notification is generated when the specified VR is about to go down." ::= { vrNotifications 2 } Layer-3 VPN Group Expires May 2005 [Page 16] Draft Virtual Router MIB December 2004 vrMaxRoutesExceeded NOTIFICATION-TYPE OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries } STATUS current DESCRIPTION "This notification is generated when the specified VR has exceeded the maximum number of routes specified" ::= { vrNotifications 3 } -- ********************************************************************* -- Module Compliance/Conformance Statements -- ********************************************************************* vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 } vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 } vrMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the VIRTUAL-ROUTER-MIB. Implementation of this MIB is strongly recommended for any platform targeted for a carrier-class environment." MODULE -- this module MANDATORY-GROUPS { vrConfigGroup, vrStatGroup, vrIfGroup, vrNotificationGroup } ::= { vrCompliances 1 } vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 } vrConfigGroup OBJECT-GROUP OBJECTS { vrRowStatus, vrName, vrContextName, vrTrapEnable, vrMaxRoutes, vrAdminStatus, vrVpnId, vrRpTrigger, vrConfigNextAvailableVrId } STATUS current DESCRIPTION "A collection of attributes that support provisioning of a virtual router." ::= { vrGroups 1 } vrStatGroup OBJECT-GROUP OBJECTS { vrConfiguredVRs, vrActiveVRs, vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime, vrOperStatus, vrRpStatus, vrRouterAddress, vrRouterAddressType } STATUS current DESCRIPTION "A collection of attributes that contain stats about the virtual router." ::= { vrGroups 2 } Layer-3 VPN Group Expires May 2005 [Page 17] Draft Virtual Router MIB December 2004 vrIfGroup OBJECT-GROUP OBJECTS { vrIfConfigRowStatus } STATUS current DESCRIPTION "A collection of attributes that support provisioning of a virtual router interfaces." ::= { vrGroups 3 } vrNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded } STATUS current DESCRIPTION "A collection of traps that are supported by the VR." ::= { vrGroups 4 } END 10.0 Acknowledgments Special thanks to Joan Cucchiara for providing valuable comments on this MIB. 11.0 Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: The Administrative VR provides visibility into and control over multiple VPNs. As such, security considerations for implementations of the Administrative VR and associated control plane(s) are critical to the security of the VPNs supported on each PE device. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Use of any vrContextName MUST be allowed in the Administrative VR. Additional authentication and security mechanisms SHOULD be used for SNMP access in the Administrative VR. Layer-3 VPN Group Expires May 2005 [Page 18] Draft Virtual Router MIB December 2004 VRs other than the Administrative VR MUST NOT have access to other VR's Instantiated MIBs, and MAY have access to their own instantiated MIBs. In VRs other than the Administrative VR, access to that VR's instantiated MIBs MAY be permitted via that VR's vrContextName. Use of any vrContextName other than that assigned to the accessed VR MUST result in an error, and implementations SHOULD provide a logging mechanism for such events. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 12.0 References 12.1 Normative References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Layer-3 VPN Group Expires May 2005 [Page 19] Draft Virtual Router MIB December 2004 12.2 Informative References [RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [VPNTCMIB] B. Schliesser, and T. Nadeau, "Definition of Textual Conventions for Provider Provisioned Virtual Private Network (PPVPN) Management.", Internet Draft , May 2004. [PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn-framework-00.txt, March 2003. [PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture using Virtual Routers", draft-ietf-l3vpn-vpn-vr-02.txt, April 2004. [PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches", draft-ietf-l3vpn-as-vr-01.txt, February 2004. 13.0 Authors' Addresses Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3832 Email: elwinietf@yahoo.com Samuel Hancock ACM Systems 3034 Gold Canal Drive Rancho Cordova, CA 94123 USA Phone: +1-916-463-7949 Email: hancoc_s@yahoo.com Benson Schliesser SAVVIS Communications 1 Savvis Parkway Town and Country, MO 63017 USA Phone: +1-314-628-7036 Email: bensons@savvis.net Joseph Laria Level Stream Research Wilmington, MA 01887 USA Phone: +1-978-884-3537 Emain: jlaria@levelstream.com Layer-3 VPN Group Expires May 2005 [Page 20] Draft Virtual Router MIB December 2004 14.0 Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and and assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 15.0 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 16.0 IANA Considerations for L3VPN-VR-MIB The IANA is requested to assign { experimental XXXX } to the L3VPN-VR-MIB module specified in this document. Layer-3 VPN Group Expires May 2005 [Page 21] --0-8481934-1103026561=:1466-- From l3vpn-bounces@ietf.org Wed Dec 22 23:53:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20345 for ; Wed, 22 Dec 2004 23:53:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChL8k-00079N-NC for l3vpn-web-archive@ietf.org; Thu, 23 Dec 2004 00:03:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChKxH-0002Mp-Tz; Wed, 22 Dec 2004 23:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChKwv-0002BB-DT for l3vpn@megatron.ietf.org; Wed, 22 Dec 2004 23:51:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20117 for ; Wed, 22 Dec 2004 23:51:38 -0500 (EST) Received: from web25308.mail.ukl.yahoo.com ([217.12.10.80]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ChL6i-00074U-Bf for l3vpn@ietf.org; Thu, 23 Dec 2004 00:01:50 -0500 Received: (qmail 48812 invoked by uid 60001); 23 Dec 2004 04:51:07 -0000 Message-ID: <20041223045107.48810.qmail@web25308.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25308.mail.ukl.yahoo.com via HTTP; Thu, 23 Dec 2004 04:51:07 GMT Date: Thu, 23 Dec 2004 04:51:07 +0000 (GMT) From: John Smith To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit Subject: Adding lo0 to a VRF X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit Hi, Assume a PE (in RFC 2547 context) which has some 3 VRFs defined. Should it be possible (or does this make any sense at all) to add the loopback IP address of this PE router in one of the VRFs? I understand advertising this loopback IP address to other BGP PE routers? But would anyone want to advertise the loopback IP address in the remote PE's VRFs? That is, advertise a loopback IP address as MP_REACH_NLRI with the NLRI as RD:lo0, etc. Thanks, John ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Thu Dec 23 02:22:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13368 for ; Thu, 23 Dec 2004 02:22:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChNSh-00026C-Is for l3vpn-web-archive@ietf.org; Thu, 23 Dec 2004 02:32:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChNCD-0000aJ-Af; Thu, 23 Dec 2004 02:15:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChNB9-0008Qv-To for l3vpn@megatron.ietf.org; Thu, 23 Dec 2004 02:14:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09672 for ; Thu, 23 Dec 2004 02:14:30 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChNKy-0001wU-FL for l3vpn@ietf.org; Thu, 23 Dec 2004 02:24:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Dec 2004 23:19:31 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBN7Dqo9027056; Wed, 22 Dec 2004 23:13:53 -0800 (PST) Received: from [10.10.10.80] (sjc-rraszuk-vpn1.cisco.com [10.25.90.226]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BAB30254; Wed, 22 Dec 2004 23:24:53 -0800 (PST) Message-ID: <41CA7031.5010405@cisco.com> Date: Wed, 22 Dec 2004 23:13:53 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Smith References: <20041223045107.48810.qmail@web25308.mail.ukl.yahoo.com> In-Reply-To: <20041223045107.48810.qmail@web25308.mail.ukl.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: Adding lo0 to a VRF X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Hi John, First you have to separate two things .. One is the interface assignment to the vrf handling and the other IP address scope and IP address reuse. In most implementations of 2547 I am aware of an interface can belong to only one vrf. So if your lo0 is already part of global table (aka VRF_0) you can't simply put it under any other vrf. Now reg the IP address reuse ... sure. You can define the same IP address as for yr global loopback and configure it under some new loX interface then assign this new interface into a vrf. If you red connected it will get advertised with the format RD:IP_address_of_yr_loX. Cheers, R. > John Smith wrote: > > Hi, > > Assume a PE (in RFC 2547 context) which has some 3 VRFs defined. Should it be possible > (or does this make any sense at all) to add the loopback IP address of this PE router in > one of the VRFs? > > I understand advertising this loopback IP address to other BGP PE routers? But would > anyone want to advertise the loopback IP address in the remote PE's VRFs? That is, > advertise a loopback IP address as MP_REACH_NLRI with the NLRI as RD:lo0, etc. > > Thanks, > John > > > > > > ___________________________________________________________ > ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com > From l3vpn-bounces@ietf.org Tue Dec 28 10:23:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04010 for ; Tue, 28 Dec 2004 10:23:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjJN2-00051g-74 for l3vpn-web-archive@ietf.org; Tue, 28 Dec 2004 10:34:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjJAT-0005qe-Kp; Tue, 28 Dec 2004 10:21:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjIzl-0001XC-Cj for l3vpn@megatron.ietf.org; Tue, 28 Dec 2004 10:10:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02295 for ; Tue, 28 Dec 2004 10:10:42 -0500 (EST) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjJAg-0004ij-C6 for l3vpn@ietf.org; Tue, 28 Dec 2004 10:22:03 -0500 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Dec 2004 15:10:12 +0000 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Dec 2004 10:10:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Dec 2004 10:10:09 -0500 Message-ID: <1E8ACF422ADD1A458AAFFAD2E6FF70C8011EDE76@proton.jnpr.net> Thread-Topic: draft-ietf-l3vpn-vr-mib-03.txt Thread-Index: AcTiKxggm0W2oQHARwCAlLFu7NyK1gKwOvPA From: "Ronald Bonica" To: "Joseph Laria" , X-OriginalArrivalTime: 28 Dec 2004 15:10:11.0230 (UTC) FILETIME=[534FE3E0:01C4ECEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-l3vpn-vr-mib-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Joe, The following are a few questions/comments on the vr-mib draft: 1) The draft is based upon the premise that a single SNMP agent should represent every virtual router on a physical router. An alternative approach would be to deploy a separate SNMP agent for each virtual router. Have you explored that option? If so, why did you reject it? Had you chosen that option, would a vr-mib be required at all? (I honestly don't know which alternative is better. I'm just checking to see that the alternative was explored.) 2) The vr-mib goes to some length the support configuration using SNMP. Other MIBs tend to be for monitoring purposes, with an occasional read-write variable. Do you see this MIB being used much for configuration? 3) The document has a few formatting problems (e.g., section numbering). Please see http://www.ietf.org/ID-Checklist.html /speaking as individual contributor Ron From l3vpn-bounces@ietf.org Wed Dec 29 09:59:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14280 for ; Wed, 29 Dec 2004 09:59:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjfT8-0000mb-8Q for l3vpn-web-archive@ietf.org; Wed, 29 Dec 2004 10:10:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjf9k-0002Dg-KU; Wed, 29 Dec 2004 09:50:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjezW-0008Up-64 for l3vpn@megatron.ietf.org; Wed, 29 Dec 2004 09:39:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12382 for ; Wed, 29 Dec 2004 09:39:56 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjfAd-0000Db-OW for l3vpn@ietf.org; Wed, 29 Dec 2004 09:51:29 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 29 Dec 2004 06:39:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iBTEdMRL004702; Wed, 29 Dec 2004 06:39:23 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-54.cisco.com [10.86.240.54]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANZ66146; Wed, 29 Dec 2004 09:39:21 -0500 (EST) In-Reply-To: <1E8ACF422ADD1A458AAFFAD2E6FF70C8011EDE76@proton.jnpr.net> References: <1E8ACF422ADD1A458AAFFAD2E6FF70C8011EDE76@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D96878E-59A7-11D9-B705-000D93AD480A@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Wed, 29 Dec 2004 09:39:21 -0500 To: "Ronald Bonica" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Joseph Laria , l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-vr-mib-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On Dec 28, 2004, at 10:10 AM, Ronald Bonica wrote: > Joe, > > The following are a few questions/comments on the vr-mib draft: > > 1) The draft is based upon the premise that a single SNMP agent should > represent every virtual router on a physical router. An alternative > approach would be to deploy a separate SNMP agent for each virtual > router. Have you explored that option? If so, why did you reject it? > Had > you chosen that option, would a vr-mib be required at all? > > (I honestly don't know which alternative is better. I'm just checking > to > see that the alternative was explored.) This is in fact one very possible approach. For example, assign multiple IP addresses to different SNMP master agents on a box (or have the same one just be virtualized using the same process, but understand multiple destination IP address-> VR mapping). --Tom > 2) The vr-mib goes to some length the support configuration using SNMP. > Other MIBs tend to be for monitoring purposes, with an occasional > read-write variable. Do you see this MIB being used much for > configuration? > > 3) The document has a few formatting problems (e.g., section > numbering). > Please see http://www.ietf.org/ID-Checklist.html > > /speaking as individual contributor > Ron >