Network Working Group Tissa Senevirathne Internet Draft Paul Billinghurst Document: draft-tsenevir-8021qbgp-00.txt Hamid Ould-Brahim Category: Informational Bryan Gleeson Nortel Networks November 2000 Distribution of 802.1Q VLAN information using BGP 4-MP Extensions 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 paper presents a method to distribute 802.1Q VLAN information across Autonomous Systems using BGP-4. The solution provided here allows to learn VLAN information across Autonomous Systems. The VLAN information and end point discovery presented here is especially useful in providing end-to-end Virtual LAN Services across Autonomous Systems. Senevirathne Informational - April 2001 1 draft-tsenevir-8021qbgp-00.txt November 2000 Table of Content 1. Conventions used in this document..................................2 2. Introduction.......................................................2 3. Typical Deployment Scenario........................................3 4. VLAN Domain Identifier (VDI).......................................4 4.1. Use of BGP Extended Communities..................................4 5. Encoding VLAN information in BGP...................................6 5.1.1 Multiprotocol Reachable NLRI....................................6 5.1.2 NLRI Encoding...................................................7 5.1.3 Encoding of VLAN Information....................................7 5.2 Advertising Unreachability.......................................10 6. Capability Advertisement..........................................11 7. Population of VFEC................................................11 8. VLAN information Aggregation......................................11 9. VLAN Distribution over E-BGP Sessions.............................12 10. VLAN Distribution over I-BGP Sessions............................12 11. Security Considerations..........................................12 12. References.......................................................12 13. Acknowledgments..................................................13 14. Author's Addresses...............................................14 Full Copyright Statement.............................................15 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 This paper presents a possible method of distributing 802.1Q VLAN information using BGP. With the increasing prospect of MAN (Metropolitan Area Networks) and optical Ethernet solutions, End to End Layer 2 connectivity provisioning is attracting attention. There are several publications that present various tunneling protocols to transport Layer 2 traffic across IP Networks. However, there are only few publications available in the area of automatic distribution of VLAN information. Automatic distribution of VLAN information becomes important in large networks, especially where large number of mutually exclusive VLAN topologies exist. [3] Paper presents a method of distributing VLAN related information using OSPF Opaque LSA. [4] Presents method of Layer 2 information distribution using BGP. However, level of detail presented here is different to [4]. This paper does not attempt to extend any Layer 1 connectivity across MPLS network, rather it provides a VPN sort of connectivity at the Layer 2 level. Concepts and format of VLAN information presented in [3] have been extended in this paper to Senevirathne Informational - April 2001 2 draft-tsenevir-8021qbgp-00.txt November 2000 facilitate distribution of VLAN information across Autonomous Systems. Unlike, IP address allocations, VLANs are allocated at random and at the will of the customer. As an example, VLAN v1 of customer c1 may not have any co-relation to VLAN v2 of customer c2. This random distribution of VLAN information makes classification of incoming packets to Layer 2 VPN more complex than classification of incoming packets to a Layer 3 VPN. To resolve this we have introduced a concept of VLAN Domain Identifier (VDI). VDI provides a method of distributing, multiple, mutually exclusive Layer 2 topologies on a given network infrastructure. [3] Presents methods to group VLAN ranges within a given VLAN domain. Thus providing a hierarchical and scalable Layer 2 VPN solution. In this paper we propose to use BGP multiprotocol extensions to carry proposed VLAN information. The methods used here are similar to [5]. A given update message may carry VLAN Reachability Information for more than one VLAN domain. 3. Typical Deployment Scenario Below is a typical scenario where Layer 2 end-to-end service is required. However, the proposed solution is not limited to the scenario below. ------------ ---------- ----------- | | | | | | | | | | --------- | ------- | | | | | | | | |VDI-V1| | | | | | | | | ------- | L2 | ------ | BB | ----- | L2 | ------ | | |--------||VFEC-1| |------| |VFEC-1||-----| |VDI-V1|| | ------- | | ------ | | ------ | | ------ | | |VDI-V2| | | | | | | | | -------- | | ------ | | | | | | | ||VFEC-2| | | | | | ------------ | ------ | | | --------- CE-1 | | | | CE-2 ------------ ---------- PE-1 PE-2 L2 Layer 2 Connectivity BB Back Bone Network with BGP It is assumed there is a BGP connectivity between each of PE devices. It is assumed that there exists a Layer 2 connectivity between CE and PE (say this is 1 Gig Link). Each PE maintain a VFEC [6] (VLAN Forwarding Equivalence Class) per VLAN Domain. Senevirathne Informational - April 2001 3 draft-tsenevir-8021qbgp-00.txt November 2000 PE maintains VFEC entries for locally attached devices. Local VFEC entries are either obtained via static configuration or by some other method. PE learns about the VFEC entries in other devices using methods described in this document and [3]. It is the function of the receiving PE to update the appropriate "VLAN domain" VFEC table, according to the incoming VDI field in the BGP update message (see below for details). In the above figure, VFEC-1 corresponds to VLAN domain V1. VFEC-1 of PE-1 contain reachability and other information required to reach CE-2 VLAN V1. VLAN information on CE-2 and PE-2 reachability is learnt by PE-1 via BGP extensions presented in this paper. Similarly, VFEC-1 in PE-2 learns reachability and other information about VLAN V1 in CE-1 via BGP extensions presented here. 4. VLAN Domain Identifier (VDI) As discussed earlier, there could exist multiple VLAN topologies (domains) within a given IP topology. These VLANs may reside in different Autonomous Systems (AS), these AS may be controlled by different providers. VDI is a two level identifier. VDI identifies both the corresponding AS and VLAN domain ID within the AS. Thus VDI is defined as {AS:Domain_ID}. It is assumed that, two VLAN domains are in the same layer 2 topology, if and only if the VLAN Domain_ID are equal and the remote AS is part of the peering ASs for this {AS:Domain_ID}. The AS-VLAN peering list is manually configured. If there is large number of AS-VLAN peers, one may choose to use Extended Community Attribute for the purpose of matching incoming VDIs to local VDI. As such AS number may be used in conjunction with local policies to accept or reject VLAN reachable information from that Autonomous System (AS). Encoding of VDI +--------------------------------------+ | AS (2 Octets) | +--------------------------------------+ | Domain ID (4 Octets) | +--------------------------------------+ AS Autonomous System Identifier Domain ID VLAN Domain Identity Number. This is a 32-bit number that is assigned with mutual consensus between different AS administrators, who wish to provide connectivity to the specified VLAN domain. 4.1. Use of BGP Extended Communities Senevirathne Informational - April 2001 4 draft-tsenevir-8021qbgp-00.txt November 2000 The BGP Communities were defined in [7] to simplify application of complex policies. Without BGP Communities, also known as route coloring [8], implementation of complex policies in large routing environment becomes administratively expensive, if not prohibitive. BGP Community is defined as a 4-octet value. General usage of the community is {AS:ID}; here AS is the 2-octet Autonomous System number and ID is arbitrary 2-octet number. The above proposed VDI numbering scheme follows a similar format as the common community value encoding. As a result there is a risk of these mutually exclusive community strings overlapping. The BGP Extended Communities Attribute [9], provides a method to define communities attributes without the risk of overlap. In addition Extended Communities Attribute presented in [9] provides a structured definition of Community Attributes. Thereby, facilitating easy implementation of complex policies. In light of the above reasons, in this paper, we suggest to use Extended Communities Attribute to propagate Communities with VLAN distribution information. The extended community may be used by BGP routers to implement complex VLAN policies easily. As an example a PE may want to use VLAN reachability announced by a specific PE only for backup purpose. All VLAN reachability learnt from that PE may be tagged with some Extended Community, such that all the VLAN rechability with that community gets a lower priority. Presented below is the preferred Extended Communities Attribute encoding for the VLAN distribution. Extended Community sub-Type 0x8020 (hex) is proposed for this purpose. However, if the proposal is accepted a specific value for this purpose will be requested through IANA. +--------------------------------------+ | Type (2 Octets)=0x8020 | +--------------------------------------+ | AS (2 Octets) | +--------------------------------------+ | VLAN Community ID (4 Octets) | +--------------------------------------+ Type Two Octet field, suggested value 0x8020, see [9] for details. AS Autonomous System number assigned by IANA. VLAN Community ID Senevirathne Informational - April 2001 5 draft-tsenevir-8021qbgp-00.txt November 2000 Community String applied to this update message. NOTE: VLAN Community ID, can be different from Domain_ID field in VDI. This is especially true if a single Extended Community is scoping multiple VLAN Domain distributions in a single update message. 5. Encoding VLAN information in BGP BGP-4 Multiprotocol Extensions [10] were designed to carry non IP information in BGP messages. Here we propose to use BGP-4 Multiprotcol Extensions to distribute Layer 2 VLAN information and other related services. Subsequent Address Family Identifier (SAFI) will indicate the receiving routers that this attribute is carrying Layer 2 VLAN information. At present, it is suggested to use 130 (decimal) for SAFI field. Values 0-127 are reserved by IANA. If this proposal is accepted it is suggested that a value in the range of 1-127 is requested from IANA for this purpose. 5.1.1 Multiprotocol Reachable NLRI [10] Presents the encoding format of the MP_REACH_NLRI. We intend to use the attribute with no modification to the encoding format. NLRI field in the MP_REACH_NLRI attribute is enhanced to carry proposed VLAN information. +----------------------------------------------------+ | Address Family Identifier (2 Octets) | +----------------------------------------------------+ | Subsequent Address Family Identifier (1 Octet) | +----------------------------------------------------+ | Length of Next Hop Network Address (1 Octet) | +----------------------------------------------------+ | Network Address of Next Hop (variable) | +----------------------------------------------------+ | Number of SNPAs (1 Octet) | +----------------------------------------------------+ | SNPA definition as in [10] | ~ ~ | | +----------------------------------------------------+ | Network Layer Reachability Information (variable) | +----------------------------------------------------+ The definition and meaning of the fields are as specified in [10]. Presented below are the fields that carry special meaning for this proposal. Subsequent Address Family Identifier This field indicates that this MP-REACH-NLRI is carrying Layer 2 information. Suggested value is 130 (decimal). Senevirathne Informational - April 2001 6 draft-tsenevir-8021qbgp-00.txt November 2000 Network Layer Reachability Information This field carries the VLAN information that is being distributed. See Section 5.1.2 below for the encoding of the field. 5.1.2 NLRI Encoding In order to support distribution of 802.1Q VLAN information, NLRI field is encoded as below. +---------------------------------------------------------------+ | Length of the NLRI (2 Octets) | +---------------------------------------------------------------+ | Number of VLAN Distribution Information (2 Octets) | +---------------------------------------------------------------+ | Length of the First VLAN Distribution Information (2 Octets) | +---------------------------------------------------------------+ | First VLAN distribution Information (variable) | +---------------------------------------------------------------+ | Length of the Second VLAN Distribution Information (2 Octets) | +---------------------------------------------------------------+ | Second VLAN distribution Information (variable) | +---------------------------------------------------------------+ | | ~ ~ | | +---------------------------------------------------------------+ | Length of the N th VLAN Distribution Information (2 Octets) | +---------------------------------------------------------------+ | N th VLAN distribution Information (variable) | +---------------------------------------------------------------+ Definition and meaning of the fields are as below Length of the NLRI The length of the NLRI in bytes. Number of VLAN Distribution Information. Number of VLAN Distribution Information encoded in this NLRI. Length of the VLAN Distribution Information Length of the VLAN distribution information in bytes. VLAN distribution Information The VLAN information that is being distributed. 5.1.3 Encoding of VLAN Information Senevirathne Informational - April 2001 7 draft-tsenevir-8021qbgp-00.txt November 2000 VLAN information presented in [3] is required to be encoded in the VLAN distribution field. Observation of the same information format allows convenient distribution of VLAN information from OSPF to BGP and vice versa. +----------------------------------------------------------+ | VLAN Domain Identifier (VDI) (6 Octets) | +----------------------------------------------------------+ | Length of the End Point IP Address (1 Octets) | +----------------------------------------------------------+ | End Point IP Address | +----------------------------------------------------------+ | Length of BPDU Tag (1 Octets) | +----------------------------------------------------------+ | BPDU Tag ( 2 Octets) | +----------------------------------------------------------+ | Length of Global Services (2 Octets) | +----------------------------------------------------------+ | Global Services (variable) | +----------------------------------------------------------+ | Number of VLAN Distributions (2 Octets) | +----------------------------------------------------------+ | First VLAN Information (6 Octets) | +----------------------------------------------------------+ | Number of Labels in the First Label Stack(1 Octet) | +----------------------------------------------------------+ | First Label Stack (variable) | +----------------------------------------------------------+ ~ ~ | | +----------------------------------------------------------+ | N th VLAN Information (6 Octets) | +----------------------------------------------------------+ | Number of Labels in the First Label Stack (1 Octet) | +----------------------------------------------------------+ | N th Label Stack (variable) | +----------------------------------------------------------+ VLAN Domain Identifier (VDI) VLAN Domain Identifier for this VLAN information, encoded as Section 4 above. Length of End Point IP Address Length of the IP Address is in bits End point IP Address IP Address of the end point. Length of the BPDU Tag Senevirathne Informational - April 2001 8 draft-tsenevir-8021qbgp-00.txt November 2000 Length of the BPDU Tag in bits. Supported values are 0 or 12. All other values are reserved. 0 indicates there is no BPDU TAG associated. Length of Global Services Length of Global Services in Bytes. Global Services Associated Services with this VDI.(TBD) Number of Labels in the First Label Stack Number of Labels in this Stack. Value zero indicates there are no labels associated with this VDI. Label Stack Label Stack contain one or more 3 octet long labels. The high-order bit contain the bottom of the stack. Remaining 3 high order bits are all reserved. Remaining 20 bits of the label contain the label value [11]. The entries in the Label Stack are zero padded to align with 4 octet (32 bit) boundaries. The end-devices optionally choose to advertise a MPLS label that could be pushed in to the Label Stack. This label(s) may provide the ability to merge several MPLS tunnels on to a single outgoing tunnel or may define wider forwarding scope at the egress. See Section 10., below for scaling example. VLAN Information VLAN Information is a combination of several fields. +--------------------------------------------------------------+ | VLAN Flags (1 Octet) | +--------------------------------------------------------------+ | Reserved (1 Octet)| Start VLAN (12 bits) | End VLAN (12 bits)| +--------------------------------------------------------------+ | Reserved (2 bits) | SP (3 bits) | EP (3 bits) | +--------------------------------------------------------------+ VLAN Flags +-------------------------------------------------------------+ | MV ( 1 bit) | +-------------------------------------------------------------+ | FV (2 bits) | +-------------------------------------------------------------+ | MP (1 bit) | +-------------------------------------------------------------+ Senevirathne Informational - April 2001 9 draft-tsenevir-8021qbgp-00.txt November 2000 | FP (2 bits) | +-------------------------------------------------------------+ | Reserved (2 bits) | +-------------------------------------------------------------+ MV VLAN TAG Matching Flag 0 Liberal Matching, 1 Conservative Matching. See [6] for details FV VLAN TAG Field Flag VLAN Tag Range Match - b'00 VLAN Tag Exact Match - b'01 MP P bit Matching Flag 0 Liberal Matching, 1 Conservative Matching. See [6] for details FP P bit Field Flag P bit Range Match - b'10 P bit Exact Match - b'11 Start VLAN Starting TAG of this VLAN entry End VLAN End TAG of this VLAN entry. This field is ignored if FV== b'01 SP Starting P bit value EP End value of P bit. This field is ignored if FP==b'11 Reserved All reserved fields are set to zero in transmission and ignored in receipt. 5.2 Advertising Unreachability Senevirathne Informational - April 2001 10 draft-tsenevir-8021qbgp-00.txt November 2000 It may be required to withdraw either an entire VLAN or some subset of services. We suggest that the same encoding format as the VLAN reachability encoding be used in MP-UNREACH-NLRI. 6. Capability Advertisement Not all BGP speakers are required to provide Layer 2 tunneling services. However, they may be required to participate in Layer 2 VLAN distribution. However, in order to properly handle Multi protocol extensions, all the BGP speakers are required to be MP capable. The MP capability is advertised using the methods specified in [12], with Capability set to 1 with SAFI set to 130 (TBD). 7. Population of VFEC Each device that is providing Layer 2 VLAN services maintains a separate instance of VFEC for each VLAN domain (or Domain_ID). Some of the entries are directly attached VLAN information. Directly attached information are either statically configured or learnt by some other mechanism such as [3]. BGP acceptance policy populates appropriate VFEC tables with the incoming VLAN distribution information. There may be local policies to reject some VLAN domains from some AS. BGP announce policy would announce directly attached (or locally learnt) VLANs via the methods presented here. In some situations there may be local policies to prevent announcing some or all of this VLAN information via BGP. Exact format of the VFEC depends on the Layer 2 tunneling protocol being implemented. [6] Presents VFEC format for MPLS based layer 2 tunnels. Details of the format and the construction of the VFEC is implementation dependent and beyond the scope of this document. 8. VLAN information Aggregation ----- | |------------ | AS 1 | | ----- -------- ---------- | |------| | | AS 4 | | AS 3 | ------ -------- ---------- | | | | AS 2 |------------ ------ Senevirathne Informational - April 2001 11 draft-tsenevir-8021qbgp-00.txt November 2000 Suppose AS 4 is providing transitive services to AS 1, 2 and 3. In this scenario, AS 4 may aggregate all the VLAN information from AS 3 and advertise to AS 1 and AS 2 and vice versa. As explained in [13], AS 4 may advertise a single label to both AS 1 and 2. AS 1 and 2, in turn can use this Label, either as the top label or part of the Label Stack to merge traffic going to AS 3, thereby providing effective scaling in large deployments. 9. VLAN Distribution over E-BGP Sessions The concepts presented here together with AS local policies can be used for inter-AS VLAN distribution. Extended Communities presented in section 4.1 may be useful in implementing complex policies such as backup paths etc. The key is, the concepts presented here use the BGP Multiprotocol extensions to distribute VLAN information, as a result most of the E-BGP methods used in IP routing can be easily implemented. 10. VLAN Distribution over I-BGP Sessions Use of IGP such as OSPF to distribute VLAN information within a large Autonomous system may lead to scaling issues, specially in environment where, changes to the VLAN topology is frequent. However, it is noted here, that calculations such as SPF (Shortest Path First) is not performed on VLAN Distribution Information. Hence, the impact may be less critical than that of classical IP routing. In any case use of I-BGP may provide better manageability and imperative if the AS is multi homed and providing transitive services. Full meshed network topology is a fundamental requirement of classical I-BGP. This requirement leads to scaling issues in large networks and possibly makes I-BGP administratively prohibitive. There are several solutions to circumvent the need of fully meshed I-BGP topology. Route Reflector concept presented in [14] provides a method to construct manageable I-BGP peer network. There are no additional changes needed to distribute VLAN information using Route Reflector methods explained in [14], except that BGP speakers are able to understand BGP-MP extensions [10] and Extended Communities attributes [9]. 11. Security Considerations This implementation does not affect the underlying security requirements of BGP-4. 12. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Senevirathne Informational - April 2001 12 draft-tsenevir-8021qbgp-00.txt November 2000 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Senevirathe, T, and Billinghurst, P., "Distribution of 802.1Q VLAN information using OSPF Opaque LSA", Work in Progress, October 2000. 4 Kompella, K., et al., "MPLS-based Layer 2 VPNs", Work in Progress, October 2000. 5 Ould-Brahim, H., et al., "BGP/VPN: VPN Information Discovery for Network-based VPNs", Work in Progress, July 2000. 6 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. 7 Chandra, R., "BGP Communities Attribute", RFC 1997, August 1996. 8 Stewart III, J.W., "BGP4 Inter-Domain Routing in the Internet", Addison-Wesley, 1998. 9 Ramachandra, S., and Tappen, D., " BGP Extended Communities Attribute", Work in Progress, May 2000. 10 Bates, T., et al., "Multiprotocol Extensions for BGP-4", RFC 2283, February 1198. 11 Rosen, E., et al., "MPLS Label Stack Encoding", Work in Progress, July 2000. 12 Chandra, R., and Scudder, J., "Carrying Label Information in BGP- 4", Work in Progress, January 2000. 13 Rekhter, Y and Rosen, E., "Carrying Label Information in BGP-4", Work in Progress, January 2000 14 Bates, T., et.al., "BGP Route Reflection - An alternative to full mesh IBGP", RFC 1966, June 1996. 13. Acknowledgments Ideas presented in this document have been influenced by sighted references and ongoing work in the IETF. Akbal Karlcut provided valuable suggestions. Senevirathne Informational - April 2001 13 draft-tsenevir-8021qbgp-00.txt November 2000 14. Author's Addresses Tissa Senevirathne Nortel Networks 4401 Great America Pkwy, Santa Clara, CA 95054 Phone: 408-565-2571 Email: tsenevir@nortelnetworks.com Paul Billinghurst Nortel Networks 4401 Great America Pkwy, Santa Clara, CA 95054 Phone: 408-565-2357 Email: pbilling@nortelnetworks.com Hamid Ould-Brahim Nortel Networks PO Box 3511 Station C, Ottawa, ON KIY 4H7 Phone: 613-765-3418 Email: hbrahim@nortelnetworks.com Bryan Gleeson Nortel Networks 2305 Mission College Blvd, Santa Clara, CA 95054 Phone: 408-565-2625 Email: bgleeson@nortelnetworks.com Senevirathne Informational - April 2001 14 draft-tsenevir-8021qbgp-00.txt November 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 - April 2001 15