Network Working Group E. Chen Internet Draft N. Shen Intended Status: Standards Track Cisco Systems Expiration Date: April 29, 2017 R. Raszuk Bloomberg LP October 28, 2016 Carrying Geo Coordinates in BGP draft-chen-idr-geo-coordinates-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 29, 2017. Copyright Notice Copyright (c) 2016 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 (http://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 Chen, Shen & Raszuk [Page 1] Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract In this document we specify a new BGP capability - the Geo Coordinate Capability, and a new BGP attribute - the Geo Coordinate Attribute, for carrying the Geo Coordinate information in BGP. 1. Introduction There are several potential applications as described hereby for the physical location information of BGP speakers [RFC4271] in a network. In an "overlay network" without IGPs or where the "underlay network" belongs to a different administrative domain (e.g., using the BGP Tunnel Encapsulation Attribute [I-D.ietf-idr-tunnel-encaps]), the geographical location of the BGP speaker that sources the route in the network can be used to derive some rough sense of "distance" as a parameter in lieu of the IGP-metric in BGP path selection. In the applications of "Service Function Chaining" [RFC7665], the Geo location information of the Service Function Forwarders or the Service Nodes, can help the design of Service Function Paths with better traffic pattern and a lower latency. The knowledge of the physical location of BGP speakers can also be used to simplify the operational procedures for setting the outbound "MED" value in route advertisement. In this document we specify a new BGP capability - the Geo Coordinate Capability, and a new BGP attribute - the Geo Coordinate Attribute, for carrying the Geo Coordinate information in BGP. 1.1. Specification of Requirements 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 [RFC2119]. Chen, Shen & Raszuk [Page 2] Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016 2. The Geo Coordinate Capability The Geo Coordinate Capability is a new BGP capability [RFC5492]. The Capability Code for this capability is specified in the "IANA Considerations" section of this document. The Capability Length is 20 octets. The Capability Value consists of the following fields that specify the location of the speaker using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|N|E|A|M|R|K| Reserved-1 | Location Uncertainty | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lat Degrees | Latitude Milliseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Long Degrees | Longitude Milliseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radius | Reserved-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: U-bit: If the U-bit is set, it indicates that the "Location Uncertainty" field is specified. If the U-bit is clear, it indicates the "Location Uncertainty" field is unspecified. N-bit: If the N-bit is set, it indicates the Latitude is north relative to the Equator. If the N-bit is clear, it indicates the Latitude is south of the Equator. E-bit: If the E-bit is set, it indicates the Longitude is east of the Prime Meridian. If the E-bit is clear, it indicates the Longitude is west of the Prime Meridian. A-bit: If the A-bit is set, it indicates the "Altitude" field is specified. If the A-bit is clear, it indicates the "Altitude" field is unspecified. M-bit: If the M-bit is set, it indicates the "Altitude" is specified in meters. If the M-bit is clear, it indicates the "Altitude" is in centimeters. R-bit: If the R-bit is set, it indicates the "Radius" field is specified and the encoding is for a circular area. If the Chen, Shen & Raszuk [Page 3] Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016 R-bit is clear, it indicates the "Radius" field is unspecified and the encoding is for a single point. K-bit: If the K-bit is set, it indicates the "Radius" is specified in kilometers. If the K-bit is clear, it indicates the "Radius" is in meters. Reserved-1: These bits are reserved. They SHOULD be set to zero by the sender and MUST be ignored by the receiver. Location Uncertainty: Unsigned 16-bit integer indicating the number of centimeters of uncertainty for the location. Latitude Degrees: Unsigned 8-bit integer with a range of 0 - 90 degrees north or south of the Equator (northern or southern hemisphere, respectively). Latitude Milliseconds: Unsigned 24-bit integer with a range of 0 - 3,599,999 (i.e., less than 60 minutes). Longitude Degrees: Unsigned 8-bit integer with a range of 0 - 180 degrees east or west of the Prime Meridian. Longitude Milliseconds: Unsigned 24-bit integer with a range of 0 - 3,599,999 (i.e., less than 60 minutes). Altitude: Signed 32-bit integer containing the Height relative to sea level in centimeters or meters. A negative height indicates that the location is below sea level. Radius: Unsigned 16-bit integer containing the radius of a circle centered at the specified coordinates. The radius is specified in meters unless the K-bit is specified indicating specification in kilometers. If the radius is specified, the geo-coordinates specify the entire area of the circle defined by the radius and center point. While the use cases herein do not make use of this field, future use cases may. Reserved-2: The 16-bit field is reserved. It SHOULD be set to zero by the sender and MUST be ignored by the receiver. Chen, Shen & Raszuk [Page 4] Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016 3. The Geo Coordinate Attribute The Geo Coordinate Attribute is an optional, transitive BGP attribute [RFC4271]. The type of the attribute is described in the IANA Considerations section, and the value of the attribute consists of one or more of the tuple encoded as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|N|E|A|M|R|K| Reserved-1 | Location Uncertainty | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lat Degrees | Latitude Milliseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Long Degrees | Longitude Milliseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radius | Reserved-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the "AS number" and the "BGP Identifier" fields contain the AS number and the BGP Identifier [RFC4271, RFC6286] of the BGP speaker that sources or advertises the route, and the remaining fields specify the location of the speaker using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. These location related fields are hereby given the same description as the ones in the "Geo Coordinate Capability" section. 4. Operations The Geo Coordinate Capability may be used by a BGP speaker to advertise its physical location to its neighbor. When an IGP (such as OSPF or ISIS) is involved and accessible, it could be advantageous for the Geo Coordinates to be carried in the IGP instead of in the OPEN for internal BGP ("IBGP") sessions. When a BGP speakers receives the Geo Coordinate Capability in the OPEN message from a neighbor, it is up to the speaker and its local policy to decide how the information would be used. The Geo Coordinate Attribute may be used by a BGP speaker to encode Chen, Shen & Raszuk [Page 5] Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016 the physical location of the speaker in an UPDATE message. In the case that a route already contains the attribute, the speaker MAY prepend its AS number, its BGP Identifier, and the Geo coordinate information in the value field of the attribute, and adjust the attribute length accordingly. Depending on local policy, the speaker MAY also override the existing Geo Coordinate Attribute with its own information in route advertisement. When a BGP speakers receives the Geo Coordinate Attribute in an UPDATE message from a neighbor, it is up to the speaker and the local policy to decide how this attribute would be handled and used. The Geo Coordinate Capability in an OPEN message does not have any impact on how the Geo Coordinate Attribute in an UPDATE message (carried over the same session) would be handled. 5. Error Handling The Geo Coordinate Attribute in an UPDATE message is considered malformed if the attribute length is not a non-zero multiple of 28. An UPDATE message with a malformed Geo Coordinate Attribute SHALL be handled using the approach of "attribute discard" [RFC7606]. 6. IANA Considerations This documents specifies a BGP capability, the Geo Coordinate Capability. The capability type needs to be allocated by IANA. This documents specifies a BGP attribute, the Geo Coordinate Attribute. The attribute type needs to be allocated by IANA. 7. Security Considerations The underlying security issues for BGP are discussed in [RFC4271]. Since the Geo coordinates provide the exact location of the routing devices, disclosure may make the routing devices more susceptible to physical attacks. In situations where this is a concern (e.g., in military applications, or the topology of the network is considered proprietary information), the implementation MUST allow the Geo Location extension to be removed from the BGP's OPEN and UPDATE messages. Chen, Shen & Raszuk [Page 6] Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016 8. Privacy Considerations TBD. 9. Acknowledgments The encoding of the Geo location is adapted from the "Geo Coordinate LISP Canonical Address Format" specified in the "LISP Canonical Address Format (LCAF)". We would like to thank the authors of that Document and particularly Dino Farinacci for subsequent discussions. Thanks to Yi Yang and Acee Lindem for review and discussions of the Geo Coordinate encoding. 10. References 10.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, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC6286] Chen, E., and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Chen, Shen & Raszuk [Page 7] Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016 10.2. Informative References [I-D.ietf-idr-tunnel-encaps] Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-01 (work in progress), December 2015. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7459] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO)", RFC 7459, DOI 10.17487/RFC7459, February 2015, . [RFC7665] Halpern, J., Ed., and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . 11. Authors' Addresses Enke Chen Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: enkechen@cisco.com Naiming Shen Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: naiming@cisco.com Robert Raszuk Bloomberg LP 731 Lexington Ave New York City, NY 10022 USA Chen, Shen & Raszuk [Page 8] Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016 Email:robert@raszuk.net Chen, Shen & Raszuk [Page 9]