idnits 2.17.00 (12 Aug 2021) /tmp/idnits51191/draft-squire-ppvpn-vpn-discovery-reqts-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 115: '... - It MUST support inter-provider...' RFC 2119 keyword, line 116: '... - It MUST be possible to deplo...' RFC 2119 keyword, line 119: '... - It MUST respond to VPN members...' RFC 2119 keyword, line 121: '... - It SHOULD limit VPN informatio...' RFC 2119 keyword, line 123: '... - It MUST provide VPN endpoint i...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 116 has weird spacing: '...ossible to de...' == Line 168 has weird spacing: '... that may ...' -- 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 (May 2002) is 7311 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? '1' on line 17 looks like a reference -- Missing reference section? 'MARTINISIG' on line 196 looks like a reference -- Missing reference section? 'RFC2026' on line 187 looks like a reference -- Missing reference section? 'RFC2547' on line 190 looks like a reference -- Missing reference section? 'RFC2917' on line 193 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft 4 Document: draft-squire-ppvpn-vpn-discovery-reqts-00.txt 6 Matt Squire 7 Hatteras Networks 9 November 2001 Expires May 2002 11 VPN Discovery Discussions and Options 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 VPNs are a common service being offered by providers. The PPVPN WG 34 is tasked with defining a limited number of solutions to support the 35 interoperable deployment of VPN services. As part of this effort, a 36 design team was tasked with defining the requirements of PPVPN 37 discovery proposals, to analyze if additional discovery schemes are 38 needed, and to characterize potential solutions to the problem. 39 This draft is the output of that design work. Consensus was not 40 reached on the solution characteristics. However, this draft 41 attempts to capture the discussions and positions of the design team 42 exchanges. 44 1 Introduction 46 VPNs come in many shapes and sizes. In [MARTINISIG], as an example, 47 an emulated VC consists of two LSPs (Label Switched Paths), one in 48 each direction. Each endpoint initiates the setup of the LSP that 49 carries packets in the "incoming" direction. In order for the 50 signaling to proceed, each endpoint has apriori knowledge of 51 (a) the address of the other endpoint, and 52 (b) a VC id. 54 draft-squire-ppvpn-vpn-discovery-reqts-00.txt September 2001 56 On a given emulated VC, the same VC id must be used for both LSPs. 58 In this context, "apriori knowledge" simply means information that 59 must be known prior to the initiation of signaling. The draft 60 [MARTINISIG] provides one example of how to use signaling in 61 establishing a VPN. The information required as apriori knowledge 62 may differ depending on the signaling protocol and assumptions. 64 In the context of PPVPN, discovery is the process by which a PE 65 learns the required apriori knowledge. 67 1.1 Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 70 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 71 this document are to be interpreted as described in RFC 2119. 73 2 Necessity of a Solution 75 There are currently two proposals for performing VPN endpoint 76 discovery. The two methods can be characterized as BGP and 77 multicast. RFC 2547 (and related work) define mechanisms to use BGP 78 multi-protocol extensions to include VPN information in the BGP 79 routing information. Discovering which PE equipment is in which 80 VPNs can then be determined by querying the routing tables. 82 RFC 2917 defines how multicast can be used to discover VPN 83 membership. Each VPN is assigned a specific multicast address. 84 This address implicitly defines a communication channel to all VPN 85 members over which members can determine the unicast address of 86 other PE equipment in that VPN. 88 Current PPVPN discovery methods have been developed as part of 89 particular deployment solutions. The BGP and multicast approaches 90 introduced above were specifically developed for discovery of L3VPNs 91 in BGP or multicast enabled networks. Most members of the design 92 team believe that there are contexts where additional discovery 93 mechanisms are needed. Some members are firmly opposed to this 94 belief. 96 PPVPN discovery is only one part of the PPVPN solution. As there 97 are currently multiple models and architectures for PPVPN solutions, 98 including virtual routers, overlay L3 networks, Layer2 VPNS, etc., 99 one must consider particular discovery solutions in the context of 100 the PPVPN architectures for which they are intended. 102 3 Requirements 104 There was consensus from the design team on many requirements for a 105 VPN discovery protocol. However, there was contention over the 106 exact interpretation of the requirements. This following list 107 summarizes the requirements while later subsections discuss where 108 these requirements are in dispute. 110 draft-squire-ppvpn-vpn-discovery-reqts-00.txt September 2001 112 Any VPN discovery process or protocol must satisfy the following 113 requirements. 115 - It MUST support inter-provider VPNs. 116 - It MUST be possible to deploy the auto-discovery scheme in a 117 manner which prevents unauthorized access and allows 118 authentication of the source 119 - It MUST respond to VPN membership changes in a timely fashion 120 (see 3.1) 121 - It SHOULD limit VPN information to only those PEs involved in 122 that VPN. 123 - It MUST provide VPN endpoint information consisting of at last 124 the IP address of associated PE equipment, and MAY be 125 extendible to provide additional information (see 3.2). 127 3.1 Timely Fasion 129 The responsiveness of VPN discovery to membership changes is hotly 130 contested. Although faster is always better, the main question is 131 how fast is fast enough? When a PE is added to a VPN (or deleted 132 for that matter), how quickly must the other PE equipment in that 133 VPN notice the change? 135 The two positions put forward by the design team and captured by 136 this document are rougly: 137 a) "Routing" time frame. 138 b) "Provisioning" time frame. 140 This document does not attempt to exactly quantify the two 141 possibilities. However, it should be clear that (a) is a more 142 stringent requirement than (b). As a rough quantification, (a) is 143 usually measured in seconds, while (b) is measured in minutes. 145 3.2 Extended Discovery or Signaling 147 There are two different ways of viewing the VPN discovery process. 148 It could be viewed as a limited process where each member learns 149 enough about other members of the VPN to complete VPN signaling. 150 Alternatively it could be viewed as this limited process, plus the 151 VPN signaling. 153 The VPN signaling is required to exchange parameters of a more or 154 less dynamic nature, e.g. information used to dynamically distribute 155 MPLS labels set up LSP tunnels and VC LSP's. 157 The point of contention centers on the boundary between discovery 158 and signaling. It is clear that, at a minimum, each PE device must 159 know the IP address of other PE devices that serve a VPN. The 160 question then becomes whether the IP address enough information. 161 The two conflicting positions are 163 draft-squire-ppvpn-vpn-discovery-reqts-00.txt September 2001 165 a) Yes. All additional information should be exchanged via the 166 signaling protocol. 167 b) No. It should be required to support additional information 168 that may be a prequesite for signaling. 169 It is clear that the initialization process must be extensible to 170 new parameters and features, the question lies in where those 171 parameters are added. 173 4 Conclusion 175 Being an IETF design team, we have realized our responsibility to 176 not reach consensus. 178 The design team was able to reach consensus on some of the VPN 179 discovery requirements. These are described in Section 3. However, 180 there was intense contention on several key issues as described 181 outlined in Sections 3.1 thru 3.2. As a result, we can conclude 182 that any one PPVPN discovery solution is unlikely to satisfy all 183 providers, developers, and scenarios. 185 5 Referenc 187 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 188 3", BCP 9, RFC 2026, October 1996. 190 [RFC2547] E. Rosen & Y. Rekhter, "BGP/MPLS VPNs," RFC 2547, March 191 1999. 193 [RFC2917] K. Muthukrishnan & A. Malis, "A Core IP MPLS VPN 194 Architecture," RFC 2917, September 2000. 196 [MARTINISIG] L. Martini, et al., "Transport of Layer 2 Frames over 197 MPLS," draft-martini-l2circuit-trans-mpls-08.txt, Work in 198 Progress. 200 6 Acknowledgments 202 This draft is the result of collaborative effort of the PPVPN 203 discovery design team. The members of that design team are: 205 Loa Andersson (Utfors) 206 Ron Bonica (MCI) 207 Juha Heinanen (Song Networks) 208 Jim Luciani (Crescent Networks) 209 Dave McDysan (WorldCom) 210 Dave Meyer (Sprint) 211 Hamid Ould-Brahim (Nortel Networks) 212 Yakov Rekhter (Juniper Networks) 213 Eric Rosen (Cisco) 214 Tissa Senevirathne (Force 10 Networks) 215 Matt Squire (Hatteras Networks) 217 draft-squire-ppvpn-vpn-discovery-reqts-00.txt September 2001 219 All members made valuable contributions to this effort. 221 7 Author's Addresses 223 Matt Squire 224 Hatteras Networks 225 639 Davis Drive 226 Research Triangle Park, NC 27709 227 Email: msquire@hatterasnetworks.com