Opaque Information Distribution

Transcription

1 1 of 9 10/24/ :09 Network Working Group R. Raszuk, Editor INTERNET DRAFT Cisco Systems <draft-raszuk-idr-oid-base-00> P. Marques, Editor Category: Standards Track Juniper Networks Expires: April 2007 October 2006 Opaque Information Distribution draft-raszuk-idr-oid-base-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 < The list of Internet-Draft Shadow Directories can be accessed at < This Internet-Draft will expire in April Copyright Notice Copyright The Internet Society (2006). All Rights Reserved. Abstract In order to simplify the operations and management of IP networks there is the need to distribute information between routers that does not directly relate to network reachability, but that is required to automate the process of network discovery and auto-configuration. Another area where increasing the amount of information on nodes making routing decisions is beneficial would be in the cases of new advanced services being offered by the operators where the key differentiator would be the introduction of new layer of network intelligence. This document defines an extension to BGP [RFC4271] that can be used to distribute generic information tuples between network devices. It is expected that this information be used to simplify the configuration and deployment of network devices, but the document makes no assumptions as to the format or contents of such information. In this document we present a generalized mechanism allowing to advertise various sets of information, keep them in database, as well as request them on a as needed basis by clients. Requirements Language 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 [RFC2119].

2 2 of 9 10/24/ :09 Table of Contents 1. Introduction 2. Operation 2.1 Update packing consideration 3. OID NLRI encoding 4. BGP Informational attribute 5. Capability advertisement 6. Scaling 7. Deployment Considerations 8. Contributors 9. IANA Considerations 10. Security Considerations 11. Acknowledgements 12. References 12.1 Normative Reference 12.2 Informative Reference Authors' Addresses Intellectual Property and Copyright Statements

3 3 of 9 10/24/ :09 1. Introduction As networks using the IP control plane have expanded to provide multiple applications and multiple services the need for automating device configuration has increased. The traditional network management solution is to use out-of-band systems that perform network device configuration via CLI or SNMP commands. This approach, while recommendable for many applications doesn't always present the best approach to situations in which the configuration should depend on the network topology. Along the same lines traditional collection for various information describing router's operation is also today performed out of band (via SNMP or Netflow). Where such data is to be used as one of many factors for routing decison it's in-bound collection seems also like a natural fit. An example is the configuration of a full mesh of MPLS LSPs between all edge devices that provide a given service. While this function could be performed via off-line management tool, it is often the case that service providers do not have the resources to develop this type of dynamic logic into their management systems. Another approach is for the network to attempt to auto-configure itself following a given policy that is driven by the management system. In this case, the hypothetical policy would be that a edge device would advertise its identity into a particular database and automatically establish MPLS LSPs to other devices that generate similar advertisements. The authors believe that such approach can simplify the operation of network devices. It is important to consider the characteristics of the data that will be used for this class of applications. It is expected that it can grow to large numbers of data elements which do not have very aggressive requirements in terms of propagation delays. When considering existing protocols that are habitually running on service provider networks, the characteristics of this type of data make it un advisable to carry as extensions to existing IGPs. However, the BGP protocol can easily be extended to carry this type of information and does adapt itself quite readily to its characteristics. The assumption however is that a mechanism can be implemented to automatically establish an initial BGP topology that can distribute information to all network devices. This can be implemented by advertising via the IGPs a pair of redundant BGP route reflectors that do advertise the OID (afi, safi) information defined in this document. The approach taken in OID proposal allows to build a single mechanism to distribute various network elements information to a database or set of redundant databases. In the initial phase the most logical proposal is to use standard BGP route reflectors (intra domain) or route-servers (inter-as) as database servers. The proposal consist of the base specification for new BGP AFI/SAFI definition as well as common attribute which would be used to encapsulate given type of database records. Adding new set of information will be very easy and incremental enabling very easy future extensions and modification to the proposed apparatus. By using MP-BGP [I-D.ietf-idr-rfc2858bis] UPDATE messages to propagate OID SAFI it is possible to reuse all BGP machinery assuring loop-free intra & inter-as information distribution with additional capability for fine grained policy application. Access to the information will be selective based on the interest of the receiver limited to given information record types. Support for more detailed query mechanism within given record type will be described in the next phases of this base specification. By using BGP ORF mechanism clients will have very easy way to indicate to sender the subset of information they are interested in receiving. 2. Operation Proposed mechanism will use BGP update message format's encapsulation to exchange information between network elements. It is assumed that while in intra domain case IGP extensions as proposed in the past for BGP Auto Discovery [...] can be used to auto discover

