idnits 2.17.1 draft-bensons-ppvpn-tunnel-metric-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 174 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 27 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7979 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 2119' on line 53 looks like a reference -- Missing reference section? 'PPVPN-VR' on line 56 looks like a reference -- Missing reference section? 'PPVPN-FW' on line 56 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Benson Schliesser 2 draft-bensons-ppvpn-tunnel-metric-00.txt SAVVIS Communications 3 Expires: December 2002 5 June 2002 7 Tunnel Interface Metric Determination for Virtual Routers 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 In the Virtual Router (VR) model of Provider Provisioned VPNs 32 multiple VRs may be connected using tunnels over an existing IP 33 network, such as IPSec or MPLS based tunnels. In the VR model 34 these tunnels often run routing protocols such as RIP or OSPF in 35 order to distribute route reachability information. This memo 36 presents methods for assigning a meaningful metric to these tunnel 37 links that can be used by such routing protocols. 39 Table of Contents 41 1. Introduction 42 2. Tunnel Metric Determination 43 2.1. Tunnel Interface Default Metric 44 2.2. Administratively Assigned Metric 45 2.3. Underlying Path Metric 46 3. Security Considerations 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in [RFC 2119]. 54 1. Introduction 56 In the VR model [PPVPN-VR] of PPVPNs [PPVPN-FW], tunnels can be used 57 to connect VR instances on PE and/or P nodes. By default, these tunnels 58 are often assigned a metric which fails to represent the metric of the 59 underlying path the tunnel takes. This often leads to inaccurate 60 routing topologies represented in VR route tables. In mesh topologies 61 this also leads to myriad equal-cost multipaths. This document 62 describes some methods available for tunnel metric determination in 63 VR-based PPVPN implementations. 65 2. Tunnel Metric Determination 67 2.1. Tunnel Interface Default Metric 69 A VR-based PPVPN may use the default metric of a tunnel interface. This 70 metric is generally a metric of one (1), but may vary based on the type 71 of tunnel being used. This is likely supported on most, if not all, VR 72 implementations. However, the default metric is the source of the issues 73 outlined in Section 1 of this document. 75 2.2. Administratively Assigned Metric 77 A VR-based PPVPN may use an adminstratively assigned metric for 78 tunnel interfaces. This method will allow the administrator to design 79 a routing topology that will almost certainly behave in the manner 80 desired and prescribed. 82 Implementations which make use of this method MUST have the ability 83 to assign a specific metric to any tunnel interface which is known 84 to exist, such as an interface for a tunnel which has been 85 administratively created. Implementations which make use of this method 86 SHOULD also provide a mechanism for administratively assigning metrics 87 to tunnel interfaces which are dynamically created. This includes tunnel 88 interfaces which were created as a result of a VPN membership discovery 89 protocol. Such a mechanism MAY make use of filters, algorithms, or other 90 administrative controls to determine the appropriate metric for a 91 dynamically created tunnel. 93 2.3. Underlying Path Metric 95 A VR-based PPVPN may use the metric of the underlying path as the metric 96 for the tunnel link. If a routing protocol is being used in the network 97 underlying the tunnels' connectivity, to distribute reachability 98 information associated with meaningful metrics, the metric associated 99 with the remote endpoint of a tunnel link may be used as the interface 100 metric for the tunnel. Or if the tunnel type allows for determination 101 of hop-count or other similar data such data may be used as the interface 102 metric for the tunnel. This metric may be used by routing protocol 103 instances that may run over the tunnel, or for any other similar purposes. 105 It should be noted that some underlying routing architectures may have 106 underlying path metrics that are not meaningfully useful in their native 107 state to the VR routing protocol being used. For these cases, 108 implementations SHOULD provide a mechanism for the underlying path 109 metric to be adjusted and bounded according to administrative logic such 110 as filters, algorithms, or other administrative controls before it is 111 assigned to the tunnel interface. 113 Because the underlying path metric may be subject to change, as the 114 underlying network itself changes topology, metric change dampening 115 functionality MAY be included in the administrative logic mechanisms 116 mentioned above. 118 3. Security Considerations 120 In each of the cases above where administrative logic can be applied 121 to tunnel link metrics, appropriate precautions must be taken to protect 122 the administration of said logic against malicious users. This 123 administrative logic could be used by a malicious user to redirect VPN 124 traffic through a compromised path or node. 126 Acknowledgements 128 Thanks to Jason Brown of SAVVIS Communications for his contributions to 129 this document. 131 Author's Address 133 Benson Schliesser 134 SAVVIS Communications 135 717 Office Parkway 136 St. Louis, MO 63141 USA 137 bensons@savvis.net 138 +1-314-468-7036 140 Full Copyright Statement 142 Copyright (C) The Internet Society (2001). All Rights Reserved. This 143 document and translations of it may be copied and furnished to 144 others, and derivative works that comment on or otherwise explain it 145 or assist in its implementation may be prepared, copied, published 146 and distributed, in whole or in part, without restriction of any 147 kind, provided that the above copyright notice and this paragraph 148 are included on all such copies and derivative works. However, this 149 document itself may not be modified in any way, such as by removing 150 the copyright notice or references to the Internet Society or other 151 Internet organizations, except as needed for the purpose of 152 developing Internet standards in which case the procedures for 153 copyrights defined in the Internet Standards process must be 154 followed, or as required to translate it into languages other than 155 English. 156 The limited permissions granted above are perpetual and will not be 157 revoked by the Internet Society or its successors or assigns.