<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY BMP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-grow-bmp.xml">
<!ENTITY BGP-ERR SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-error-handling">

]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space: 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="std" docName="draft-litkowski-idr-bgp-timestamp-02"
     ipr="trust200902">
  <front>
    <title abbrev="bgp-timestamp">Timestamp support for BGP paths</title>

    <author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
      <organization>Orange Business Service</organization>

      <address>
        <!-- postal><street/><city/><region/><code/><country/></postal -->

        <!-- <phone/> -->

        <!-- <facsimile/> -->

        <email>stephane.litkowski@orange.com</email>

        <!-- <uri/> -->
      </address>
    </author>
    <author fullname="Keyur Patel" initials="K" surname="Patel">
      <organization>Cisco Systems</organization>

      <address>
        <!-- postal><street/><city/><region/><code/><country/></postal -->

        <!-- <phone/> -->

        <!-- <facsimile/> -->

        <email>keyupate@cisco.com</email>

        <!-- <uri/> -->
      </address>
    </author>
   <author fullname="Jeff Haas" initials="J" surname="Haas">
      <organization>Juniper Networks</organization>

      <address>
        <!-- postal><street/><city/><region/><code/><country/></postal -->

        <!-- <phone/> -->

        <!-- <facsimile/> -->

        <email>jhaas@juniper.net</email>

        <!-- <uri/> -->
      </address>
    </author>
    <date year="2015"/>

    <area/>

    <workgroup>Interdomain Working Group</workgroup>

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <abstract>
      <t>BGP is more and more used to transport routing information for critical services. 
	  Some BGP updates may be critical to be received as fast as possible : for example, in a layer 3
	  VPN scenario where a dual-attached site is loosing primary connection, the BGP withdraw message should be propagated as fast as possible to restore the service.	  
	  The same criticity exists for other address-families like multicast VPNs where "join" messages should also be propagated very fast.</t>
	  <t>Experience of service providers shows that BGP path propagation time may vary depending on network conditions (especially load of BGP speaker on the path)
	  and too long propagation time are affecting customer service.</t>
	  <t>It is important for service providers to keep track of BGP updates propagation time to monitor quality of service for the customers. 
	  It is also important to be able to identify BGP Speakers that are slowing down the propagation.</t>
	  <t>This document presents a solution to transport timestamps of a BGP path. The solution is targeted to be used using special identified beacon prefixes that are single-homed.</t>
	</abstract>
	
	<note title="Requirements Language">
      <t>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 <xref
      target="RFC2119"/>.</t>
  </note>
  
  </front>

  <middle>
    <section anchor="problem-statement" title="Problem statement">
		
      
	  <figure>
	  <artwork>
CE3----PE3               PE4 --- CE4 (Source)             
          \             /
           RR3       RR4		  
              \     /
                RR5
               /    \            
            RR1     RR2
           / |         \
          /  |          \
