Internet Engineering Task Force J.M. Jeganathan Internet-Draft V.S. Avula Intended status: Standards Track Juniper Networks Expires: 13 January 2022 12 July 2021 BGP Peer Auto-Configuration draft-minto-idr-bgp-autodiscovery-00 Abstract This document describes a layer 3 protocol (Service advertisement) to help bgp to advertise service availability and local configurations . This enable bgp speakers to discover bgp peers transport endpoints and peer's configuration within link. With Service advertisement, receivers could successfully bring up bgp protocol session without mundane configurations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 13 January 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Jeganathan & Avula Expires 13 January 2022 [Page 1] Internet-Draft Abbreviated Title July 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 3 3. PUD layers . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. SA Base message . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Remaining lifetime TLV . . . . . . . . . . . . . . . 5 4.1.2. Config sequence TLV . . . . . . . . . . . . . . . . . 5 4.2. BGP service advertisement message . . . . . . . . . . . . 6 4.2.1. Local address . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Security TTL . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Security Authentication . . . . . . . . . . . . . . . 6 4.2.4. TCP MSS . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.5. link address . . . . . . . . . . . . . . . . . . . . 7 4.2.6. Transport address family preference . . . . . . . . . 7 5. Protocol operation . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7.1. Message of SA . . . . . . . . . . . . . . . . . . . . . . 9 7.2. TLVs of SA base Message . . . . . . . . . . . . . . . . . 9 7.3. TLVs of BGP service advertisement message . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document describes a layer 3 protocol (Service advertisement)to help bgp to advertise service availability and local configurations . This enable bgp speakers to discover bgp peers transport endpoints and peer's configuration within link. With Service advertisement, receivers could successfully bring up bgp protocol session without mundane configurations. 1.1. 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]. Jeganathan & Avula Expires 13 January 2022 [Page 2] Internet-Draft Abbreviated Title July 2021 2. Protocol overview This is a simple protocol, periodically send and receive UDP multicast PDU that contains bgp transport information in the form of messages and TLVs. Receiver could use this information to bootstrap the 1hop bgp and/or loopback address bgp between directly connected bgp speakers. The advertised information gets expired if not refreshed before the lifetime. This protocol does not provide any reliability of delivery and relay on UDP multicast and periodic send. The current version of this protocol assumes the link MTU is good enough to encode BGP transport information or underlying IP implementation able to do fragment and reassembly for link local multicast PDU. But this protocol flexible enough implements a future version of fragment TLV attachment to bypass the smaller link MTU for the system or environment prevent IP fragment. Service Advertisement (SA) PDU has multiple types of messages. This document defines 2 types of messages. The primary/base messages are required for SA to operates and secondary type messages for BGP service advertisement. 3. PUD layers The PDU contains a header followed by variable number of messages. Each message contains variable number of TLVs. SA uses type length value 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value .. +-+-+-+-+ Figure 1 Type: This 1-octet value to define how to interpret the value with in message. The same type value could be reused in different message. Length: Specifies length in octets of the value field. Value: Octet string that encodes information to be interpreted as specified by the Type field. Jeganathan & Avula Expires 13 January 2022 [Page 3] Internet-Draft Abbreviated Title July 2021 SA uses message to group set of 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |message Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs +----- Figure 2 message Type: This 1-octet value identifies type of message. Message Length: Specifies the length in octets of the Message ID and TLVs. Message ID :32-bit value used to identify this message. Used for logging purpose. SA PDU 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | PDU Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Messages +----- Figure 3 Version: This 1-octet unsigned integer indicates the protocol version. This version of the specification specifies Service Advertisement version 0. Message Length: Length of the PDU. PDU Length: This 2-octet unsigned integer specifies the length Jeganathan & Avula Expires 13 January 2022 [Page 4] Internet-Draft Abbreviated Title July 2021 Identifier: 4 octet field that uniquely identifies PDU sender. BGP id could be used for this purpose. This help to uniquely identify sender across the parallel links between same nodes. 4. Messages The document defines following messages. 1. SA Base message 2. BGP service advertisement message 4.1. SA Base message The SA Base message is mandatory message and mainly used for the protocol operation. The document defines following TLVs for SA Base message. 1. Remaining lifetime TLV 2. Config sequence TLV 3. Authentication TLV 4.1.1. Remaining lifetime TLV Remaining lifetime describes how long receiver keep the state without seeing a PDU from the sender. The lifetime gets updated whenever receiver accept the PDU. Type : 1 Length: 2 octets Value: Remaining lifetime in seconds 4.1.2. Config sequence TLV Specifies a 4-octet configuration sequence number. Receiver could make use the number to detect config change.This will be useful to restart the bgp open message again. Type : 2 Length: 4 octets Value: unsigned sequence number Jeganathan & Avula Expires 13 January 2022 [Page 5] Internet-Draft Abbreviated Title July 2021 4.2. BGP service advertisement message BGP service advertisement message enable BGP to use the information to successfully bring up bgp session. The document defines transportport information TLVs and session information TLVs for BGP service advertisement message. Following are the Transport information TLVs 1. Local address 2. Security TTL 3. Security Authentication 4. link address 5. Transport preference. 6. TCP MSS 4.2.1. Local address Specifies a local address used for bgp transport connection. Type : 1 Length: 4 for IPv4 transport and 16 for IPv6 transport Value: local IPv4 or IPv6 address used for transport connection. 4.2.2. Security TTL TTL be accepted for bgp messages Type : 2 Length: 0 Value: The presence of the TLV indicate receiver only accept TTL with 255. 4.2.3. Security Authentication TTL be accepted for bgp messages Type : 3 Jeganathan & Avula Expires 13 January 2022 [Page 6] Internet-Draft Abbreviated Title July 2021 Length: 1 Value:This support only two values 0 and 1. 0 indicates TCP md5. 1 indicates TCP-AO Absence of this TLV indicates, no authentication used for connection. 4.2.4. TCP MSS TCP MSS used for the connection Type : 4 Length: 4 Value:Value in bytes Indicates the preference of TCP MSS for the transport connection. 4.2.5. link address This will be useful to receiver for nexthop for local address TLV when sender running IPv4 PDU and prefer IPv6 transport and vice versa. Type : 5 Length: 4 for IPv4 transport and 16 for IPv6 transport. Value:local IPv4 or IPv6 address used for transport connection. 4.2.6. Transport address family preference When both IPv4 and IPv6 transport are available this, this tlv indicates sender preference Type : 6 Length: 1 for IPv4 transport and 16 for IPv6 transport. Value:0 IPv4 and 1 IPv6, 2 for both 5. Protocol operation A sender should periodically send PDU to refresh the advertised information before remaining life become zero. Jeganathan & Avula Expires 13 January 2022 [Page 7] Internet-Draft Abbreviated Title July 2021 A sender should send the PDU to refresh the before the advertised remaining lifetime expire. If bgp is only configured with only one transport address family(IPv4/v6) then sender shall only send corresponding data protocol PDU. If both addresses are configured, then it shall use both data protocol PDU. PDUs are send with source address as link primary address and destination is link local all- routers with TTL 255. if the authentication is enabled then add authentication TLV using the authentication procedure described in [TBD]. Populated other TLVs based on local preference and send the PDU in configured link. The sematic content (transport and session information) of the PDU should be same irrespective the data protocol. Receiver reset refresh of the state whenever it accepts the PDU irrespective of the data protocol. Receiver shall add a route for the address in local address TLV with nexthop as source address of the PDU if PUD data protocol and local address is same address family. Otherwise if link address is available and link address could be used as nexthop for the address in local address TLV. Receivers consolidate state from various TLV and pass on BGP for the session opening. An implementation could only notify if the state change from previous reported state to bgp or the configuration sequence number changes from the receiver. How bgp uses this information is beyond the scope of the document. 6. Acknowledgements Jeff Hass provided many useful technical and editorial comments and suggestions for improvement. 7. IANA Considerations This document requests IANA to allocate a new UDP port (179 is the preferred number ) and 2 message type code for service advertisments. Value TLV Name Reference ----- ------------------------------------ ------------- Service Name: Service advertisments Transport Protocol: UDP Assignee: IESG iesg@ietf.org Description: Service advertisments for auto configuration. Reference: This document -- draft-minto-idr-bgp-autodiscovery.txt Port Number: 179 -- To be assigned by IANA. Figure 4 Jeganathan & Avula Expires 13 January 2022 [Page 8] Internet-Draft Abbreviated Title July 2021 7.1. Message of SA This document requests IANA to create a new registry following messages "Messagess of SA " with the following registration procedure: Registry Name: Messages of SA protocol Value Message name Reference ------- ---------------------------------- ------------- 0 reserved This document 0 SA Base message This document 1 BGP service advertisement message This document Figure 5 7.2. TLVs of SA base Message This document requests IANA to create a new registry following messages "TLVs of SA base Message" with the following registration procedure: Registry Name: TLVs of SA base Message. Value TLV Name Reference ------- ---------------------------------- ------------- 0 Reserved This document 1 Remaining lifetime TLV This document 2 Config sequence TLV This document 3 Authentication This document 224-255 Experimental Figure 6 7.3. TLVs of BGP service advertisement message This document requests IANA to create a new registry following messages "TLVs of BGP service advertisement" with the following registration procedure: Jeganathan & Avula Expires 13 January 2022 [Page 9] Internet-Draft Abbreviated Title July 2021 Registry Name: TLVs of bgp service advertisement Message. Value TLV Name Reference ------- ---------------------------------- ------------- 0 Reserved This document 1 Local Address This document 2 Security TTL This document 3 Security Authentication This document 4 link address This document 5 Transport preference This document 6 TCP MSS This document 224-255 Experimental Figure 7 8. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2006, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . Jeganathan & Avula Expires 13 January 2022 [Page 10] Internet-Draft Abbreviated Title July 2021 Appendix A. Additional Stuff This becomes an Appendix. Authors' Addresses Jeyananth Minto Jeganathan Juniper Networks Juniper Networks, 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: minto@juniper.net Venkata Shiva Krishna Reddy Juniper Networks Juniper Networks, 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: venkatashiva@juniper.net Jeganathan & Avula Expires 13 January 2022 [Page 11]