4 4 of 9 10/24/ :09 database servers (BGP route reflectors/bgp route servers) the initial base specification will assume manual configuration for the OID BGP session. By manual configuration authors assume both single sided or dual sided BGP session establishment. Once the general BGP mechanism completes resulting in the session being established information exchange will then take place. By using BGP capabilities set of information types to be exchanged with given peer will be known. Also symetry/asymetry in the information exchange directions will be indicated. It is expected that when Router_ID or AS number is changed on the BGP speaker session will be restarted and therefore NLRI received with restarting speaker withdrawn. An implementation may force the user to configure BGP Router_ID explicitly, before activating the new BGP Peer Discovery AFI/SAFI. Each BGP speaker will perform standard BGP procedures (update generation, advertisements, in/outbound filtering when applicable, best path selection etc... ) on this SAFI just like it would for any other SAFI. 2.1 Update packing consideration Depending on the type of information the packing may vary. In example if type attributes contains unique information per sender, database propagation clients may either be on a message per sender basis or some form of attribute concatenation needs to performed in the database. On the other hand if the information propagated can be common to many senders BGP will pack all sender's NLRIs into single MP_REACH_NLRI allowing all of them to be send in a single message with the identical record type attributes. 3. OID NLRI encoding Throughout this document, the term NLRI, which originally expands to "Network Layer Reachability Information" is used to describe routing information carried via MP-BGP updates without any assumption of semantics. An NLRI consisting of {Prefix_Length, OID_Type, OID_Key} will be referred to as OID NLRI for the purpose of the explanation in this document. The prefix length is expressed numerically in bytes. OID NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [6]. The single record information addition/deletion or modifications shall be propagated with MP_REACH_NLRI. Including OID NLRI in MP_UNREACH_NLRI will result in deletion of all previously propagated information records. The [AFI, SAFI] value pair used to identify this NLRI is (AFI=1, SAFI=/XXXX/). The Next Hop field of MP_REACH_NLRI attribute should be optional. When present (length > 0) NLRIs are only valid if the next-hop is reachable via RIB otherwise the information is valid until being withdrawn or BGP session it has been received on went down. When next hop has a length of 4 octets it is treated as IPv4 address and when 16 octets it is treated as IPv6 address. New next hop address types can be specified when required. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a variable length. OID NLRI structured is encoded as follows: NLRI Length (2 octets) OID Type (4 octets) OID Type Key (Variable)

5 5 of 9 10/24/ :09 Figure 1 - OID NLRI structure The above NLRI structure allows very easy and direct information insertion into a database where BGP can treat it as an opaque data. The OID Type becomes the table index while OID type keys become given database table rows. The carried content is linked to the keys Key_A" > Attr Content A" Key_A' Key_A > Attr Content A Key_B OID Type Database table index Key_Z OID Type 2 - Database table index OID Type 1 - Database table index 1 Figure 2 - OID to database direct mapping Example: In the application of BGP discovery proposal as described in [...] the NLRI for the IPv4 peering cases would have the format of: <10,BGP_Auto-Discovery_Type,IPv4_Peering_Address> and the content would be carried in the given information attribute. 4. BGP Informational attribute For the purpose of having a single BGP attribute capable of carrying opaque information we define a BGP Informational Attribute. The type code of this attribute is YYYY. A simple encoding for BGP Informational attribute is presented below: Attr. Flags (1 octet) Attr. Type Code (1 octet) Attribute Length (2 octets) Information Descriptor (var) Figure 3 - BGP Informational Attribute Flags & Type code fields: Figure 4 - Attribute Flags YYYY Bit 0 - Optional attribute (value 1) Bit 1 - Transitive attribute (value 1) Bit 2 - Partial bit (value 0 for optional non transitive attributes) Bit 3 - Extended length of two octets (value 1) Bit Unused (value all zeros) Type code - Attribute type code (YYYY) The semantics of information descriptor field will be described in corresponding documents