CE1----PE1  PE5          PE2 --- CE2
             |
             CE5			 
                 
              Figure 1				 
	  </artwork>
	  </figure>
	  <t>
	  The figure 1 describes a typical hierarchical RR design where PEs are meshed to local RRs and local RRs are meshed to more centric RRs.
	  We consider a single multicast VPN between all CEs. CE4 is the source, all others may be receivers.
	  The BGP controlplane also supports some other BGP service like L3VPN service.
	  </t>
	  <t>
	  We consider an event in L3VPN service leading to RR1 being temporarily overloaded (for example, RR1 is processing massive updates due to a router failure or formatting updates for a route-refresh).
	  In the same timeframe, CE1 wants to join the multicast flow from CE4. PE1 propagates the C-multicast route to RR1, but RR1 fails to propagate the route to RR5 because it is busy processing L3VPN.
	  When RR1 finishes the L3VPN job, it would send the C-multicast route to RR5 and updates would be imported by PE4. The long time to join the flow may cause CE4 to miss part of the multicast flow.
	  </t>
	  <t>
	  All BGP implementations are different in term of internal processing within an address family or between address family. The issue described above is just given as an example, and the document does not
	  presume that all implementations are suffering from this exact issue. But whatever the implementation, their always be cases where BGP path propagation could be delayed.
	  </t>
	  <t>
	  Service providers currently lack of efficient solution to keep track of BGP path propagation time as well as solution to identify the BGP speakers causing issues.
	  </t>
	  <t>
	  BMP (BGP Monitoring Protocol) may be a solution but as several drawbacks (see <xref target="bmp"/>).
	  </t>
    </section>
	

	

	<section anchor="timestamp" title="Requirements for monitoring BGP path propagation time">
		<section anchor="architecture" title="Architecture">
		<figure>
		<artwork>
                    ---------             -------
                   /           \         /         \
    RTR_SRC1 ----- |   AS1     | -----  |     AS2   |  ---- RTR_DST1
        |          \           /         \         /           |
      Inject         ---------            ---------            Sink point
       point             |                     |
                         |                     |
                     ---------             -------
                   /           \         /         \
    RTR_DST2 ---- |     AS4     |       |     AS3   |  ---- RTR_SRC2_DST2
         |         \           /         \         /             |
        Sink point   ---------            ---------         Inject/Sink
                                                              point
                              Figure 2					
		</artwork>
		</figure>

		<figure>
		<artwork>
                 Single AS
   -------------------------------------------
  /                                            \
 |          RR1 ---------- RR2                  |
 |         /   \               \                |
 | RTR_SRC1     \               RTR_DST2        |
 |    |          \                  |           |
 |   Inject      RR3               Sink point   |
 |     point      |                             |
 |               RTR_DST1                       |
 |                |                             |
  \              Sink point                    /
    -------------------------------------------
                    Figure 3
		</artwork>
		</figure>
		<t>
		Figure 2 and Figure 3 describes an interAS and a single AS scenario where a service provider wants to monitor BGP path propagation time from a router to multiple routers.
		In Figure 2, multiple probing routers are attached to multiple ASes. In Figure 3, all probing routers are in the same AS.
		</t>
		<t>
		The architecture requires some BGP Speaker to originate some NLRI within the BGP controlplane. In the diagram above, they are identified as "Inject point".
		In order to provide information about propagation delays, the architecture requires introduction of timestamp information.
		Architecture also needs to identify BGP Speaker causing high propagation delays.
		As only, specific advertisement will serve for measurement, the architecture requires BGP Speaker to identify NLRIs that must be timestamped.
		The architecture also requires some BGP Speaker to serve as sink point where a timestamp vector information can be retrieved. The timestamp vector must contain propagation time information 
		for all BGP Speaker that participated in the BGP path. It is so required that each BGP Speaker along the path to add timestamp information.
		There may be multiple sink points in the network to perform measurement at different location and also different inject points.
		An external tool may be connected to Sink Points to retrieve the timestamp information. But this is out of scope of the document.
		</t>
		<t>
		In case of interAS, for security reason, the architecture MUST support hiding detailed timestamp information to the other AS.
		</t>
		
		<t>Example of usage : </t>
		<t>An external tool should command RTR_SRC to originate a probing BGP NLRI. 
		All the BGP Speakers are configured to measure timestamp for this NLRI.
		The BGP path would propagate across BGP Speakers. Each BGP Speaker may provide timestamp informations.
		An external tool connected to sink points will retrieve timestamp vector information for the NLRI.
		</t>
		</section>
		<section anchor="accuracy" title="Measurement accuracy">
			<section anchor="accuracy-clock" title="Clock synchronization">
			<t>
			For the solution to be accurate, it is mandatory for BGP Speaker to be synchronized. This could be ensured easily within a single AS
			but in a inter domain scenario, it is hard to ensure that all Speakers are synchronized to a good clock source.
			</t>
			<t>
			The solution MUST include synchronization information associated with the timestamp in order to be able to compare timestamps between them.
			</t>
			</section>
			<section anchor="accuracy-beacon" title="Beacon accuracy">
			<t>
			In order to be accurate, an implementation SHOULD :
			<list style="symbols">
			<t>ensure that the timestamped NLRIs are processed with the same priority as non timestamped NLRIs.</t>
			<t>ensure that the processing of adding timestamp information is as lightweight as possible. If some limitation exists, the vendor SHOULD document them.</t>
			</list>
			</t>
			<t>
			Using a unique special prefix advertisement from a single location to evaluate propagation time will not provide a detail view of min/max propagation time values as the user will not know where the path for the prefix may be located in a processing queue.
			Considering a BGP Speaker handling high churn, the advertisement of the path for the special prefix may have a specific place in the long processing queue of the churn depending on the implementation : it may be first, last or somewhere in the middle.
			</t>
			<t>
			It is required from user to perform sampling to establish propagation time boundaries based on multiple advertisements. Repeated operations of advertisement then withdraw may help in this. See <xref target="deployment"/> for more details.
			</t>
			</section>
		</section>
		<section anchor="churn" title="Churn">
		<t>
		The target solution MUST NOT create more churn in the BGP controlplane.
		</t>
		</section>
		<section anchor="stale-info" title="Path propagation complexity">
		<t>
		When a NLRI is originated in BGP from a point, a BGP path is created. Nothing ensures that all nodes within the BGP controlplane will receive this BGP path. When a concurrent path already exists from the NLRI, the concurrent path may be prefered by some BGP Speaker leading to hiding of the new path.
		Moreover, even if the NLRI is originated in BGP from a single point, multiple paths may be created within the BGP controlplane, this is inherent to the BGP meshing in place.
		</t>
		<t>
		As soon as multiple BGP paths are involved, controlplane convergence may be done in multiple steps in order to find the final best path.
		This convergence may involve multiple BGP path advertisement (replacing each other) between peers.
		</t>
		<t>
		The goal of our proposal is not to measure the convergence time but to focus on the path propagation time. In a controlplane convergence involving multiple paths for a NLRI, the solution MUST identify
		timestamp for the event where the NLRI was seen for the first time on a BGP Speaker.
		</t>
		<t>
		Example :
		<figure>
		<artwork>
                 Single AS
   -------------------------------------------
  /                             RTR_SRC2- 10/8 \
 |                            /                 |
 |          RR1 ---------- RR2                  |
 |         /   \               \                |
 | RTR_SRC1     \               RTR_DST2        |
 |     |         \                              |
 |   10/8        RR3                            |
 |                |                             |
 |               RTR_DST1                       |
 |                                              |
  \                                            /
    -------------------------------------------
                   
				   Figure 4
		</artwork>
		</figure>
		
		In the figure above, consider that the service provider is keep tracking of propagation time for real NLRIs (corresponding to customer routes).
		All the BGP Speakers in our figure are configured to inspect the NLRI 10/8 which is multihomed. We consider that the network is starting and the NLRI has not been propagated yet.
		</t>
		<t>
		RTR_SRC1 starts to propagate 10/8 within the BGP controlplane. All BGP Speakers considers the path as best and this path will be propagated within the whole controlplane. 
		Each BGP Speaker would add its timestamp information and RTR_DST1 and RTR_DST2 would be able to record the timestamp vector. In this case, the timestamp vector is quite accurate because
		it represents an end to end propagation.
		</t>
		<t>Now RTR_SRC2 starts to propagate its own path. RR2 has two paths for 10/8 and will choose the best one, let's consider that RTR_SRC2 path is the best one, RTR_SRC2 path will so be propagated and timestamp vector will be updated.
		RR1 will also have two paths, and we consider that RR1 prefers RTR_SRC1 path, so RTR_SRC2 path will not be propagated by RR1. In this situation, RTR_DST2 will receive the path from RR2 with accurate timestamp (end to end propagation) but RTR_DST1 will never receive it.
		</t>
		
		<t>
		We could also consider a stable network situation, where both paths have been advertised for a long time. A network event may occur (e.g. IGP metric change) that would cause a BGP Speaker
		within a path vector to change its best path. In Figure 10, an IGP event, may cause RR1 to change its decision and prefers the path originated by RTR_SRC2 as best, the path will be propagated with
		previous received timestamp information that are no more accurate. RTR_DST1 will receive a BGP timestamp vector containing stale (old) timestamp informations as well as new ones. 
		</t>
		</section>
	</section>
	
	<section anchor="proposal" title="Proposal">
	<t>
	Our proposal is based on tagging NLRI with timestamp values along its BGP path propagation. Each BGP Speaker along the path will add timestamp values, so creating a timestamp vector.
	
	An ordered list of timestamps would so be built along the path.
	</t>
	<figure>
	<artwork>

    BGP Update      BGP Update       BGP Update      BGP Update
    10.0.0.0/8      10.0.0.0/8       10.0.0.0/8      10.0.0.0/8
    Timestamp:      Timestamp:       Timestamp:      Timestamp:
    R1:T1           R1:T1            R1:T1           R1:T1
                    R2:T2            R2:T2           R2:T2
                                     R3:T3           R3:T3
                                                     R4:T4
