IDRNetworking Working GroupQ. WuS. Previdi, Ed. Internet-DraftHuaweiCisco Systems, Inc. Intended status: Standards TrackS. PrevidiQ. Wu Expires:July 8, 2015 CiscoNovember 12, 2016 Huawei H. GredlerJuniperS. RayCiscoJ. TantsuraEricsson January 4, 2015 BGP attribute for North-Bound DistributionIndividual C. Filsfils L. Ginsberg Cisco Systems, Inc. May 11, 2016 BGP-LS Advertisement of IGP Traffic Engineering(TE) performance Metrics draft-ietf-idr-te-pm-bgp-02Performance Metric Extensions draft-ietf-idr-te-pm-bgp-03 AbstractInThis document defines new BGP-LS TLVs in order topopulate network performance information like link latency, latency variation, packet loss and bandwidth intocarry the IGP Traffic EngineeringDatabase(TED)Extensions defined in IS-IS and OSPF protocols. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", andALTO server,"OPTIONAL" in this documentdescribes extensionsare toBGP protocol, that canbeusedinterpreted as described in RFC 2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not todistribute network performance information (suchbe interpreted aslink delay, delay variation, packet loss, residual bandwidth, available bandwidth and utilized bandwidth ).carrying RFC-2119 significance. 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 http://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 onJuly 8, 2015.November 12, 2016. Copyright Notice Copyright (c)20152016 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2.Conventions used in this document . . . . . .Link Attribute TLVs for TE Metric Extensions . . . . . . . . 3 3.Use Cases .TLV Details . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1.MPLS-TE with H-PCE .Unidirectional Link Delay TLV . . . . . . . . . . . . . . 3 3.2. Min/Max Unidirectional Link Delay TLV . . . .3 3.2. ALTO Server Network API. . . . . . 4 3.3. Unidirectional Delay Variation TLV . . . . . . . . . . . 44. Carrying TE Performance information in BGP . .3.4. Unidirectional Link Loss TLV . . . . . . .5 5. Attribute TLV Details. . . . . . . 5 3.5. Unidirectional Residual Bandwidth TLV . . . . . . . . . . 5 3.6. Unidirectional Available Bandwidth TLV . . .6 6. Manageability Considerations. . . . . . 5 3.7. Unidirectional Utilized Bandwidth TLV . . . . . . . . . .7 7.6 4. Security Considerations . . . . . . . . . . . . . . . . . . .7 8.6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79. References . . . . . . . . . . . . . . . . . . . . .6. Acknowledgements . . . .8 9.1. Normative References. . . . . . . . . . . . . . . . . .8 9.2. Informative7 7. References . . . . . . . . . . . . . . . . .8 Appendix A. Change Log . . . . . . . .. . . . . . . . 7 7.1. Normative References . . . . .9 A.1. draft-ietf-idr-te-pm-bgp-00. . . . . . . . . . . . . 7 7.2. Informative References . .9 A.2. draft-ietf-idr-te-pm-bgp-02. . . . . . . . . . . . . . .98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .98 1. IntroductionAs specified in [RFC4655],a Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph,BGP-LS ([RFC7752]) defines NLRI andof applying computational constraints during the computation. Inattributes in order tocompute an end to end path, the PCE needs to have a unified view of the overall topology[I-D.ietf-pce-pcep- service-aware]. [I.D-ietf-idr-ls-distribution] describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This mechanism can be used by both PCE and ALTO server to gather information about the topologies and capabilities of the network. With the growth of network virtualization technology, the Network performance or QoS requirements such as latency, limited bandwidth, packet loss, and jitter, for real trafficcarry link-state information. New BGP-LS Link-Attribute TLVs areall critical factors that must be taken into accountrequired inthe end to end path computation and selection ([I-D.ietf-pce-pcep-service-aware])which enable optimizing resource usage and degrading gracefully during period of heavy load . Inorder topopulate network performance information like link latency, latency variation, packet loss and bandwidth into TED and ALTO server, this document describes extensions to BGP protocol, that can be used to distribute network performance information (such as link delay, delay variation, packet loss, residual bandwidth, available bandwidth, and utilized bandwidth). The network performance information can be distributed incarry thesame way as link state information distribution,i.e., either directly or via a peer BGP speaker (see figure 1 of [I.D-ietf-idr-ls-distribution]). 2. 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 describedTraffic Engineering Metric Extensions defined inRFC2119 [RFC2119]. 3. Use Cases 3.1. MPLS-TE with H-PCE For inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805] may be used to compute the optimal sequence of domains. Within the H-PCE architecture, the child PCE communicates domain connectivity information to the parent PCE,[RFC7810] andthe parent PCE will use this information to compute a multi-domain path based on the optimal TE links between domains [I.D-ietf-pce-hierarchy-extensions][RFC7471]. 2. Link Attribute TLVs forthe end-to-end path. The following figure demonstrates how a parent PCE may obtain TE performance information beyond that contained in the LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the mechanism described in this document. +----------+ +---------+ | ----- | | BGP | | | TED |<-+-------------------------->| Speaker | | ----- | TED synchronization | | | | | mechanism: +---------+ | | | BGP withTEperformance | v | NLRI | ----- | | | PCE | | | ----- | +----------+ ^ | Request/ | Response v Service +----------+ Signaling +----------+ Request | Head-End | Protocol | Adjacent | -------->| Node |<------------>| Node | +----------+ +----------+ Figure 1: External PCE node using a TED synchronization mechanism 3.2. ALTO Server Network API The ALTO Server can aggregate information from multiple systems to provide an abstract and unified view that can be more useful to applications.Metric Extensions The followingfigure shows how an ALTO Server can get TE performance information from the underlying network beyond that contained in the LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the mechanism described in this document. +--------+ | Client |<--+ +--------+ | | ALTO +--------+ BGP with +---------+ +--------+ | Protocol | ALTO | TE Performance | BGP | | Client |<--+------------| Server |<----------------| Speaker | +--------+ | | | NLR | | | +--------+ +---------+ +--------+ | | Client |<--+ +--------+ Figure 2: ALTO Server using network performance information 4. Carrying TE Performance information in BGP This document proposesnewBGP TE performance TLVs that can be announced as attribute in the BGP-LS attribute (defined in [I.D-ietf- idr-ls-distribution]) to distribute network performance information. The extensions in this document build on the ones provided in BGP-LS [I.D-ietf-idr-ls-distribution] and BGP-4 [RFC4271]. BGP-LS attribute defined in [I.D-ietf-idr-ls-distribution] has nested TLVs which allow the BGP-LS attribute to be readily extended. This document proposes seven additionalLink Attribute TLVsas its attributes:are defined: TLV Type ValueTBD1-------------------------------------------------------- 1104 (Suggested) Unidirectional Link DelayTBD21105 (Suggested) Min/Max Unidirectional Link DelayTBD31106 (Suggested) Unidirectional Delay VariationTBD41107 (Suggested) Unidirectional Packet LossTBD51108 (Suggested) Unidirectional Residual BandwidthTBD61109 (Suggested) Unidirectional Available BandwidthTBD71110 (Suggested) UnidirectionalUtilizedBandwidthAs can be seen in the list above, the TLVs described in this document carry different types of network performance information. Some of these TLVs include a bit called the Anomalous (or "A") bit at the left-most bit after length field of each TLV defined in figure 4 of [[I.D-ietf-idr-ls-distribution]]. The other bits in the first octets after length field of each TLV is reserved for future use. When the A bit is clear (or when the TLV does not include an A bit), the TLV describes steady state link performance. This information could conceivably be used to construct a steady state performance topology for initial tunnel path computation, or to verify alternative failover paths. When network performance downgrades and exceeds configurable maximum thresholds, a TLV with the A bit set is advertised. These TLVs could be used by the receiving BGP peer to determine whether to redirect failing traffic to a backup path, or whether to calculate an entirely new path. If link performance improves later and falls below a configurable value, that TLV can be re- advertised with the Anomalous bit cleared. In this case, a receiving BGP peer can conceivably do whatever re-optimization (or failback) it wishes to do (including nothing). Note that when a TLV does not include the A bit, that TLV cannot be used for failover purposes. The A bit was intentionally omitted from some TLVs to help mitigate oscillations. Consistent with existing ISIS TE specifications [ISIS-TE-METRIC], the bandwidth advertisements, the delay and delay variation advertisements, packet loss defined in this document MUST be encoded in the same unit as one defined in IS-IS Extended IS Reachability sub-TLVs [ISIS-TE-METRIC]. All values (except residual bandwidth) MUST be obtained by a filter that is reasonably representative of an average or calculated as rolling averages where the averaging period MUST be a configurable period of time. The measurement interval, any filter coefficients, and any advertisement intervals MUST be configurable per sub-TLV in the same way as ones defined in section 5 of [ISIS-TE-METRIC]. 5. AttributeUtilization 3. TLV Details 3.1. Unidirectional Linkattribute TLVs defined in section 3.2.2 of [I-D.ietf-idr-ls- distribution]are TLVs that may be encoded inDelay TLV This TLV advertises theBGP-LS attribute with aaverage linkNLRI. Each 'Link Attribute' is a Type/Length/ Value (TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf-idr- ls-distribution].delay between two directly connected IGP link-state neighbors. Theformat and semanticssemantic of the'value' fieldsTLV is described in'Link Attribute' TLVs correspond to the format[RFC7810] andsemantics of value fields in IS-IS Extended IS Reachability sub-TLVs, defined in [RFC5305]. Although the encodings for 'Link Attribute' TLVs were originally defined for IS-IS, the TLVs can carry data sourced either by IS-IS or OSPF. The following 'Link Attribute' TLVs are valid in the LINK_STATE attribute: +------------+---------------------+--------------+-----------------+ | TLV Code | Description | IS-IS | Defined in: | | Point | | TLV/Sub-TLV | | +------------+---------------------+--------------+-----------------+ | xxxx | Unidirectional | 22/xx[RFC7471]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |[ISIS-TE-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| RESERVED |LinkDelay || METRIC]/4.1 | | | | | | | xxxx |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Figure 1 Type: TBA (suggested value: 1104). Length: 4. 3.2. Min/MaxUnidirection| 22/xx | [ISIS-TE- | | |Unidirectional Link Delay TLV This sub-TLV advertises the minimum and maximum delay values between two directly connected IGP link-state neighbors. The semantic of the TLV is described in [RFC7810] and [RFC7471]. 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 |METRIC]/4.2 | |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| RESERVED | Min Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED |xxxxMax Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Figure 2 Type: TBA (suggested value: 1105). Length: 8. 3.3. Unidirectional| 22/xx | [ISIS-TE- | | |Delay Variation TLV This sub-TLV advertises the average link delay variation between two directly connected IGP link-state neighbors. The semantic of the TLV is described in [RFC7810] and [RFC7471]. 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 |METRIC]/4.3 | | | |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED |xxxxDelay Variation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Figure 3 Type: TBA (suggested value: 1106). Length: 4. 3.4. Unidirectional Link Loss TLV This sub-TLV advertises the loss (as a packet percentage) between two directly connected IGP link-state neighbors. The semantic of the TLV is described in [RFC7810] and [RFC7471]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |22/xx | [ISIS-TE-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| RESERVED | Link Loss || METRIC]/4.4 | | | | | | | xxxx |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBA (suggested value: 1107). Length: 4. 3.5. Unidirectional| 22/xx | [ISIS-TE- | | |ResidualResidual Bandwidth TLV This sub-TLV advertises the residual bandwidth between two directly connected IGP link-state neighbors. The semantic of the TLV is described in [RFC7810] and [RFC7471]. 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 |METRIC]/4.5 | | | | |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |xxxxResidual Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBA (suggested value: 1108). Length: 4. 3.6. Unidirectional| 22/xx | [ISIS-TE- | | |AvailableAvailable Bandwidth TLV This sub-TLV advertises the available bandwidth between two directly connected IGP link-state neighbors. The semantic of the TLV is described in [RFC7810] and [RFC7471]. 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 |METRIC]/4.6 | | | | |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |xxxxAvailable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Figure 4 Type: TBA (suggested value: 1109). Length: 4. 3.7. Unidirectional Utilized Bandwidth TLV This sub-TLV advertises the bandwidth utilization between two directly connected IGP link-state neighbors. The semantic of the TLV is described in [RFC7810] and [RFC7471]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |22/xxType |[ISIS-TE-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||UtilizedUtilized Bandwidth || METRIC]/4.7 | +------------+---------------------+--------------+-----------------+ Table 1: Link Attribute TLVs 6. Manageability Considerations Manageability+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Figure 5 Type: TBA (suggested value: 1110). Length: 4. 4. Security ConsiderationsdescribedProcedures and protocol extensions defined in this document do not affect the BGP security model. See the 'Security Considerations' section of [RFC4271] for a discussion of BGP security. Also refer to [RFC4272] and [RFC6952] for analysis of security issues for BGP. The TLVs introduced insection 6.2this document are used to propagate IGP defined information ([RFC7810] and [RFC7471].) These TLVs represent the state and resources availability of[I-D.ietf- idr-ls-distribution] can be appliedthe IGP link. The IGP instances originating these TLVs are assumed toTraffic Engineering (TE) performance Metrics as well. 7. Security Considerations This document does not introducehave all the required securityissues beyond those discussedand authentication mechanism (as described in[I.D-ietf-idr-ls-distribution][RFC7810] and[RFC4271]. 8.[RFC7471]) in order to prevent any security issue when propagating the TLVs into BGP-LS. 5. IANA ConsiderationsIANA maintainsThis document requests assigning code-points from the registry "BGP- LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" for theTLVs. BGP TE Performance TLV will require onenewtype code per TLV definedLink Attribute TLVs deefined inthis document. 9.the table here below: TLV code-point Value -------------------------------------------------------- 1104 (Suggested) Unidirectional Link Delay 1105 (Suggested) Min/Max Unidirectional Link Delay 1106 (Suggested) Unidirectional Delay Variation 1107 (Suggested) Unidirectional Packet Loss 1108 (Suggested) Unidirectional Residual Bandwidth 1109 (Suggested) Unidirectional Available Bandwidth 1110 (Suggested) Unidirectional Bandwidth Utilization 6. Acknowledgements TBD 7. References9.1.7.1. Normative References[I-D.ietf-idr-ls-distribution] Gredler, H., "North-Bound Distribution of Link-State and TE Information using BGP", ID draft-ietf-idr-ls- distribution-07, November 2014. [I-D.ietf-pce-pcep-service-aware] Dhruv, D., "Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP)", ID draft-ietf-pce-pcep- service-aware-06, December 2014. [ISIS-TE-METRIC] Giacalone, S., "ISIS Traffic Engineering (TE) Metric Extensions", ID draft-ietf-isis-te-metric-extensions-04, October 2014.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March1997.1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January2006. [RFC5305] Li, T.,2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <http://www.rfc-editor.org/info/rfc7471>. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>. [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-ISExtensions forTrafficEngineering",Engineering (TE) Metric Extensions", RFC5305, October 2008. 9.2.7810, DOI 10.17487/RFC7810, May 2016, <http://www.rfc-editor.org/info/rfc7810>. 7.2. Informative References[ALTO] Yang, Y., "ALTO Protocol", ID http://tools.ietf.org/html/draft-ietf-alto-protocol-16, May 2013. [I.D-ietf-pce-hierarchy-extensions] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., and D. King, "Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)", ID draft-ietf-pce-hierarchy- extensions-01, February 2014. [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based Architecture",[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC4655, August 2006. Appendix A. Change Log Note to the RFC-Editor: please remove this section prior4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>. [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According topublication as an RFC. A.1. draft-ietf-idr-te-pm-bgp-00 The following arethemajor changes compared to previous version draft-wu-idr-te-pm-bgp-03: o Update PCE case in section 3.1. o Add some texts in section 1 and section 4 to clarify from where to distribute pm info and measurement intervalKeying andmethod. A.2. draft-ietf-idr-te-pm-bgp-02 The following are the major changes compared to previous version draft-wu-idr-te-pm-bgp-03: o Some Editorial changes.Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>. Authors' Addresses Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico 200 Rome 00191 IT Email: sprevidi@cisco.com Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.comStefano Previdi Cisco Systems, Inc. Via Del Serafico 200 Rome 00191 Italy Email: sprevidi@cisco.comHannes GredlerJuniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USIndividual AT Email:hannes@juniper.nethannes@gredler.at Saikat RayCisco Systems, Inc. 170, West Tasman Drive San Jose, CA 95134Individual US Email:sairay@cisco.comraysaikat@gmail.com Jeff TantsuraEricsson 300 Holger Way San Jose, CA 95134Individual US Email: jefftant@gmail.com Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Les Ginsberg Cisco Systems, Inc. US Email:jeff.tantsura@ericsson.comginsberg@cisco.com