6 6 of 9 10/24/ :09 which would define given applications. 5. Capability advertisement A BGP speaker that wishes to advertise and receive OID information of given type must use the new OID Capability Code to advertise the corresponding (AFI, SAFI) pair along with per OID type parameters. OID Capability is a new BGP capability [RFC3392] defined as follows: Capability code: ZZZZ Capability length: variable Capability value: one or more of the entries as shown in Figure X. Capability Code ZZZZ (1 octet) Capability Length (1 octet) < Reserved (1 octet) Number of OID types (1 octet) OID Type (1 octet) Capability Send/Receive (1 octet) Value... OID Type (1 octet) Send/Receive (1 octet) < Figure 5 - OID BGP Capability Encoding The use and meaning of these fields are as follows: Address Family Identifier (AFI): This field carries the identity of the Network Layer protocol associated with the Network Address that follows. Presently defined values for this field are specified in RFC 1700 (see the Address Family Numbers section). Subsequent Address Family Identifier (SAFI): This field provides additional information about the type of the Network Layer Reachability Information carried in the attribute. Number of OID Types: This field contains the number of Filter Types to be listed in the following fields. OID Type: This field contains the value of an OID Type. Send/Receive: This field indicates whether the sender is: (a) willing to receive OID entries from its peer for a given OID Type (value 1) (b) would like to send OID entries to its peer for a given OID Type (value 2) (c) Willing to both send & receive OID entries from the peer (value 3). 6. Scaling Scaling aspect of the proposal largely depend on a type of information proposed to be carried. Information like discovery parameters to automatically provision BGP sessions for given

7 7 of 9 10/24/ :09 AFI/SAFI [BGP-DISC] will be triggered by manual configuration so they will change relatively infrequent. What also needs to be pointed out that proposed to be used RRs as a databases can be distributed in a such way that each OID type can reside on a different server. 7. Deployment Considerations As the character of the proposed mechanism has mainly an informational character incremental deployment is fully supported. Depending on the type of OID type full benefit of partial deployment of given OID type peerings the network wide benefit will also be different. 8. Contributors TBD 9. IANA Considerations This document defines a new BGP OID SAFI type code XXXX which will be used to carry opaque to BGP data. That value will need to be assigned by IANA from BGP SAFI Type Code space. This document defines a new NLRI format, called Opaque Information Distribution NLRI, to be carried in BGP OID SAFI using BGP multiprotocol extensions [I-D.ietf-idr-rfc2858bis]. This document defines a new BGP optional transitive attribute, called BGP Informational Attribute. A new attribute type code YYYY is to be assinged by IANA from the BGP path attribute Type Code space. This document defines a new BGP Capability Type code (ZZZZ) to be allocated by IANA. Once XXXX, YYYY & ZZZZ values are allocated please replace them in the above text. 10. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing BGP [RFC2385]. 11. Acknowledgements The authors would like to thank Keyur Patel for his valuable comments and suggestions. 12. References 12.1 Normative Reference [I-D.ietf-idr-rfc2858bis] Bates, T, Multiprotocol Extensions for BGP-4, Internet-Draft draft-ietf-idr-rfc2858bis-10, March [RFC2119] [RFC2385] [RFC2434] [RFC3392] 12.2 Informative Reference Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March Heffernan, A., Protection of BGP Sessions via the TCP MD5 Signature Option, RFC 2385, August Narten, T. and H.T. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October Chandra, R. and J. Scudder, Capabilities Advertisement with BGP-4, RFC 3392, November 2002.

8 8 of 9 10/24/ :09 [RFC1965] Traina, P., Autonomous System Confederations for BGP, RFC 1965, June [RFC2026] Bradner, S., The Internet Standards Process -- Revision 3, BCP 9, RFC 2026, October [RFC2028] Hovey, R. and S. Bradner, The Organizations Involved in the IETF Standards Process, BCP 11, RFC 2028, October [RFC2434] Narten, T. and H.T. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October [RFC2796] Bates, T., Chandra, R., and E. Chen, BGP Route Reflection - An Alternative to Full Mesh IBGP, RFC 2796, April [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, Multiprotocol Extensions for BGP-4, RFC 2858, June [RFC4271] Rekhter, Y., Li, T., and S. Hares, A Border Gateway Protocol 4 (BGP-4), RFC 4271, January Authors' Addresses Robert Raszuk (editor) Cisco Systems 170 West Tasman Dr San Jose, CA USA raszuk@cisco.com Pedro Marques (editor) Juniper Networks 1194 N. Mathilda Ave. Sunyvale, CA USA roque@juniper.net Intellectual Property Statement 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 any 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 < 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. Disclaimer of Validity 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. Copyright Statement Copyright The Internet Society (2006). This document is subject to the rights, licenses and

9 9 of 9 10/24/ :09 restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.