R1 ------------> R2 ------------> R3 ------------> R4 ------------> R5
	</artwork>
	</figure>
	<t>
	Using this mechanism, we can easily identify if a hop within a path is slowing down the propagation.
	</t>
	<t>We propose to use a new BGP attribute, BGP timestamp attribute to encode timestamps information.</t>
	</section>
	
	<section anchor="encoding" title="BGP timestamp attribute">
	<t>
	The BGP timestamp (BGP-TS) Attribute is an optional transitive BGP Path Attribute. The attribute type code is TBD.
	</t>
	<t>
	The value field of the BGP timestamp attribute is defined as an ordered list of timestamp entries, the first entry being the first timestamp entry
added (origin):
	</t>
	
<figure>
<artwork>
 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Timestamp #1  (variable)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Timestamp #2  (variable)                       |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Timestamp #n  (variable)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

<t>The timestamps entries are encoded as follows :
<figure>
<artwork>
 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                 Receive Timestamp #x                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                 Send Timestamp #x                             |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 ASN                                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|   Rsvd      |   SyncType    |   EntryType   |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
|                                                               |
|                        Optional variable field                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

</artwork>
</figure>
	<list style="symbols">
	<t>Receive timestamp : the time at which the BGP path was received. When originating a path in BGP, the timestamp is the originating time.
	 Expressed in seconds and microseconds since
      midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
      unavailable.  Precision of the timestamp is implementation-
      dependent.
	  <figure>
	  <artwork>
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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                 Timestamp (seconds)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                 Timestamp (microseconds)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	  </artwork>
	  </figure>
	</t>
	<t>Send timestamp : the time at which the BGP path was exported to the peer. 
	 Expressed in seconds and microseconds since
      midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
      unavailable.  Precision of the timestamp is implementation-
      dependent.
	</t>
	<t>ASN : AS Number of the local node creating the timestamp entry.</t>
	<t>Flags :
		<list style="symbols">
		<t>T : Synchronized, if set, the BGP speaker clock is synchronized to an external system.</t> 
		</list>
	</t>
	<t>SyncType : defines the stratum as defined in <xref target="RFC5905"/>.</t>
	<t>EntryType : defines the type of Timestamp entry, the following types are defined :
	<list style="symbols">
	<t>Type 0 : empty. There is no following variable field. This type is to be used in case of timestamp summarization.</t>
	<t>Type 1 : IPv4 address, the following variable field will be 4 bytes long and will contain the IPv4 router ID of the local node.</t>
	<t>Type 2 : IPv6 address, the following variable field will be 16 bytes long and will contain the IPv6 router ID of the local node.</t>
	<t>Type 3 : Stale Indicator, Stale indicates that previous timestamp entries are old. There is no following variable field. The receive timestamp and send timestamp should be set to zero. The ASN is set to the ASN of the local BGP Speaker.</t>
	</list>
	</t>
	</list>
</t>


	</section>
	<section anchor="processing" title="Processing the BGP timestamp attribute">
		<section anchor="processing-inspection" title="Inspection list">
		<t>
		A BGP Speaker supporting the BGP-TS can decide to timestamp only some specific NLRIs. 
		An inspection list may be configured by the user (filter) to apply timestamping on a specific set of BGP NLRIs.
		By default, we suggest that a BGP Speaker supporting BGP-TS SHOULD NOT timestamp any BGP NLRIs.
		</t>
		<t>
		User of our proposal must be aware that using a complex policy to express inspection list may result in more processing that will influence the end to end propagation time.
		It is expected that the inspection list policy should be kept as simple as possible.
		</t>
		</section>
		<section anchor="processing-origin" title="Originating a timestamped route in BGP">
		<t>
		When a BGP Speaker supporting BGP-TS originates a new path in BGP that matches the inspection list, 
		it MUST add the BGP-TS attribute to the BGP path and MUST set the receive timestamp field to the time the path was originated in BGP. At this time of processing, the send timestamp will be set to 0.
		If the BGP Speaker is synchronized to an external system when originating the route, the S-bit MUST be set in the attribute and the SyncType MUST be set to the current stratum.
		As mentioned above, the BGP path of the originated route will have a send timestamp value of zero in the BGP LOC-RIB.
		</t>
		</section>
		<section anchor="processing-receive" title="Receiving a timestamped route in BGP">
		<t>When a BGP Speaker supporting BGP-TS receives a BGP path that matches the inspection list, the implementation MUST record the current time associated with the received path.</t>
		<t>The time recording MUST append before the inbound routing policies.</t>
		<figure>
		<artwork>
                         Inspection
		                   List
       +------------+      +---+    No match    +------------+
