Network Working Group Tissa Senevirathne Internet Draft (Force10) Document: draft-tsenevir-8021qospf-01.txt Paul Billinghurst Category: Informational (Extreme) July 2001 Distribution of Layer 2 VPN Membership and Configuration information using OSPF Opaque LSAs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document presents the use of OSPF opaque LSAs to distribute Network Based Layer 2 VPN membership and configuration information across an Autonomous System. The distributed Layer 2 VPN information MAY be used later to construct Back-end Layer 2 VPN tunnels. Senevirathne Informational - January 2002 1 draft-tsenevir-8021qospf-01.txt July 2001 Table of Content 1. Conventions used in this document..................................2 2. Introduction.......................................................2 3. Opaque LSA overview................................................3 3.1 Opaque LSA Types and VLAN flooding Scope..........................4 4. VLAN LSA ID........................................................5 5. VLAN distribution TLV format.......................................5 6. Top Level TLV definitions..........................................6 6.1. Domain ID TLV....................................................6 6.2. Router ID TLV....................................................7 6.3 BPDU TAG TLV...........................Error! Bookmark not defined. 6.4 VLAN Distribution TLV.............................................8 6.4.1 Top level VLAN Distribution TLV format..........................8 6.4.2 VLAN sub-TLV format.............................................9 6.4.3 Scope Label Sub-TLV............................................10 6.4.4. Service Sub-TLV...............................................10 6.4.5 Encoding of the VLAN sub TLV...................................11 7. Global Service TLV................................................11 7.1 Global Service TLV format........................................11 7.2 Global Service TLV sub-Types.....................................12 8. Encoding of Top Level TLVs........................................12 9. Processing of the VLAN Distribution LSA...........................13 10. Security Considerations..........................................13 11. References.......................................................13 12. Acknowledgments..................................................14 13. Author's Addresses...............................................15 Full Copyright Statement.............................................16 1. Conventions used in this document 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 [2]. 2. Introduction There are several discussions and papers published on transporting layer 2 traffic over MPLS networks. An MPLS label defines the forwarding of the packet as opposed to Network Layer information in classical routing. Label based forwarding of Layer 3 packets has lead to the popularity of MPLS in transporting non IP data over IP networks. In this scenario the IP network layer is merely the control plane used to establish the label switched data path. Recently published papers on transportation of layer 2 traffic across MPLS networks such as [3], assume static configuration of specified layer 2 information such as VLANs and end router information. With large layer 2 networks, such static configuration leads to administrative burden. This paper presents a dynamic method for distributing and maintaining VLAN information within an autonomous system. Senevirathne Informational - January 2002 2 draft-tsenevir-8021qospf-01.txt July 2001 Within a given autonomous system it is anticipated there will be multiple Layer 2 VPN domains. The term "domains" is used in [4]to describe VLAN topologies which are mutually exclusive within a defined autonomous system. To reflect this, [5] has defined Layer 2 NBVN Domain Identifier Distributed Layer 2 VPN configuration information, such as VLAN, are interpreted within the scope of a "Layer 2 NBVPN Domain". This paper utilizes Opaque LSAs defined in [6] to distribute the required Layer 2 VPN information. The Layer 2 VPN discovery information is divided in to three main areas; end-point information, configuration information and Service information. Opaque LSAs provide the necessary flexibility to allow the required information to be transmitted within their payload. Opaque LSAs define 3 different distribution scopes. These distribution scopes are ideally suited to distribute VLAN information, either locally, within an area or throughout an entire autonomous system. 3 Layer 2 VPN discovery Information 3.1 Membership information Membership of Layer 2 VPN are the end-points of the Layer 2 VPN. The membership of the Layer 2 VPN is defined per Layer 2 NBVPN Domain. 3.2 Configuration information Configuration information specified are the VLAN and other Layer 2 information required to provide a Layer 2 VPN service. These configuration information are defined per Layer 2 NBVPN Domain. 3.3 Service Information Service information specifies the optional service requirements. 4. Opaque LSA overview Opaque LSAs were introduced in [6] as a means of distributing additional information using the OSPF protocol. Opaque LSAs were designed such that the payload of the LSA could contain information that has meaning only within a certain application. The scope of the application is defined by the Opaque Type. The Opaque LSA header layout is detailed below. Note fields not discussed are used as specified in [6] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10 or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Senevirathne Informational - January 2002 3 draft-tsenevir-8021qospf-01.txt July 2001 | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Pay Load | + + | ... | Opaque Type Defines that this LSA is carrying VLAN distribution information. Opaque ID A unique 24 bit number that identifies this LSA instance Pay Load Contain VLAN distribution information in Type/Length/Value (TLV) format. 4.1 Opaque LSA Types and VLAN flooding scope Three types of Opaque LSA have been defined. Each type has a different flooding scope. Based on administrative requirements, different LSA types may be used to distribute VLAN and service information. Based either on application or administrative requirements it may be necessary to flood VLAN information across the entire autonomous system, within a single area or just to the local subnet. To achieve this we propose a locally configurable parameter "VLAN flooding scope". Each VLAN entry or range of entries may have its own flooding scope. In another words "VLAN flooding scope" is not a system wide configuration but a per VFEC[3] definition. Accordingly we define three VLAN flooding scopes as below: Local Scope LSA Type 9 is chosen for this. LSAs of type 9 are flooded only within the local sub-network. Thus all VLAN (VFEC) information that is to be restricted to the local subnet needs to be configured with a VLAN flooding scope of Local Scope. Area Scope Senevirathne Informational - January 2002 4 draft-tsenevir-8021qospf-01.txt July 2001 LSA Type 10 is chosen for this. LSAs of type 10 are flooded throughout the local area. Thus all VLAN (VFEC) information that is to be restricted to the local area needs to be configured with a VLAN flooding scope of Area Scope. Global Scope LSA Type 11 is chosen for this. LSA of type 11 are flooded throughout the entire autonomous system. Thus all VLAN (VFEC) information that is required to be available throughout the entire autonomous system must be configured with a VLAN flooding scope of Global Scope. Stub Areas and Not So-Stubby Areas (NSSA) LSAs of Type 11 are not flooded to stub areas or NSSAs[6]. Hence special note should be taken when VLAN reachability is required to devices which reside in these area types. Devices within these areas should be statically configured with the required VFEC reachability information. 5. L2VPN LSA ID [6] Defines LSA ID as 8 bits for the Opaque Type and 24 bits for the Opaque ID. Opaque IDs 0-127 are already allocated or reserved by IANA. Values 128-255 are available for private or experimental usage. At present we suggest use of Opaque Type 129 for the distribution of Layer 2 VPN information. However, if this proposal is accepted an application for a dedicated Opaque Type for the Layer 2 VPN distribution LSA should be applied for. The 24 bits of Opaque ID is the VLAN distribution instance. This number is assigned by the originating router and unique within the context of that router. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opaque Type | L2VPN distribution instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Opaque Type Identifies the VLAN distribution LSA. Suggested value is 129. L2VPN distribution instance A 24-bit number assigned by the originating router. Unique within the originating router. 6. Layer 2 VPN distribution TLV format Senevirathne Informational - January 2002 5 draft-tsenevir-8021qospf-01.txt July 2001 The L2 VPN Distribution LSA payload is defined in the form of TLV. This is flexible enough to facilitate the introduction of new information as required. In addition the format detailed below allows nested TLVs and the ability to define sub TLVs 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value.. ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Defines VLAN information TLVs (NOTE: These TLV values are independent of the Opaque Type) Length Length of the value field in bytes. Value Value of the TLV. The Value field is padded with zeros to the nearest 32 bit boundary. As an example, a 3 byte long Value field has a Length field of 3 and the last byte of the Value field is padded with zero. 7. Top Level TLV definitions There are several TLV defined at the top level. Some of these TLVs are defined to possibly carry sub-TLVs. Domain ID TLV Mandatory Router ID TLV Mandatory Layer 2 VPN Distribution TLV Mandatory Global Service TLV Optional 7.1. Layer 2 NBVPN Domain ID TLV Unlike IP addresses, Layer 2 configurations such as VLAN allocation is entirely a local policy and there is no global scope for a given Layer 2 parameter. For example, router A and B can both have same VLAN V but they may not necessarily communicate or be related. To resolve this ambiguity, we define a Layer 2 NBVPN Domain. VLANs within a given Layer 2 NBVPN Domain scope are related. VLANs in different VLAN domains are considered mutually exclusive. Senevirathne Informational - January 2002 6 draft-tsenevir-8021qospf-01.txt July 2001 We define the Layer 2 NBVPN Domain ID TLV to carry Layer 2 NBVPN domain information. The Layer 2 NBVPN Domain ID is statically configured. It is assumed that there is an understanding of the Domain ID values between network administrators responsible for each Layer 2 NBVPN domain when allocating Domain IDs. The assignment of domain IDs is entirely an administrative matter and considered beyond the scope of this discussion. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Domain ID Type = 1 Length Length of the Domain ID - 4 bytes Domain ID A 32-bit number that defines the scope of Layer 2 NBVPN domain 7.2. Router ID TLV The Router ID TLV advertises the router ID of the originating router. Other routers may use this as the end point IP address to construct Layer 2 VPN tunnels for this Domain (Layer 2 VPN). Hence it may be advisable to select the router ID based on a loopback interface, instead of an interface IP address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID - IPV4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type IP V4 Router ID = 2 Length Length of the Router ID field - 4 bytes Senevirathne Informational - January 2002 7 draft-tsenevir-8021qospf-01.txt July 2001 Router ID End point router IP V4 address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID - IPV6 | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type IP V6 Router ID = 3 Length Length of the Router ID field - 12 bytes Router ID End point router IP V6 address 7.4 Layer 2 VPN configuration Distribution TLV Layer 2 VPN configuration distribution TLV is the top level TLV that distributes several sub-TLVs that contain Layer 2 VPN specific information. There are three sub-TLVs defined beneath the top level VLAN distribution TLV; VLAN TLV Mandatory Scope Label TLV Optional Service TLV Optional 7.4.1 Top level Layer 2 VPN configuration Distribution TLV format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Senevirathne Informational - January 2002 8 draft-tsenevir-8021qospf-01.txt July 2001 | Type = 5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value.. ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Top Level VLAN distribution TLV = 5 Length Length of the value field in bytes. Value Value of the TLV. This contains all the sub TLVs. All sub-TLVs are 32-bit aligned and hence the value field of this TLV is a multiple of 32-bits as well. 7.4.2 VLAN sub-TLV format VLAN sub-TLVs distribute VFEC entries; the distribution scope is defined by the Domain ID TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved| F | Start VLAN TAG | End VLAN TAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type VLAN sub-TLV = 1 Length Length of this TLV - 8 bytes M Matching Criteria. Conservative matching if M == 1 else Liberal matching. See [3] for definition of Liberal and conservative matching. Reserved Senevirathne Informational - January 2002 9 draft-tsenevir-8021qospf-01.txt July 2001 All reserved fields are set to zero on transmission and ignored on receipt. 7.4.3 Scope Label Sub-TLV Scope Label TLV distributes a locally significant label, which could be used as a hidden label[7]. The Scope Label, may be used to provide a wider forwarding scope on top of the standard MPLS label, or as a de-mux agent when sharing a LSP. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Scope Label Sub-TLV = 2 Length Length of this TLV - 4 bytes Reserved Set to zero on transmission and ignored on reception. Label Hidden Label. 24 bit MPLS label. 7.4.4. Service Sub-TLV Service Sub-TLV defines various services offered in this VLAN or group of VLANs. These services are specific to the corresponding VLAN(s) and supercede equivalent Domain Services if they exist or are specified (See below). Sub-TLV types 3 through 7 are allocated for "VLAN Services". Specifics regarding actual services are considered beyond the scope of this discussion. The purpose of this TLV is to provide a framework to allow distribution of such services. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3 - 7 | Length | Senevirathne Informational - January 2002 10 draft-tsenevir-8021qospf-01.txt July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value.. ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Service Sub-TLV presently 3 to 7 Length Length of the Service Sub_TLV value Value Value of this TLV TBD 7.4.5 Encoding of the Layer 2 VPN configuration distribution sub TLV Encoding of nested sub-TLVs within the Layer 2 VPN configuration distribution TLV should conform to the following sequence. There must be at least one or more VLAN sub-TLV. Corresponding Scope Label TLVs, if present, should immediately follow the VLAN sub-TLV. If the values of a Scope Label TLV meet the requirements of more than one VLAN sub-TLV, a single Scope Label TLV should appear after all corresponding VLAN sub-TLVs. Service sub-TLV, if present should follow the Scope Label TLV. Service sub-TLV should follow the VLAN sub-TLV(s), if a Scope Label TLV is not present. Presence of a new VLAN sub TLV ends the scope of the Service and Scope Label sub-TLVs. It is possible that a VLAN sub-TLV does not have an associated Scope Label TLV and Service sub-TLVs. In this case the VLAN sub-TLV must be encoded after all VLAN sub-TLVs with Scope and/or Service TLVs have been encoded. 8. Global Service TLV Global Service TLV allows the advertisement of various domain wide services. The types of service advertised are implementation specific and beyond the scope of this document. However the following nested TLV format with separate sub-TLVs for each service or class of service is proposed. 8.1 Global Service TLV format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Senevirathne Informational - January 2002 11 draft-tsenevir-8021qospf-01.txt July 2001 | Type = 6 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value.. ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Global Service TLV = 6 Length Length of the Global service TLV Value Contains nested sub-TLVs 8.2 Global Service TLV sub-Types Allocation and definition of Global Service sub-Types are open to discussion. At this point sub-Types 0-255 are reserved for private and experimental usage. However, if this proposal is accepted, it is suggested that values 0-127 are reserved for IANA allocation of well know services and 128-255 are for private and experimental usage. 9. Encoding of Top Level TLVs The first TLV in the Layer 2 VPN distribution LSA payload MUST be the Router ID TLV. Otherwise it is considered an erroneous TLV and MUST be silently discarded. The Domain ID TLV defines the scope of the Layer 2 VPN. It MUST be present and MUST immediately follow the Router ID TLV. There MUST be at least one Layer 2 VPN configuration Distribution TLV. The VLAN Distribution TLV must immediately follow the BPDU TLV, if present, or Domain ID TLV if the BPDU TLV is not present. If present, the Scope Label TLV MUST immediately follow the VLAN Distribution TLV. If present, the Global Service TLV MUST immediately follow the Scope Label TLV. If the Scope Label TLV is not present, the Global Service TLV MUST immediately follow the VLAN Distribution TLV. Senevirathne Informational - January 2002 12 draft-tsenevir-8021qospf-01.txt July 2001 Within a given Layer 2 VPN Distribution LSA only information relating to a Layer 2 NBVPN domain may be encoded. Separate Layer 2 VPN Distribution LSAs MUST be generated for each Layer 2 NBVPNdomain. Each of these LSAs has a unique Layer 2 VPN distribution instance (see section 5). Any Layer 2 VPN configuration Distribution LSA that violates the above rules MUST be silently discarded. They SHOULD not be flooded except where qualified specifically. At this point, it is suggested that only information relating to a single Layer 2 NBVPNdomain is included in a single LSA. However there is nothing in the TLV architecture presented here which prevents multiple Layer 2 NBVPNDomain encoding within a single LSA. Exact format for the Layer 2 NBVPNdistribution LSA is open for discussion. 10. Processing of the Layer 2 VPN Configuration Distribution LSA Only Layer 2 VPN Distribution LSAs that belong to locally enabled VLAN domains are processed and update VFEC tables. LSAs that do not belong to the local domain MUST still be included in the Link State Database and MUST be flooded according to OSPF[8] conventions. Layer 2 VPN Distribution LSAs should NOT be included in SPF calculations. Any changes to VFEC tables should trigger LSA updates. In addition, all OSPF update events should trigger LSA updates. VFEC table population based on received LSAs is performed per Layer 2 NBVPN domain. The exact procedures for updating VFEC entries from distributed Layer 2 VPNinformation is implementation dependent. 11. Security Considerations This implementation does not affect the underlying security requirements of OSPF. Implementations that wish to implement higher levels of security should consider cryptographic OSPF [8]. 12. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Senevirathne Informational - January 2002 13 draft-tsenevir-8021qospf-01.txt July 2001 3 Senevirathne, T and Billinghurst, P, "Use of CR-LDP or RSVP-TE to Extend 802.1Q Virtual LANs across MPLS Networks", Work in Progress, October 2000. 4 Senevirathne, T., et.al, " A Framework for Virtual Metropolitan Internetworks (VMI)", Work in Progress, July 2001. 5 Senevirathne, et.al, "Requirements for Network Based Layer 2 VPN", Work In Progress, May 2001. 6 Coltun, R, "The OPSF Opaque LSA Option", Work in Progress, July 1998. 7 Martini, L. et al , "Transport of Layer 2 Frames Over MPLS", Work in Progress, September 2000. 8 Moy, J., "OPSF Version 2", RFC 2328, April 1998. 13. Acknowledgments Ideas presented in this document have been influenced by sighted references and ongoing work in the IETF. Senevirathne Informational - January 2002 14 draft-tsenevir-8021qospf-01.txt July 2001 14. Author's Addresses Tissa Senevirathne Force10 Networks 1440 Milpitas, California. Phone: 408-965-5103 Email: tsenevir@hotmail.com Paul Billinghurst Extreme Networks 3585 Monroe Street, Santa Clara Phone: 408-579-2800 Emial: p_billing@yahoo.com Senevirathne Informational - January 2002 15 draft-tsenevir-8021qospf-01.txt July 2001 Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Senevirathne Informational - January 2002 16