idnits 2.17.1 draft-litkowski-idr-bgp-timestamp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 44 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: For a manageability/security purpose, the authors suggest that BGP timestamp attribute MAY NOT be sent to a peer unless it was explicitly configured for. This would prevent timestamp and internal address informations to be propagated to some external peers for example. See Section 5.7 for more information. -- The document date (March 23, 2015) is 3315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-grow-bmp-07 == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-18 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Working Group S. Litkowski 3 Internet-Draft Orange Business Service 4 Intended status: Standards Track K. Patel 5 Expires: September 24, 2015 Cisco Systems 6 J. Haas 7 Juniper Networks 8 March 23, 2015 10 Timestamp support for BGP paths 11 draft-litkowski-idr-bgp-timestamp-02 13 Abstract 15 BGP is more and more used to transport routing information for 16 critical services. Some BGP updates may be critical to be received 17 as fast as possible : for example, in a layer 3 VPN scenario where a 18 dual-attached site is loosing primary connection, the BGP withdraw 19 message should be propagated as fast as possible to restore the 20 service. The same criticity exists for other address-families like 21 multicast VPNs where "join" messages should also be propagated very 22 fast. 24 Experience of service providers shows that BGP path propagation time 25 may vary depending on network conditions (especially load of BGP 26 speaker on the path) and too long propagation time are affecting 27 customer service. 29 It is important for service providers to keep track of BGP updates 30 propagation time to monitor quality of service for the customers. It 31 is also important to be able to identify BGP Speakers that are 32 slowing down the propagation. 34 This document presents a solution to transport timestamps of a BGP 35 path. The solution is targeted to be used using special identified 36 beacon prefixes that are single-homed. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on September 24, 2015. 61 Copyright Notice 63 Copyright (c) 2015 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Requirements for monitoring BGP path propagation time . . . . 4 80 2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 81 2.2. Measurement accuracy . . . . . . . . . . . . . . . . . . 6 82 2.2.1. Clock synchronization . . . . . . . . . . . . . . . . 6 83 2.2.2. Beacon accuracy . . . . . . . . . . . . . . . . . . . 6 84 2.3. Churn . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 2.4. Path propagation complexity . . . . . . . . . . . . . . . 7 86 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 4. BGP timestamp attribute . . . . . . . . . . . . . . . . . . . 9 88 5. Processing the BGP timestamp attribute . . . . . . . . . . . 10 89 5.1. Inspection list . . . . . . . . . . . . . . . . . . . . . 10 90 5.2. Originating a timestamped route in BGP . . . . . . . . . 11 91 5.3. Receiving a timestamped route in BGP . . . . . . . . . . 11 92 5.4. Sending a timestamped route in BGP . . . . . . . . . . . 13 93 5.4.1. Propagating the BGP Timestamp attribute . . . . . . . 13 94 5.4.2. Setting the send timestamp . . . . . . . . . . . . . 13 95 5.5. Limiting churn . . . . . . . . . . . . . . . . . . . . . 14 96 5.6. Marking stale entries . . . . . . . . . . . . . . . . . . 15 97 5.7. Inter-AS considerations . . . . . . . . . . . . . . . . . 19 98 5.7.1. Drop option . . . . . . . . . . . . . . . . . . . . . 19 99 5.7.2. Drop AS option . . . . . . . . . . . . . . . . . . . 20 100 5.7.3. Summary option . . . . . . . . . . . . . . . . . . . 21 101 5.7.4. Propagate option . . . . . . . . . . . . . . . . . . 22 102 5.8. Retrieving timestamp vector . . . . . . . . . . . . . . . 23 103 5.9. Handling malformed attribute . . . . . . . . . . . . . . 23 104 5.10. Impact on update packing . . . . . . . . . . . . . . . . 23 105 6. Compared to BMP . . . . . . . . . . . . . . . . . . . . . . . 23 106 7. Deployment considerations . . . . . . . . . . . . . . . . . . 24 107 8. Security considerations . . . . . . . . . . . . . . . . . . . 25 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 110 11. Normative References . . . . . . . . . . . . . . . . . . . . 25 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 113 1. Problem statement 115 CE3----PE3 PE4 --- CE4 (Source) 116 \ / 117 RR3 RR4 118 \ / 119 RR5 120 / \ 121 RR1 RR2 122 / | \ 123 / | \ 124 CE1----PE1 PE5 PE2 --- CE2 125 | 126 CE5 128 Figure 1 130 The figure 1 describes a typical hierarchical RR design where PEs are 131 meshed to local RRs and local RRs are meshed to more centric RRs. We 132 consider a single multicast VPN between all CEs. CE4 is the source, 133 all others may be receivers. The BGP controlplane also supports some 134 other BGP service like L3VPN service. 136 We consider an event in L3VPN service leading to RR1 being 137 temporarily overloaded (for example, RR1 is processing massive 138 updates due to a router failure or formatting updates for a route- 139 refresh). In the same timeframe, CE1 wants to join the multicast 140 flow from CE4. PE1 propagates the C-multicast route to RR1, but RR1 141 fails to propagate the route to RR5 because it is busy processing 142 L3VPN. When RR1 finishes the L3VPN job, it would send the 143 C-multicast route to RR5 and updates would be imported by PE4. The 144 long time to join the flow may cause CE4 to miss part of the 145 multicast flow. 147 All BGP implementations are different in term of internal processing 148 within an address family or between address family. The issue 149 described above is just given as an example, and the document does 150 not presume that all implementations are suffering from this exact 151 issue. But whatever the implementation, their always be cases where 152 BGP path propagation could be delayed. 154 Service providers currently lack of efficient solution to keep track 155 of BGP path propagation time as well as solution to identify the BGP 156 speakers causing issues. 158 BMP (BGP Monitoring Protocol) may be a solution but as several 159 drawbacks (see Section 6). 161 2. Requirements for monitoring BGP path propagation time 163 2.1. Architecture 165 --------- ------- 166 / \ / \ 167 RTR_SRC1 ----- | AS1 | ----- | AS2 | ---- RTR_DST1 168 | \ / \ / | 169 Inject --------- --------- Sink point 170 point | | 171 | | 172 --------- ------- 173 / \ / \ 174 RTR_DST2 ---- | AS4 | | AS3 | ---- RTR_SRC2_DST2 175 | \ / \ / | 176 Sink point --------- --------- Inject/Sink 177 point 178 Figure 2 180 Single AS 181 ------------------------------------------- 182 / \ 183 | RR1 ---------- RR2 | 184 | / \ \ | 185 | RTR_SRC1 \ RTR_DST2 | 186 | | \ | | 187 | Inject RR3 Sink point | 188 | point | | 189 | RTR_DST1 | 190 | | | 191 \ Sink point / 192 ------------------------------------------- 193 Figure 3 195 Figure 2 and Figure 3 describes an interAS and a single AS scenario 196 where a service provider wants to monitor BGP path propagation time 197 from a router to multiple routers. In Figure 2, multiple probing 198 routers are attached to multiple ASes. In Figure 3, all probing 199 routers are in the same AS. 201 The architecture requires some BGP Speaker to originate some NLRI 202 within the BGP controlplane. In the diagram above, they are 203 identified as "Inject point". In order to provide information about 204 propagation delays, the architecture requires introduction of 205 timestamp information. Architecture also needs to identify BGP 206 Speaker causing high propagation delays. As only, specific 207 advertisement will serve for measurement, the architecture requires 208 BGP Speaker to identify NLRIs that must be timestamped. The 209 architecture also requires some BGP Speaker to serve as sink point 210 where a timestamp vector information can be retrieved. The timestamp 211 vector must contain propagation time information for all BGP Speaker 212 that participated in the BGP path. It is so required that each BGP 213 Speaker along the path to add timestamp information. There may be 214 multiple sink points in the network to perform measurement at 215 different location and also different inject points. An external 216 tool may be connected to Sink Points to retrieve the timestamp 217 information. But this is out of scope of the document. 219 In case of interAS, for security reason, the architecture MUST 220 support hiding detailed timestamp information to the other AS. 222 Example of usage : 224 An external tool should command RTR_SRC to originate a probing BGP 225 NLRI. All the BGP Speakers are configured to measure timestamp for 226 this NLRI. The BGP path would propagate across BGP Speakers. Each 227 BGP Speaker may provide timestamp informations. An external tool 228 connected to sink points will retrieve timestamp vector information 229 for the NLRI. 231 2.2. Measurement accuracy 233 2.2.1. Clock synchronization 235 For the solution to be accurate, it is mandatory for BGP Speaker to 236 be synchronized. This could be ensured easily within a single AS but 237 in a inter domain scenario, it is hard to ensure that all Speakers 238 are synchronized to a good clock source. 240 The solution MUST include synchronization information associated with 241 the timestamp in order to be able to compare timestamps between them. 243 2.2.2. Beacon accuracy 245 In order to be accurate, an implementation SHOULD : 247 o ensure that the timestamped NLRIs are processed with the same 248 priority as non timestamped NLRIs. 250 o ensure that the processing of adding timestamp information is as 251 lightweight as possible. If some limitation exists, the vendor 252 SHOULD document them. 254 Using a unique special prefix advertisement from a single location to 255 evaluate propagation time will not provide a detail view of min/max 256 propagation time values as the user will not know where the path for 257 the prefix may be located in a processing queue. Considering a BGP 258 Speaker handling high churn, the advertisement of the path for the 259 special prefix may have a specific place in the long processing queue 260 of the churn depending on the implementation : it may be first, last 261 or somewhere in the middle. 263 It is required from user to perform sampling to establish propagation 264 time boundaries based on multiple advertisements. Repeated 265 operations of advertisement then withdraw may help in this. See 266 Section 7 for more details. 268 2.3. Churn 270 The target solution MUST NOT create more churn in the BGP 271 controlplane. 273 2.4. Path propagation complexity 275 When a NLRI is originated in BGP from a point, a BGP path is created. 276 Nothing ensures that all nodes within the BGP controlplane will 277 receive this BGP path. When a concurrent path already exists from 278 the NLRI, the concurrent path may be prefered by some BGP Speaker 279 leading to hiding of the new path. Moreover, even if the NLRI is 280 originated in BGP from a single point, multiple paths may be created 281 within the BGP controlplane, this is inherent to the BGP meshing in 282 place. 284 As soon as multiple BGP paths are involved, controlplane convergence 285 may be done in multiple steps in order to find the final best path. 286 This convergence may involve multiple BGP path advertisement 287 (replacing each other) between peers. 289 The goal of our proposal is not to measure the convergence time but 290 to focus on the path propagation time. In a controlplane convergence 291 involving multiple paths for a NLRI, the solution MUST identify 292 timestamp for the event where the NLRI was seen for the first time on 293 a BGP Speaker. 295 Example : 297 Single AS 298 ------------------------------------------- 299 / RTR_SRC2- 10/8 \ 300 | / | 301 | RR1 ---------- RR2 | 302 | / \ \ | 303 | RTR_SRC1 \ RTR_DST2 | 304 | | \ | 305 | 10/8 RR3 | 306 | | | 307 | RTR_DST1 | 308 | | 309 \ / 310 ------------------------------------------- 312 Figure 4 314 In the figure above, consider that the service provider is keep 315 tracking of propagation time for real NLRIs (corresponding to 316 customer routes). All the BGP Speakers in our figure are configured 317 to inspect the NLRI 10/8 which is multihomed. We consider that the 318 network is starting and the NLRI has not been propagated yet. 320 RTR_SRC1 starts to propagate 10/8 within the BGP controlplane. All 321 BGP Speakers considers the path as best and this path will be 322 propagated within the whole controlplane. Each BGP Speaker would add 323 its timestamp information and RTR_DST1 and RTR_DST2 would be able to 324 record the timestamp vector. In this case, the timestamp vector is 325 quite accurate because it represents an end to end propagation. 327 Now RTR_SRC2 starts to propagate its own path. RR2 has two paths for 328 10/8 and will choose the best one, let's consider that RTR_SRC2 path 329 is the best one, RTR_SRC2 path will so be propagated and timestamp 330 vector will be updated. RR1 will also have two paths, and we 331 consider that RR1 prefers RTR_SRC1 path, so RTR_SRC2 path will not be 332 propagated by RR1. In this situation, RTR_DST2 will receive the path 333 from RR2 with accurate timestamp (end to end propagation) but 334 RTR_DST1 will never receive it. 336 We could also consider a stable network situation, where both paths 337 have been advertised for a long time. A network event may occur 338 (e.g. IGP metric change) that would cause a BGP Speaker within a 339 path vector to change its best path. In Figure 10, an IGP event, may 340 cause RR1 to change its decision and prefers the path originated by 341 RTR_SRC2 as best, the path will be propagated with previous received 342 timestamp information that are no more accurate. RTR_DST1 will 343 receive a BGP timestamp vector containing stale (old) timestamp 344 informations as well as new ones. 346 3. Proposal 348 Our proposal is based on tagging NLRI with timestamp values along its 349 BGP path propagation. Each BGP Speaker along the path will add 350 timestamp values, so creating a timestamp vector. An ordered list of 351 timestamps would so be built along the path. 353 BGP Update BGP Update BGP Update BGP Update 354 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 355 Timestamp: Timestamp: Timestamp: Timestamp: 356 R1:T1 R1:T1 R1:T1 R1:T1 357 R2:T2 R2:T2 R2:T2 358 R3:T3 R3:T3 359 R4:T4 360 R1 ------------> R2 ------------> R3 ------------> R4 ------------> R5 362 Using this mechanism, we can easily identify if a hop within a path 363 is slowing down the propagation. 365 We propose to use a new BGP attribute, BGP timestamp attribute to 366 encode timestamps information. 368 4. BGP timestamp attribute 370 The BGP timestamp (BGP-TS) Attribute is an optional transitive BGP 371 Path Attribute. The attribute type code is TBD. 373 The value field of the BGP timestamp attribute is defined as an 374 ordered list of timestamp entries, the first entry being the first 375 timestamp entry added (origin): 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Timestamp #1 (variable) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Timestamp #2 (variable) | 383 ... 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Timestamp #n (variable) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 The timestamps entries are encoded as follows : 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Receive Timestamp #x | 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Send Timestamp #x | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | ASN | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 |T| Rsvd | SyncType | EntryType | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 403 | | 404 | Optional variable field | 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 o Receive timestamp : the time at which the BGP path was received. 409 When originating a path in BGP, the timestamp is the originating 410 time. Expressed in seconds and microseconds since midnight (zero 411 hour), January 1, 1970 (UTC). If zero, the time is unavailable. 412 Precision of the timestamp is implementation- dependent. 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Timestamp (seconds) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Timestamp (microseconds) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 o Send timestamp : the time at which the BGP path was exported to 422 the peer. Expressed in seconds and microseconds since midnight 423 (zero hour), January 1, 1970 (UTC). If zero, the time is 424 unavailable. Precision of the timestamp is implementation- 425 dependent. 427 o ASN : AS Number of the local node creating the timestamp entry. 429 o Flags : 431 * T : Synchronized, if set, the BGP speaker clock is synchronized 432 to an external system. 434 o SyncType : defines the stratum as defined in [RFC5905]. 436 o EntryType : defines the type of Timestamp entry, the following 437 types are defined : 439 * Type 0 : empty. There is no following variable field. This 440 type is to be used in case of timestamp summarization. 442 * Type 1 : IPv4 address, the following variable field will be 4 443 bytes long and will contain the IPv4 router ID of the local 444 node. 446 * Type 2 : IPv6 address, the following variable field will be 16 447 bytes long and will contain the IPv6 router ID of the local 448 node. 450 * Type 3 : Stale Indicator, Stale indicates that previous 451 timestamp entries are old. There is no following variable 452 field. The receive timestamp and send timestamp should be set 453 to zero. The ASN is set to the ASN of the local BGP Speaker. 455 5. Processing the BGP timestamp attribute 457 5.1. Inspection list 459 A BGP Speaker supporting the BGP-TS can decide to timestamp only some 460 specific NLRIs. An inspection list may be configured by the user 461 (filter) to apply timestamping on a specific set of BGP NLRIs. By 462 default, we suggest that a BGP Speaker supporting BGP-TS SHOULD NOT 463 timestamp any BGP NLRIs. 465 User of our proposal must be aware that using a complex policy to 466 express inspection list may result in more processing that will 467 influence the end to end propagation time. It is expected that the 468 inspection list policy should be kept as simple as possible. 470 5.2. Originating a timestamped route in BGP 472 When a BGP Speaker supporting BGP-TS originates a new path in BGP 473 that matches the inspection list, it MUST add the BGP-TS attribute to 474 the BGP path and MUST set the receive timestamp field to the time the 475 path was originated in BGP. At this time of processing, the send 476 timestamp will be set to 0. If the BGP Speaker is synchronized to an 477 external system when originating the route, the S-bit MUST be set in 478 the attribute and the SyncType MUST be set to the current stratum. 479 As mentioned above, the BGP path of the originated route will have a 480 send timestamp value of zero in the BGP LOC-RIB. 482 5.3. Receiving a timestamped route in BGP 484 When a BGP Speaker supporting BGP-TS receives a BGP path that matches 485 the inspection list, the implementation MUST record the current time 486 associated with the received path. 488 The time recording MUST append before the inbound routing policies. 490 Inspection 491 List 492 +------------+ +---+ No match +------------+ 493 --> | Adj-RIB-in | --> | I | -------------> | Rtg pol in | 494 | Peer#1 | | n | | Peers#1 | -----> 495 +------------+ | s | +-------+ | | 496 | p | --> | AddTS |->| | 497 | e | +-------+ +------------+ 498 | c | If match 499 | t | 500 | | 501 | l | 502 +------------+ | i | No match +------------+ 503 --> | Adj-RIB-in | --> | s | -------------> | Rtg pol in | 504 | Peer#2 | | t | | Peers#2 | -----> 505 +------------+ | | +-------+ | | 506 | | --> | AddTS |->| | 507 | | +-------+ +------------+ 508 | | If match 509 +---+ 511 If the path that matches the inspection list and does not contains a 512 BGP-TS attribute, it MUST add a BGP-TS attribute with a timestamp 513 entry : 515 o The receive timestamp MUST be set to the recorded time for this 516 BGP path. 518 o If the BGP Speaker is synchronized to an external system when 519 receiving the route, the S-bit MUST be set in the attribute and 520 the SyncType MUST be set to the current stratum. 522 o The send timestamp MUST be set to zero. 524 If the path that matches the inspection list and contains a BGP-TS 525 attribute, it MUST append a new timestamp entry in the existing 526 attribute : 528 o The receive timestamp MUST be set to the recorded time for this 529 BGP path. 531 o If the BGP Speaker is synchronized to an external system when 532 receiving the route, the S-bit MUST be set in the attribute and 533 the SyncType MUST be set to the current stratum. 535 o The send timestamp MUST be set to zero. 537 The process of adding a timestamp entry or adding BGP-TS attribute 538 SHOULD be as light as possible in order to influence the propagation 539 time as lowest as possible. 541 When a BGP Speaker supporting BGP-TS receives a BGP path that does 542 not the inspection list and contains a BGP-TS attribute, it MUST NOT 543 change the existing attribute. 545 When a BGP Speaker not supporting BGP-TS receives a BGP path that 546 contains a BGP-TS attribute, it MUST follow the standard BGP 547 procedures described in [RFC4271]. 549 5.4. Sending a timestamped route in BGP 551 5.4.1. Propagating the BGP Timestamp attribute 553 For a manageability/security purpose, the authors suggest that BGP 554 timestamp attribute MAY NOT be sent to a peer unless it was 555 explicitly configured for. This would prevent timestamp and internal 556 address informations to be propagated to some external peers for 557 example. See Section 5.7 for more information. 559 If a BGP path containing a BGP-TS attribute must be sent to be peer 560 not configured with BGP timestamp option, the BGP-TS attribute should 561 be dropped when the update message is sent to the peer. 563 5.4.2. Setting the send timestamp 565 If sending timestamp attribute is authorized for a specific peer, and 566 path has a BGP-TS attribute, the outgoing BGP processing MUST fill 567 the send timestamp field when exporting the path to a peer. The time 568 recording MUST occur after all BGP filtering policies (outgoing 569 routing policies, ORF, ...) and after placing path in Adj-RIB-Out. An 570 implementation SHOULD set timestamp at the nearest possible step 571 before sending the BGP Update to the peer. Depending of the 572 implementation, the timestamping may occur at different stage of the 573 outgoing BGP processing. Each implementer SHOULD document their 574 timestamping process in order to make users understand correctly 575 timestamp values. As most of implementations are using the concept 576 of peer-groups, in case, timestamp is set too early in the BGP 577 outgoing processing, all peers within a group may have the same 578 timestamp value. Implementation should avoid this. 580 The process of adding the send timestamp must be as light as possible 581 in order to influence the propagation time as lowest as possible. 583 +------+ 584 | | +--------+ +-----+ +---+ +-------+ No TS 585 | | --> | Rtgpol | --> | ORF | --> |...|-->|Adj-RIB|--------------> 586 | | | Out | |P#1 | | | |Out | Send to peer 587 | | | Peer#1 | | | | | |Peer#1 | +-----+ 588 | | | | | | | | | |-->|AddTS| ---> 589 | | +--------+ +-----+ +---+ +-------+ +-----+ 590 | | TS present 591 | BGP | 592 | LOC | 593 | RIB | 594 | | 595 | | +--------+ +-----+ +---+ +-------+ No TS 596 | | --> | Rtgpol | --> | ORF | --> |...|-->|Adj-RIB|--------------> 597 | | | Out | |P#2 | | | |Out | Send to peer 598 | | | Peer#2 | | | | | |Peer#2 | +-----+ 599 | | | | | | | | | |-->|AddTS| ---> 600 | | +--------+ +-----+ +---+ +-------+ +-----+ 601 | | TS present 602 +------+ 604 5.5. Limiting churn 606 Adding timestamp informations to BGP path will make all received 607 paths to be unique. 609 RR1 610 / \ 611 10/8 - R1 RR3 --- R3 612 \ / 613 RR2 615 In the figure above, we consider that RR1 and RR2 are part of the 616 same cluster (cluster ID : 1). RR3 is client of RR1 and RR2. R3 is 617 client from RR3, R1 is client from RR1 and RR2. 619 Without BGP timestamp, when R1 originates the BGP prefix 10/8, it 620 sends it to RR1 and RR2. Consider that RR3 receives path from RR1 621 first, it will reflect it to R3. When it will receive the path from 622 RR2, it may consider that path from RR2 is best (lowest router ID) 623 but as BGP attributes of the path are exactly the same as for RR1 624 path, there is no need to send an update to R3. 626 With BGP timestamp, when R1 originates the BGP prefix 10/8, it sends 627 it to RR1 and RR2. Consider that RR3 receives path from RR1 first, 628 it will reflect it to R3. When it will receive the path from RR2, it 629 may consider that path from RR2 is best (lowest router ID) but as BGP 630 attributes of the two paths are not more equal due to the timestamp 631 difference, RR3 may need to advertise an update to R3. 633 In order to prevent introducing more churn, we propose to modify the 634 behavior described in Section 9.2. of [RFC4271]. An implementation 635 MUST NOT consider BGP-TS attribute when evaluating the need to send a 636 new update. As the BGP-TS attribute is purely informational, even if 637 BGP Speakers have a different view of the timestamp attribute, there 638 will be no impact on routing. 640 Considering our example, when RR3 will receive the path from RR2, 641 even if it considers RR2 path as best, it will not send an update to 642 R3 as all the attributes, except BGP-TS are equal. 644 5.6. Marking stale entries 646 Section 2.4 describes some cases where advertised timestamp 647 information is no more relevant because it is old and also requires 648 identification of first propagation timestamps. 650 In order to do this, we propose to mark old entries by adding a Stale 651 Indicator within the timestamp vector. The presence of Stale 652 Indicator must be interpreted as all previous timestamp entries need 653 to be considered as old and not considered as a first propagation. 655 BGP-TS attribute example : 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 660 | Timestamp #1 (IPv4) | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old 662 | Timestamp #2 (IPv4) | | entries 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 664 | Timestamp #3 (IPv4) | | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 666 | Timestamp #4 (Stale Indicator) | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 668 | Timestamp #5 (IPv4) | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usable 670 ... ...entries 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 672 | Timestamp #n (variable) | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 674 Insertion of Stale Indicator in a BGP-TS attribute may happen in the 675 following conditions : 677 o A path is received from a peer containing BGP-TS attribute or 678 originated locally, the path matches the inspection list, and the 679 decision process does not select the path as best path. Then the 680 Stale Indicator SHOULD be inserted after decision process 681 happened. 683 o A path is received from a peer containing BGP-TS attribute or 684 originated locally, the path matches the inspection list, and the 685 decision process does select the path as best path. The path is 686 exported to peers and then the Stale Indicator MUST be inserted. 687 The path MUST NOT be repropagated as per Section 5.5. 689 When inserting a Stale indicator, if a Stale Indicator already exists 690 in the timestamp vector, the implement SHOULD remove it before adding 691 the new one. 693 BGP Update BGP Update 694 10/8 10/8 695 NH R2 NH=R1 696 ASP : 2 ASP : 1,2 697 Origin IGP Origin IGP 698 BGP-TS : BGP-TS : 699 [TS_entry1:IPv4] [TS_entry1:IPv4] 700 [TS_entry2:IPv4] [TS_entry2:IPv4] 701 [TS_entry3:Stale] [TS_entry3:Stale] 702 [TS_entry4:IPv4] [TS_entry4:IPv4] 703 [TS_entry5:IPv4] [TS_entry5:IPv4] 704 [TS_entry6:IPv4] 706 BGP BGP Speaker BGP Speaker 707 Speaker R1 R3 708 R2 +---------------------------+ 709 -----------------> | | ------------> 710 | BGP Path | 711 | At reception | 712 | +-----------------------+ | 713 | | 10/8, from R2 | | 714 | | BGP-TS : | | 715 | | [TS_entry1:IPv4] | | 716 | | [TS_entry2:IPv4] | | 717 | | [TS_entry3:Stale] | | 718 | | [TS_entry4:IPv4] | | 719 | | [TS_entry5:IPv4] | | 720 | | [TS_entry6:IPv4]<-| | New timestamp entry 721 | +-----------------------+ | created by R1 722 | | 723 | BGP Path | 724 | after sending to peer | 725 | Stale state is added | 726 | +-----------------------+ | 727 | | 10/8, from R2 | | 728 | | BGP-TS : | | 729 | | [TS_entry1:IPv4] | | 730 | | [TS_entry2:IPv4] | | 731 | | [TS_entry4:IPv4] | | 732 | | [TS_entry5:IPv4] | | 733 | | [TS_entry6:IPv4]<-| | New timestamp entry 734 | | [TS_entry7:Stale] | | created by R1 735 | +-----------------------+ | 736 +---------------------------+ 738 In the example above, R2 sends a BGP path with some existing stale 739 timestamps. When R1 receives the route, it creates a new timestamp 740 entry in the BGP-TS attribute. We consider that the decision process 741 decides that the path is best, the path is exported with the new 742 timestamp entry and old timestamps coming from R2. Then R1 will 743 update its local path by removing the previous Stale Indicator and 744 replace a new one at the latest position to mark that it is no more 745 the first propagation. 747 Single AS 748 ---------------------------- 749 / RTR_SRC2- 10/8 \ 750 | / | 751 | RR1 | 752 | / \ | 753 | RTR_SRC1 \ | 754 | | \ | 755 | 10/8 RR3 | 756 | | | 757 | RTR_DST1 | 758 \ / 759 ---------------------------- 761 In the figure above, we consider that all BGP Speaker apply timestamp 762 for prefix 10/8. RTR_SRC1 originates 10/8 in BGP, the decision 763 process will decide that the path is best. RTR_SRC1 will export path 764 to RR1 and then it will add locally the Stale Indicator within the 765 timestamp vector. The path exported does not have the Stale 766 Indicator. RR1 will receive the path and add a timestamp entry, the 767 path is considered as best, RR1 will export it to RTR_SRC2 and RR3 768 and then it will add a stale indicator. RR3 will proceed in the same 769 way. 771 When RTR_SRC2 will originate a new path for 10/8, if this new path is 772 best on RTR_SRC2, it will export the path to RR1 and then it will add 773 locally the Stale Indicator to the path. When RR1 will receive the 774 route : 776 o If the path from RTR_SRC2 is best, RR1 will export the new path to 777 RTR_SRC1 and RR3 and then will add Stale indicator to the path.If 778 RTR_SRC2 fails after some time, RR1 will pick up RTR_SRC1 path as 779 best, and will export it to RR3. RR3 will know that the received 780 timestamp entries are stale thanks to the stale indicator. 782 o If the path from RTR_SRC2 is not best, RR1 will add Stale 783 indicator to the path. If RTR_SRC1 fails after some time, RR1 784 will pick up RTR_SRC2 path as best, and will export it to RR3. 785 RR3 will know that the received timestamp entries are stale thanks 786 to the stale indicator. 788 5.7. Inter-AS considerations 790 BGP update 791 10.0.0.0/8 792 TS: 793 AS3;CE1:rT1,sT2 795 CE1--------->R1 ------------> R2 ------------> R3 ------------> R4 -------> CE2 796 | | | | 797 | | | | 798 AS3 AS1 AS2 AS4 800 In the figure above, we consider that customer wants to monitor BGP 801 updates propagation time between its two sites. 803 If AS1 and AS2 BGP Speakers does not support BGP-TS, the attribute 804 will be transported transparently accross AS1 without any processing. 805 CE2 will so receive the BGP path with only a single timestamp entry 806 from CE1. 808 If AS1 and AS2 BGP Speakers does support BGP-TS, four different 809 options are offered : drop, drop-as, summarize, propagate. It must 810 be noted that using drop-as or summarize options may involve more 811 processing and so may impact the end to end propagation time. 813 5.7.1. Drop option 815 If AS1 and/or AS2 BGP Speakers support BGP-TS, they may not want to 816 expose any timestamp information between each other. If a service 817 does not want to propagate timestamp information to external peers, 818 it can decide to not activate the "timestamp" option on the peer 819 configuration , as explained in Section 5.4. 821 BGP update BGP update BGP update BGP update 822 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 823 TS: TS: TS: 824 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 AS2;R3:rT5,sT6 825 AS1;R1:rT3,sT4 827 CE1------------->R1 -----------------> R2 ---------------> R3 ------------> R4 828 | | no TS | | 829 | | | | 830 AS3 AS1 AS2 832 In the example above, CE1 is configured to send timestamp to R1, as 833 well as R1 to R2. But R2 does not want to send timestamp to R3. 835 When sending BGP route for 10/8, CE1 adds timestamp attribute and a 836 timestamp entry (AS3, entry type : IPv4=CE1_IP, receive timestamp = 837 T1, send timestamp=T2). R1 receives the path, we suppose that the 838 inspection list matches, so R1 adds a timestamp entry. When sending 839 to R2, R1 will send the following information in its timestamp entry 840 : AS1,entry type : IPv4=R1_IP, receive timestamp T3, send timestamp 841 T4. As R2 is configured to not send timestamp information to R3, it 842 will drop the BGP attribute when sending to R3. 844 5.7.2. Drop AS option 846 If AS1 and/or AS2 BGP Speakers support BGP-TS, they may not want to 847 expose their timestamps or internal BGP topology to other ASes. If a 848 service does not want to propagate local AS related timestamp 849 information to external peers, it can decide to use the "drop-as" 850 option towards the peer. 852 BGP update BGP update BGP update BGP update 853 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 854 TS: TS: TS: TS: 855 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 856 AS1;R1:rT3,sT4 AS2;R3:rT5,sT6 858 CE1------------->R1 -----------------> R2 ---------------> R3 ------------> R4 859 | | no TS | | 860 | | | | 861 AS3 AS1 AS2 863 In the example above, CE1 is configured to send timestamp to R1, as 864 well as R1 to R2. But R2 does not want to send AS1 internal 865 timestamp to R3. "Drop-as" option is configured on R2 towards R3. 867 When sending BGP route for 10/8, CE1 adds timestamp attribute and a 868 timestamp entry (AS3, entry type : IPv4=CE1_IP, receive timestamp = 869 T1, send timestamp=T2). R1 receives the path, we suppose that the 870 inspection list matches, so R1 adds a timestamp entry. When sending 871 to R2, R1 will send the following information in its timestamp entry 872 : AS1,entry type : IPv4=R1_IP, receive timestamp T3, send timestamp 873 T4. As R2 is configured with "drop-as" option to R3, it will remove 874 all timestamp entries where the ASN is equal to its autonomous system 875 number and then send the update to R3. 877 5.7.3. Summary option 879 If AS1 and/or AS2 BGP Speakers support BGP-TS, they may want to offer 880 timestamp service to their customers but they want to hide their 881 internal topology. In order to achieve the expected behavior, AS1/ 882 AS2 can activate a timestamp summary option on the external peer. 884 BGP update BGP update BGP update BGP update 885 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 886 TS: TS: TS: TS : 887 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 888 AS1;R1:rT3,sT4 AS1;rT3,sT5 AS1;rT3,sT5 889 AS2;R3,rT6,sT7 891 CE1------------->R1 -----------------> R2 ---------------> R3 ------------> R4 892 | | TS summary | | 893 | | | | 894 AS3 AS1 AS2 896 When using summary option, the BGP-TS attribute is modified as 897 follows when exporting the route : 899 o All timestamp entries containing the local AS in AS field are 900 removed. 902 o A new timestamp entry is created and inserted in place of removed 903 entries (n entries replaced by 1). 905 o The new timestamp entry will use an entry type zero. 907 o The new timestamp entry MUST have the S bit set. 909 o The new timestamp entry MUST NOT have any EntryType. 911 o The receive timestamp of the new timestamp entry is the receiving 912 timestamp of the first timestamp entry that has been removed. 914 o The send timestamp of the new timestamp entry will be added as 915 usual. 917 In the example above, CE1 is configured to send timestamp to R1, as 918 well as R1 to R2. But R2 wants summarize timestamp information to 919 AS2. 921 When sending BGP route for 10/8, CE1 adds timestamp attribute and a 922 timestamp entry (AS3, entry type : IPv4=CE1_IP, receive timestamp = 923 T1, send timestamp=T2). R1 receives the path, we suppose that the 924 inspection list matches, so R1 adds a timestamp entry. When sending 925 to R2, R1 will send the following information in its timestamp entry 926 : AS1,entry type : IPv4=R1_IP, receive timestamp T3, send timestamp 927 T4. As R2 is configured with "summarize" option to R3, it will 928 remove all timestamp entries where the ASN is equal to its autonomous 929 system number and add a new timestamp entry with an entry type zero. 930 The receive timestamp will be retrieved from R1 timestamp entry. 932 5.7.4. Propagate option 934 If AS1 and/or AS2 BGP Speakers support BGP-TS, they may want to offer 935 timestamp service to their customers with a full view. This MUST be 936 the default behavior when timestamp is activated on a peer. 938 BGP update BGP update BGP update BGP update 939 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 940 TS: TS: TS: TS : 941 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 AS3;CE1:rT1,sT2 942 AS1;R1:rT3,sT4 AS1;R1:rT3,sT4 AS1;R1:rT3,sT4 943 AS1;R2:rT5,sT6 AS1;R2,rT5,sT6 944 AS2;R3,rT6,sT7 946 CE1------------->R1 -----------------> R2 ---------------> R3 ------------> R4 947 | | TS propagate | | 948 | | | | 949 AS3 AS1 AS2 951 5.8. Retrieving timestamp vector 953 Authors suggest to implementers to use a local wrapping buffer on 954 each node and record entries in the buffer each time a BGP path is 955 timestamped. An external tool should then retrieve timestamps 956 information from sink points. How the information is retrieved is 957 out of scope of the document but we can imagine using : 959 o BMP from the external tool to the sink point. 961 o NetConf get to retrieve wrapping buffer information. 963 o SNMP get to retrieve wrapping buffer information. 965 o CLI command to retrieve wrapping buffer information. 967 5.9. Handling malformed attribute 969 When receiving a BGP Update message containing a malformed BGP-TS 970 attribute, an "attribute discard" action MUST be applied as defined 971 in [I-D.ietf-idr-error-handling]. 973 5.10. Impact on update packing 975 Introducing timestamps information will make update packing less 976 efficient for the timestamps path. In the deployment we are 977 targeting (Section 7), this is not considered as an issue. In the 978 case where a site is generating a special prefix with path 979 timestamped and others not timestamped, these prefixes will not be 980 packed together, so two update messages will be generated. Even if 981 two updates are generated, we do not consider, that the propagation 982 time will be highly affected. 984 6. Compared to BMP 986 BMP (BGP Monitoring Protocol) [I-D.ietf-grow-bmp] is a solution to 987 monitor BGP sessions and provides a convenient interface for 988 obtaining route views. BMP is a complete suite of messages to 989 exchange informations regarding a BGP session. 991 We can imagine to use BMP as a solution to monitor BGP update 992 propagation time but there is multiple drawbacks associated with such 993 solution : 995 o BMP provides dump of all received BGP update (per peer). If we 996 are interested only in probing BGP routes, a strong filtering of 997 information may be needed in BMP messages. 999 o BMP does not mandate timestamping of messages (as per 1000 [I-D.ietf-grow-bmp] Section 5) : "If the implementation is able to 1001 provide information about when routes were received, it MAY 1002 provide such information in the BMP timestamp field. Otherwise, 1003 the BMP timestamp field MUST be set to zero, indicating that time 1004 is not available." 1006 o BMP may provide (if implementation available) timestamps 1007 information only for a single router point of view. If we want to 1008 retrieve timestamps of all BGP Speakers on a path, a BMP session 1009 is required to all BGP speakers. Correlation (based on known 1010 design) is also required at the external tool to order timestamps 1011 from each BMP session. 1013 o If BMP provides timestamp information, it does not provide 1014 information on how the router clock is synchronized (free run, 1015 NTP, GPS ...). 1017 o BMP only provides Adj-RIB-in view and does not provide outgoing 1018 information. 1020 Using BMP to monitor BGP update propagation may complexify the design 1021 of the monitor solution. But as mentioned in Section 1, BMP can be 1022 used on specific sink routers to retrieve BGP TS vector. 1024 7. Deployment considerations 1026 This solution is not intended to perform timestamp imposition on all 1027 BGP prefixes. 1029 The deployment scenario we are targeting is really to monitor some 1030 specific single-homed NLRIs identified by the service provider (see 1031 Section 2 as an example). 1033 These NLRIs may be advertised at some injection point in the network, 1034 and timestamp vector will be retrieved at some sink points. As 1035 pointed in Section 2.2.2 , multiple samples of measurement will be 1036 necessary in order to evaluate the propagation time. 1038 These NLRIs should be single-homed in order to ensure an end to end 1039 propagation from injection point to sink point. A coordination 1040 between injection and sink points based on an external tool is 1041 necessary : once a NLRI to be monitored has been advertised, the tool 1042 would retrieve the timestamp vector from the sink point. 1044 Service provider may use real prefixes (used for routing) or special 1045 prefixes (standard IP prefix but allocated for beaconing). In case 1046 of special prefix used, the tool can at regular interval command the 1047 advertisement and withdrawal of the prefix. The tool must ensure 1048 that it has retrieved the timestamp vector before withdrawing the 1049 prefix and also wait for convergence after withdrawal before 1050 advertising back the prefix. 1052 The inspection list should be kept as small as possible by users in 1053 order to not introduce processing overhead and as a consequence slow 1054 down propagation. 1056 8. Security considerations 1058 Depending of the implementation and router capacity, adding 1059 timestamps to BGP path may consume some router resources. As 1060 proposed in Section 5.1, by default a BGP Speaker will not timestamp 1061 any path and inspection list should be configured to activate 1062 timestamping on a subset of paths. Using this approach, we consider 1063 that overhead that may be introduced by timestamping BGP paths is 1064 well controlled by operators. An external router cannot force an 1065 internal router to timestamp. 1067 Providing detailed timestamps information to other ASes may introduce 1068 security issues by exposing internal datas (part of BGP topology, IP 1069 addresses, internal performance) to external entities. The proposal 1070 we make in Section 5.7 solves this security issue by giving 1071 flexibility to operators on the level of information he wants to 1072 expose to external peers. 1074 9. Acknowledgements 1076 10. IANA Considerations 1078 IANA shall assign a codepoint for the BGP Timestamp attribute. This 1079 codepoint will come from the "BGP Path Attributes" registry. 1081 11. Normative References 1083 [I-D.ietf-grow-bmp] 1084 Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring 1085 Protocol", draft-ietf-grow-bmp-07 (work in progress), 1086 October 2012. 1088 [I-D.ietf-idr-error-handling] 1089 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 1090 "Revised Error Handling for BGP UPDATE Messages", draft- 1091 ietf-idr-error-handling-18 (work in progress), December 1092 2014. 1094 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1095 Requirement Levels", BCP 14, RFC 2119, March 1997. 1097 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1098 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1100 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1101 Time Protocol Version 4: Protocol and Algorithms 1102 Specification", RFC 5905, June 2010. 1104 Authors' Addresses 1106 Stephane Litkowski 1107 Orange Business Service 1109 Email: stephane.litkowski@orange.com 1111 Keyur Patel 1112 Cisco Systems 1114 Email: keyupate@cisco.com 1116 Jeff Haas 1117 Juniper Networks 1119 Email: jhaas@juniper.net