--&gt;    | Adj-RIB-in | --&gt;  | I | -------------&gt; | Rtg pol in |
       | Peer#1     |      | n |                | Peers#1    | -----&gt;
       +------------+      | s |     +-------+  |            |
                           | p | --&gt; | AddTS |-&gt;|            |
                           | e |     +-------+  +------------+
                           | c |   If match
                           | t |
                           |   |
                           | l |
       +------------+      | i |    No match    +------------+
--&gt;    | Adj-RIB-in | --&gt;  | s | -------------&gt; | Rtg pol in |
       | Peer#2     |      | t |                | Peers#2    | -----&gt;
       +------------+      |   |     +-------+  |            |
                           |   | --&gt; | AddTS |-&gt;|            |
                           |   |     +-------+  +------------+
                           |   |   If match
                           +---+
				



		
		</artwork>
		</figure>
		<t>
		If the path that matches the inspection list and does not contains a BGP-TS attribute, it MUST add a BGP-TS attribute with a timestamp entry  :
			<list style="symbols">
			<t>The receive timestamp MUST be set to the recorded time for this BGP path.</t>
			<t>If the BGP Speaker is synchronized to an external system when receiving the route, the S-bit MUST be set in the attribute and the SyncType MUST be set to the current stratum.</t>
			<t>The send timestamp MUST be set to zero.</t>
			</list>
		</t>
		<t>If the path that matches the inspection list and contains a BGP-TS attribute, it MUST append a new timestamp entry in the existing attribute :
			<list style="symbols">
			<t>The receive timestamp MUST be set to the recorded time for this BGP path.</t>
			<t>If the BGP Speaker is synchronized to an external system when receiving the route, the S-bit MUST be set in the attribute and the SyncType MUST be set to the current stratum.</t>
			<t>The send timestamp MUST be set to zero.</t>
			</list>
		</t>
		<t>
			The process of adding a timestamp entry or adding BGP-TS attribute SHOULD be as light as possible in order to influence the propagation time as lowest as possible.
		</t>
		<t>When a BGP Speaker supporting BGP-TS receives a BGP path that does not the inspection list and contains a BGP-TS attribute, it MUST NOT change the existing attribute.</t>
		<t>When a BGP Speaker not supporting BGP-TS receives a BGP path that contains a BGP-TS attribute, it MUST follow the standard BGP procedures described in <xref target="RFC4271"/>.</t>
		</section>
		<section anchor="processing-send" title="Sending a timestamped route in BGP">

			<section anchor="processing-send-attr" title="Propagating the BGP Timestamp attribute">
			<t>
			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 <xref target="processing-interAS"/> for more information.
			</t>
			<t>If a BGP path containing a BGP-TS attribute must be sent to be peer not configured with BGP timestamp option, the BGP-TS attribute should be dropped when the update message is sent to the peer.</t>
			</section>
			<section anchor="processing-send-ts" title="Setting the send timestamp">
			<t>
			If sending timestamp attribute is authorized for a specific peer, and path has a BGP-TS attribute, the outgoing BGP processing MUST fill the send timestamp field when exporting the path to a peer.
			The time recording MUST occur after all BGP filtering policies (outgoing routing policies, ORF, ...) and after placing path in Adj-RIB-Out. An implementation
			SHOULD set timestamp at the nearest possible step before sending the BGP Update to the peer.
			Depending of the implementation, the timestamping may occur at different stage of the outgoing BGP processing. Each implementer SHOULD document their timestamping process in order to make users understand
			correctly timestamp values.
			As most of implementations are using the concept of peer-groups, in case, timestamp is set too early in the BGP outgoing processing, all peers within a group may have the same timestamp value. Implementation should avoid this.
			</t>
			<t>
			The process of adding the send timestamp must be as light as possible in order to influence the propagation time as lowest as possible.
			</t>
			<figure>
			<artwork>
+------+
|      |     +--------+     +-----+     +---+   +-------+     No TS
|      | --&gt; | Rtgpol | --&gt; | ORF | --&gt; |...|--&gt;|Adj-RIB|--------------&gt;
|      |     | Out    |     |P#1  |     |   |   |Out    |       Send to peer
|      |     | Peer#1 |     |     |     |   |   |Peer#1 |   +-----+     
|      |     |        |     |     |     |   |   |       |--&gt;|AddTS| ---&gt;
|      |     +--------+     +-----+     +---+   +-------+   +-----+
|      |                                                     TS present
| BGP  |
| LOC  |
| RIB  |
|      |
|      |     +--------+     +-----+     +---+   +-------+     No TS
|      | --&gt; | Rtgpol | --&gt; | ORF | --&gt; |...|--&gt;|Adj-RIB|--------------&gt;
|      |     | Out    |     |P#2  |     |   |   |Out    |       Send to peer
|      |     | Peer#2 |     |     |     |   |   |Peer#2 |   +-----+     
|      |     |        |     |     |     |   |   |       |--&gt;|AddTS| ---&gt;
|      |     +--------+     +-----+     +---+   +-------+   +-----+
|      |                                                     TS present
+------+	
			</artwork>
			</figure>
			
			</section>
		</section>
		<section anchor="processing-churn" title="Limiting churn">
		<t>
		Adding timestamp informations to BGP path will make all received paths to be unique.
		</t>
		<figure>
		<artwork>
            RR1
          /    \
10/8 - R1        RR3 --- R3
          \    /
            RR2
		</artwork>
		</figure>
		<t>
		In the figure above, we consider that RR1 and RR2 are part of the same cluster (cluster ID : 1). RR3 is client of RR1 and RR2. R3 is client from RR3, R1 is client from RR1 and RR2.
		</t>
		<t>Without BGP timestamp, when R1 originates the BGP prefix 10/8, it sends it to RR1 and RR2. Consider that RR3 receives path from RR1 first, it will reflect it to R3. When it will receive the path from RR2, it may consider that path from RR2 is best (lowest router ID) but as
		BGP attributes of the path are exactly the same as for RR1 path, there is no need to send an update to R3.
		</t>
		<t>With BGP timestamp, when R1 originates the BGP prefix 10/8, it sends it to RR1 and RR2. Consider that RR3 receives path from RR1 first, it will reflect it to R3. When it will receive the path from RR2, it may consider that path from RR2 is best (lowest router ID) but as
		BGP attributes of the two paths are not more equal due to the timestamp difference, RR3 may need to advertise an update to R3.
		</t>
		<t>
		In order to prevent introducing more churn, we propose to modify the behavior described in Section 9.2. of <xref target="RFC4271"/>.
		An implementation MUST NOT consider BGP-TS attribute when evaluating the need to send a new update.
		As the BGP-TS attribute is purely informational, even if BGP Speakers have a different view of the timestamp attribute, there will be no impact on routing.
		</t>
		<t>
		Considering our example, when RR3 will receive the path from RR2, even if it considers RR2 path as best, it will not send an update to R3 as all the attributes, except BGP-TS are equal.
		</t>
		</section>
		<section anchor="processing-stale" title="Marking stale entries">
		<t>
		<xref target="stale-info"/> describes some cases where advertised timestamp information is no more relevant because it is old and also requires identification of first propagation timestamps.
		</t>
		<t>In order to do this, we propose to mark old entries by adding a Stale Indicator within the timestamp vector. The presence of Stale Indicator must be interpreted as all previous timestamp entries need to be considered as old and not considered as a first propagation.</t>
		<figure>
		<artwork>
BGP-TS attribute example :

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  +
|                Timestamp #1  (IPv4)                           |  | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | Old
|                Timestamp #2   (IPv4)                          |  | entries
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                Timestamp #3   (IPv4)                          |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  +
|                Timestamp #4   (Stale Indicator)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  +
|                Timestamp #5   (IPv4)                          |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | Usable
...                                                               ...entries
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                Timestamp #n  (variable)                       |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  +
		</artwork>
		</figure>
		<t>
		Insertion of Stale Indicator in a BGP-TS attribute may happen in the following conditions :
		<list style="symbols">
		<t>A path is received from a peer containing BGP-TS attribute or originated locally, the path matches the inspection list, and the decision process does not select the path as best path. Then the Stale Indicator SHOULD be inserted after decision process happened.</t>
		<t>A path is received from a peer containing BGP-TS attribute or originated locally, the path matches the inspection list, and the decision process does select the path as best path. The path is exported to peers and then the Stale Indicator MUST be inserted. The path MUST NOT be repropagated as per <xref target="processing-churn"/>.</t>
		</list>
		</t>
		<t>
		When inserting a Stale indicator, if a Stale Indicator already exists in the timestamp vector, the implement SHOULD remove it before adding the new one.
		<figure>
		<artwork>
		
		


BGP Update                                              BGP Update
10/8                                                    10/8
NH R2                                                   NH=R1
ASP : 2                                                 ASP : 1,2
Origin IGP                                              Origin IGP
BGP-TS :                                                BGP-TS :
 [TS_entry1:IPv4]                                        [TS_entry1:IPv4] 
 [TS_entry2:IPv4]                                        [TS_entry2:IPv4]
 [TS_entry3:Stale]                                       [TS_entry3:Stale]
 [TS_entry4:IPv4]                                        [TS_entry4:IPv4]
 [TS_entry5:IPv4]                                        [TS_entry5:IPv4]
                                                         [TS_entry6:IPv4]

BGP                         BGP Speaker                          BGP Speaker
Speaker                     R1                                   R3
R2                       +---------------------------+ 
  -----------------&gt;     |                           | ------------&gt; 
                         |   BGP Path                |
                         |   At reception            |
                         | +-----------------------+ |
                         | | 10/8, from R2         | |
                         | |   BGP-TS :            | | 
                         | |     [TS_entry1:IPv4]  | |
                         | |     [TS_entry2:IPv4]  | |
                         | |     [TS_entry3:Stale] | |
                         | |     [TS_entry4:IPv4]  | |
                         | |     [TS_entry5:IPv4]  | |
                         | |     [TS_entry6:IPv4]&lt;-| | New timestamp entry  
                         | +-----------------------+ | created by R1
                         |                           |
                         |   BGP Path                |
                         |   after sending to peer   |
                         |   Stale state is added    |
                         | +-----------------------+ |
                         | | 10/8, from R2         | |
                         | |   BGP-TS :            | | 
                         | |     [TS_entry1:IPv4]  | |
                         | |     [TS_entry2:IPv4]  | |
                         | |     [TS_entry4:IPv4]  | |
                         | |     [TS_entry5:IPv4]  | |
                         | |     [TS_entry6:IPv4]&lt;-| | New timestamp entry  
                         | |     [TS_entry7:Stale] | | created by R1
                         | +-----------------------+ |
                         +---------------------------+
						 						 
		</artwork>
		</figure>
		In the example above, R2 sends a BGP path with some existing stale timestamps. When R1 receives the route, it creates a new timestamp entry in the BGP-TS attribute.
		We consider that the decision process decides that the path is best, the path is exported with the new timestamp entry and old timestamps coming from R2. Then R1 will update its local path by removing the previous
		Stale Indicator and replace a new one at the latest position to mark that it is no more the first propagation.
		</t>
		<t>
		<figure>
		<artwork>
              Single AS
   ----------------------------
  /               RTR_SRC2- 10/8 \
 |              /                 |
 |          RR1                   |
 |         /   \                  |
 | RTR_SRC1     \                 |
 |     |         \                |
 |   10/8        RR3              |
 |                |               |
 |               RTR_DST1         |
  \                              /
    ----------------------------
                   
		</artwork>
		</figure>
		In the figure above, we consider that all BGP Speaker apply timestamp for prefix 10/8.
		RTR_SRC1 originates 10/8 in BGP, the decision process will decide that the path is best. RTR_SRC1 will export path to RR1 and then it will add locally the Stale Indicator within the timestamp vector. The path exported does not have the Stale Indicator.
		RR1 will receive the path and add a timestamp entry, the path is considered as best, RR1 will export it to RTR_SRC2 and RR3 and then it will add a stale indicator. RR3 will proceed in the same way.
		</t>
		<t>
		When RTR_SRC2 will originate a new path for 10/8, if this new path is best on RTR_SRC2, it will export the path to RR1 and then it will add locally the Stale Indicator to the path.
		When RR1 will receive the route :
		<list style="symbols">
		<t>If the path from RTR_SRC2 is best, RR1 will export the new path to RTR_SRC1 and RR3 and then will add Stale indicator to the path.If RTR_SRC2 fails after some time, RR1 will pick up RTR_SRC1 path as best, and will export it to RR3. RR3 will know that the received timestamp entries are stale thanks to the stale indicator.</t>
		<t>If the path from RTR_SRC2 is not best, RR1 will add Stale indicator to the path. If RTR_SRC1 fails after some time, RR1 will pick up RTR_SRC2 path as best, and will export it to RR3. RR3 will know that the received timestamp entries are stale thanks to the stale indicator.</t>
		</list>
		</t>
		</section>
		
		<section anchor="processing-interAS" title="Inter-AS considerations">
		<figure>
		<artwork>

   BGP update                                                                               
   10.0.0.0/8                                                                    
   TS:
    AS3;CE1:rT1,sT2

		                                                           
CE1--------->R1 ------------> R2 ------------> R3 ------------> R4 -------> CE2
            |                   |             |                    |
            |                   |             |                    |
	AS3		     AS1                                 AS2              AS4
				 
		</artwork>
		</figure>
		<t>
		In the figure above, we consider that customer wants to monitor BGP updates propagation time between its two sites.
		</t>
		<t>
		If AS1 and AS2 BGP Speakers does not support BGP-TS, the attribute will be transported transparently accross AS1 without any processing. 
		CE2 will so receive the BGP path with only a single timestamp entry from CE1.
		</t>
		<t>
		If AS1 and AS2 BGP Speakers does support BGP-TS, four different options are offered : drop, drop-as, summarize, propagate.
		
		It must be noted that using drop-as or summarize options may involve more processing and so may impact the end to end propagation time.

		</t>
		
			<section anchor="processing-interAS-drop" title="Drop option">
			<t>
			If AS1 and/or AS2 BGP Speakers support BGP-TS, they may not want to expose any timestamp information between each other.
			If a service does not want to propagate timestamp information to external peers, it can decide to not activate the "timestamp" option on the peer configuration
			, as explained in <xref target="processing-send"/>.
			</t>
			
		<figure>
		<artwork>

   BGP update       BGP update            BGP update        BGP update       
   10.0.0.0/8       10.0.0.0/8            10.0.0.0/8        10.0.0.0/8         
   TS:              TS:                                     TS:
    AS3;CE1:rT1,sT2  AS3;CE1:rT1,sT2                         AS2;R3:rT5,sT6
                     AS1;R1:rT3,sT4
		
CE1------------->R1 -----------------> R2 ---------------> R3 ------------> R4 
                 |                     | no TS            |                    |
                 |                     |                  |                    |
	AS3                  AS1                                       AS2
				 
				        
		</artwork>
		</figure>
			<t>
			In the example above, CE1 is configured to send timestamp to R1, as well as R1 to R2. But R2 does not want to send timestamp to R3.
			</t>
			<t>
			When sending BGP route for 10/8, CE1 adds timestamp attribute and a timestamp entry (AS3, entry type : IPv4=CE1_IP, receive timestamp = T1, send timestamp=T2).
			R1 receives the path, we suppose that the inspection list matches, so R1 adds a timestamp entry. When sending to R2, R1 will send the following information in its timestamp entry : AS1,entry type : IPv4=R1_IP, receive timestamp T3, send timestamp T4.
			As R2 is configured to not send timestamp information to R3, it will drop the BGP attribute when sending to R3.
			</t>
			</section>
			<section anchor="processing-interAS-dropas" title="Drop AS option">
			<t>
			If AS1 and/or AS2 BGP Speakers support BGP-TS, they may not want to expose their timestamps or internal BGP topology to other ASes.
			If a service does not want to propagate local AS related timestamp information to external peers, it can decide to use the "drop-as" option towards the peer.
			</t>
			
		<figure>
		<artwork>

   BGP update       BGP update            BGP update         BGP update       
   10.0.0.0/8       10.0.0.0/8            10.0.0.0/8         10.0.0.0/8         
   TS:              TS:                   TS:                TS:
    AS3;CE1:rT1,sT2  AS3;CE1:rT1,sT2       AS3;CE1:rT1,sT2    AS3;CE1:rT1,sT2
                     AS1;R1:rT3,sT4                           AS2;R3:rT5,sT6
		
CE1------------->R1 -----------------> R2 ---------------> R3 ------------> R4 
                 |                     | no TS            |                    |
                 |                     |                  |                    |
	AS3                 AS1                                        AS2
				 
				        
		</artwork>
		</figure>
			<t>
			In the example above, CE1 is configured to send timestamp to R1, as well as R1 to R2. But R2 does not want to send AS1 internal timestamp to R3. "Drop-as" option is configured on R2 towards R3.
			</t>
			<t>
			When sending BGP route for 10/8, CE1 adds timestamp attribute and a timestamp entry (AS3, entry type : IPv4=CE1_IP, receive timestamp = T1, send timestamp=T2).
			R1 receives the path, we suppose that the inspection list matches, so R1 adds a timestamp entry. When sending to R2, R1 will send the following information in its timestamp entry : AS1,entry type : IPv4=R1_IP, receive timestamp T3, send timestamp T4.
			As R2 is configured with "drop-as" option to R3, it will remove all timestamp entries where the ASN is equal to its autonomous system number and then send the update to R3.
			</t>
			</section>
			<section anchor="processing-interAS-summary" title="Summary option">
			<t>
			If AS1 and/or AS2 BGP Speakers support BGP-TS, they may want to offer timestamp service to their customers but they want to hide their internal topology.
			In order to achieve the expected behavior, AS1/AS2 can activate a timestamp summary option on the external peer.
			</t>
		<figure>
		<artwork>

   BGP update       BGP update            BGP update          BGP update       
   10.0.0.0/8       10.0.0.0/8            10.0.0.0/8          10.0.0.0/8         
   TS:              TS:                   TS:                 TS :
    AS3;CE1:rT1,sT2  AS3;CE1:rT1,sT2       AS3;CE1:rT1,sT2     AS3;CE1:rT1,sT2
                     AS1;R1:rT3,sT4        AS1;rT3,sT5         AS1;rT3,sT5
                                                               AS2;R3,rT6,sT7
		
CE1------------->R1 -----------------> R2 ---------------> R3 ------------> R4 
                 |                     | TS summary       |                    |
                 |                     |                  |                    |
	AS3                   AS1                                         AS2
				 
				        
		</artwork>
		</figure>
			<t>
			When using summary option, the BGP-TS attribute is modified as follows when exporting the route :
			<list style="symbols">
			<t>All timestamp entries containing the local AS in AS field are removed.</t>
			<t>A new timestamp entry is created and inserted in place of removed entries (n entries replaced by 1).</t>
			<t>The new timestamp entry will use an entry type zero.</t>
			<t>The new timestamp entry MUST have the S bit set.</t>
			<t>The new timestamp entry MUST NOT have any EntryType.</t>
			<t>The receive timestamp of the new timestamp entry is the receiving timestamp of the first timestamp entry that has been removed.</t>
			<t>The send timestamp of the new timestamp entry will be added as usual.</t>
			</list>
			</t>
			<t>
			In the example above, CE1 is configured to send timestamp to R1, as well as R1 to R2. But R2 wants summarize timestamp information to AS2.
			</t>
			<t>
			When sending BGP route for 10/8, CE1 adds timestamp attribute and a timestamp entry (AS3, entry type : IPv4=CE1_IP, receive timestamp = T1, send timestamp=T2).
			R1 receives the path, we suppose that the inspection list matches, so R1 adds a timestamp entry. When sending to R2, R1 will send the following information in its timestamp entry : AS1,entry type : IPv4=R1_IP, receive timestamp T3, send timestamp T4.
			As R2 is configured with "summarize" option to R3, it will remove all timestamp entries where the ASN is equal to its autonomous system number and add a new timestamp entry with an entry type zero.
			The receive timestamp will be retrieved from R1 timestamp entry.
			</t>
			</section>
			<section anchor="processing-interAS-propagate" title="Propagate option">
			<t>
			If AS1 and/or AS2 BGP Speakers support BGP-TS, they may want to offer timestamp service to their customers with a full view.
			This MUST be the default behavior when timestamp is activated on a peer.
			</t>
		<figure>
		<artwork>

   BGP update       BGP update            BGP update          BGP update       
   10.0.0.0/8       10.0.0.0/8            10.0.0.0/8          10.0.0.0/8         
   TS:              TS:                   TS:                 TS :
    AS3;CE1:rT1,sT2  AS3;CE1:rT1,sT2       AS3;CE1:rT1,sT2     AS3;CE1:rT1,sT2
                     AS1;R1:rT3,sT4        AS1;R1:rT3,sT4      AS1;R1:rT3,sT4
                                           AS1;R2:rT5,sT6      AS1;R2,rT5,sT6
                                                               AS2;R3,rT6,sT7
		
CE1------------->R1 -----------------> R2 ---------------> R3 ------------> R4 
                 |                     | TS propagate     |                    |              
                 |                     |                  |                    |
	AS3                 AS1                                         AS2
				        
						
		</artwork>
		</figure>
			</section>
			
		</section>
		<section anchor="processing-retrieving" title="Retrieving timestamp vector">
		<t>
		Authors suggest to implementers to use a local wrapping buffer on each node and record entries in the buffer each time a BGP path is timestamped.
		An external tool should then retrieve timestamps information from sink points. How the information is retrieved is out of scope of the document but we can imagine using :
		<list style="symbols">
		<t>BMP from the external tool to the sink point.</t>
		<t>NetConf get to retrieve wrapping buffer information.</t>
		<t>SNMP get to retrieve wrapping buffer information.</t>
		<t>CLI command to retrieve wrapping buffer information.</t>
		</list>
		</t>
		</section>
		<section anchor="processing-malformed" title="Handling malformed attribute">
		<t>
		When receiving a BGP Update message containing a malformed BGP-TS attribute, an "attribute discard"
		action MUST be applied as defined in <xref target="I-D.ietf-idr-error-handling"/>.
		</t>
		</section>
		<section anchor="processing-packing" title="Impact on update packing">
		<t>
		Introducing timestamps information will make update packing less efficient for the timestamps path.
		In the deployment we are targeting (<xref target="deployment"/>), this is not considered as an issue.
		In the case where a site is generating a special prefix with path timestamped and others not timestamped, these prefixes will not be packed together, so two update messages will be generated.
		Even if two updates are generated, we do not consider, that the propagation time will be highly affected.
		</t>
		</section>
		
	</section>
	
	
	

	<section anchor="bmp" title="Compared to BMP">
	<t>
	BMP (BGP Monitoring Protocol) <xref target="I-D.ietf-grow-bmp"/> is a solution to monitor BGP sessions and provides a convenient interface for obtaining route views.
	BMP is a complete suite of messages to exchange informations regarding a BGP session.
	</t>
	<t>We can imagine to use BMP as a solution to monitor BGP update propagation time but there is multiple drawbacks associated with such solution :
	<list style="symbols">
	<t>BMP provides dump of all received BGP update (per peer). If we are interested only in probing BGP routes, a strong filtering of information may be needed in BMP messages.</t>
	<t>BMP does not mandate timestamping of messages (as per <xref target="I-D.ietf-grow-bmp"/> Section 5) : "If the implementation is able to provide information about when
   routes were received, it MAY provide such information in the BMP
   timestamp field.  Otherwise, the BMP timestamp field MUST be set to
   zero, indicating that time is not available." </t>
    <t>BMP may provide (if implementation available) timestamps information only for a single router point of view. If we want to retrieve timestamps of all BGP Speakers on a path, a BMP session is required to all BGP speakers. 
	Correlation (based on known design) is also required at the external tool to order timestamps from each BMP session.</t>
	<t>If BMP provides timestamp information, it does not provide information on how the router clock is synchronized (free run, NTP, GPS ...).</t>
	<t>BMP only provides Adj-RIB-in view and does not provide outgoing information.</t>
	</list>
	</t>
	<t>Using BMP to monitor BGP update propagation may complexify the design of the monitor solution. But as mentioned in <xref target="problem-statement"/>, BMP can be used on specific sink routers to retrieve BGP TS vector.</t>
	</section>
	
	<section anchor="deployment" title="Deployment considerations">
	<t>
	This solution is not intended to perform timestamp imposition on all BGP prefixes.
	</t>
	<t>
	The deployment scenario we are targeting is really to monitor some specific single-homed NLRIs identified by the service provider (see <xref target="timestamp"/> as an example).
	</t>
	<t>
	These NLRIs may be advertised at some injection point in the network, and timestamp vector will be retrieved at some sink points. As pointed in <xref target="accuracy-beacon"/>
	, multiple samples of measurement will be necessary in order to evaluate the propagation time.  
	</t>
	<t>These NLRIs should be single-homed in order to ensure an end to end propagation from injection point to sink point. A coordination between injection and sink points based on an external tool
	is necessary : once a NLRI to be monitored has been advertised, the tool would retrieve the timestamp vector from the sink point.</t>
	<t>Service provider may use real prefixes (used for routing) or special prefixes (standard IP prefix but allocated for beaconing). In case of special prefix used, the tool can at regular interval command the advertisement and withdrawal of the prefix.
	The tool must ensure that it has retrieved the timestamp vector before withdrawing the prefix and also wait for convergence after withdrawal before advertising back the prefix.
	</t>
	<t>
	The inspection list should be kept as small as possible by users in order to not introduce processing overhead and as a consequence slow down propagation.
	</t>
	</section>
	<section anchor="Security" title="Security considerations">
	<t>Depending of the implementation and router capacity, adding timestamps to BGP path may consume some router resources.
	As proposed in <xref target="processing-inspection"/>, by default a BGP Speaker will not timestamp any path and inspection list should be configured to activate timestamping on a subset of paths.
	Using this approach, we consider that overhead that may be introduced by timestamping BGP paths is well controlled by operators. An external router cannot force an internal router to timestamp.</t>
	<t>
	Providing detailed timestamps information to other ASes may introduce security issues by exposing internal datas (part of BGP topology, IP addresses, internal performance) to external entities.
	The proposal we make in <xref target="processing-interAS"/> solves this security issue by giving flexibility to operators on the level of information he wants to expose to external peers.
	</t>
	</section>
	
    <section anchor="Acknowledgements" title="Acknowledgements"/>

    <section anchor="IANA" title="IANA Considerations">
    <t>
	IANA shall assign a codepoint for the BGP Timestamp attribute. This codepoint will come from the "BGP Path Attributes" registry.
	</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
	  &RFC4271;
	  &RFC5905;
	  &BMP;
	  &BGP-ERR;
    </references>

  </back>
</rfc>
