One document matched: draft-litkowski-idr-bgp-timestamp-00.xml
<?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">
]>
<?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-00"
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="2014"/>
<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.</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 temporarly 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 update processing could be delayed.
</t>
<t>
Service providers currently lack of performant solution to keep track of BGP update 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="proposal" title="Proposal">
<t>
Our proposal is based on the path vector property of BGP. Each hop within the path would add a tuple (ID,timestamp) information in the BGP path.
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 here :
</t>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OType | Originator (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp #1 (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp #2 (variable) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp #n (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="symbols">
<t>
OType : A single octet encoding the originator type
<list style="symbols">
<t>Type 1 : 2 bytes ASN.</t>
<t>Type 2 : 4 bytes ASN.</t>
<t>Type 3 : IPv4 address.</t>
<t>Type 4 : IPv6 address.</t>
</list>
</t>
<t>Originator : IP address or AS number identifying the first router or AS that added the BGP timestamp attribute.</t>
<t>Timestamp : ordered list of timestamps, the first timestamp is the first router information. The timestamps 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|P|S|T| Rsvd | SyncType | AS#x (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer#x (variable) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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.
The format of the timestamp is the same as in <xref target="RFC5905"/> and is as
follows: the first 32 bits represent the unsigned integer number of
seconds elapsed since 0h on 1 January 1900; the next 32 bits
represent the fractional part of a second that has elapsed since
then.
</t>
<t>Flags :
<list style="symbols">
<t>A : AS type, if unset the AS field is a 2 bytes ASN, otherwise the AS field is a 4 bytes ASN.</t>
<t>P : Peer type, if unset the peer field is an IPv4 address, otherwise the peer field is an IPv6 address.</t>
<t>S : Summary, if set, the timestamp is a summary entry and does not contain a peer field. If set, the P bit MUST be set to zero.</t>
<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>AS : the local AS of the BGP Speaker.</t>
<t>Peer : the routerID of the 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 BGP paths.
An inspection list may be configured by the user (filter) to apply timestamping on a specific set of BGP prefixes or paths.
By default, we suggest that a BGP Speaker supporting BGP-TS SHOULD NOT timestamp any BGP paths.
</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.
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.
</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 and does not contains a BGP-TS attribute, it MUST add a BGP-TS attribute containing :
<list style="symbols">
<t>The originator type and originator field are set according to local BGP Speaker informations.</t>
<t>The timestamp entry contains information related to the local BGP Speaker.</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>
</list>
</t>
<t>When a BGP Speaker supporting BGP-TS receives a BGP path that matches the inspection list and contains a BGP-TS attribute, it MUST append its own timestamp entry in the existing attribute.
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>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">
<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-interAS" title="Inter-AS considerations">
<figure>
<artwork>
BGP update CE2 add timestamp
10.0.0.0/8 when receiving path
TS:
CE1:T1
CE1--------->R1 ------------> R2 ------------> R3 ------------> R4 ------------> CE2
| | | |
| | | |
AS1 AS2
Figure 2
</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, three different options are offered : drop, summarize, propagate.
</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 their timestamps or internal BGP topology to other ASes.
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 BGP update
10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8
TS: TS:
CE1:T1 CE1:T1
CE1--------->R1 ------------> R2 ------------> R3 ------------> R4 ------------> CE2
| | no TS | |
| | | |
AS1 AS2
Figure 3
</artwork>
</figure>
</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 BGP update
10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8 10.0.0.0/8
TS: TS: TS: TS: TS:
CE1:T1 CE1:T1 CE1:T1 CE1:T1 CE1:T1
R1:T2 AS1:T3 AS1:T3 AS1:T3
R3:T4 AS2:T5
CE1--------->R1 ------------> R2 ------------> R3 ------------> R4 ------------> CE2
| | TS summary | | TS summary
| | | |
AS1 AS2
Figure 4
</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 MUST have the S bit set.</t>
<t>The new timestamp entry MUST NOT have a peer field.</t>
<t>The timestamp of the new timestamp entry is the receiving timestamp of the last timestamp entry that has been removed.</t>
</list>
</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.
The behavior is the default intraAS behavior.
</t>
<figure>
<artwork>
BGP update 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 10.0.0.0/8
TS: TS: TS: TS: TS:
CE1:T1 CE1:T1 CE1:T1 CE1:T1 CE1:T1
R1:T2 R1:T2 R1:T2 R1:T2
R2:T3 R2:T3 R2:T3
R3:T4 R3:T4
R4:T5
CE1--------->R1 ------------> R2 ------------> R3 ------------> R4 ------------> CE2
| | | |
| | | |
AS1 AS2
Figure 5
</artwork>
</figure>
</section>
</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 .
</t>
</section>
</section>
<section anchor="timestamp" title="Monitoring BGP Update propagation time">
<section anchor="architecture" title="An architecture to measure BGP Update propagation time">
<figure>
<artwork>
--------- -------
/ \ / \
RTR_SRC ----- | AS1 | ----- | AS2 | ---- RTR_DST1
\ / \ /
--------- ---------
| |
| |
--------- -------
/ \ / \
RTR_DST2 ---- | AS4 | | AS3 | ---- RTR_DST3
\ / \ /
--------- ---------
Figure 6
</artwork>
</figure>
<figure>
<artwork>
Single AS
-------------------------------------------
/ \
| RR1 ---------- RR2 |
| / \ \ |
| RTR_SRC1 \ RTR_DST1 |
| \ |
| RR3 |
| | |
| RTR_DST2 |
| |
\ /
-------------------------------------------
Figure 7
</artwork>
</figure>
<t>
Figure 6 and Figure 7 describes an interAS and a single AS scenario where a service provider wants to monitor BGP Update propagation time from a router to multiple routers.
In Figure 6, multiple probing routers are attached to multiple ASes. In Figure 7, all probing routers are in the same AS.
</t>
<t>An external tool should command RTR_SRC to originate a probing BGP path.
Each probing router is configured to match the path in its inspection list.
The BGP path would propagate across ASes whatever they are supporting BGP TS or not.
Each probing router would receive the BGP path and add timestamp information.
Authors suggest to implementors 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 RTR_DSTx. 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 each RTR_DSTx.</t>
<t>NetConf call to retrieve wrapping buffer information.</t>
<t>SNMP call to retrieve wrapping buffer information.</t>
<t>CLI command to retrieve wrapping buffer information.</t>
</list>
</t>
</section>
<section anchor="accuracy" title="Measurement accuracy">
<t>
For the solution to be accurate, it is mandatory for BGP Speaker to be synchronized. This could be achieved 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 S bit and SyncType fields are set to help operators to understand the accuracy of the timestamp measurements and being able to compare timestamps between them.
</t>
</section>
<section anchor="stale-info" title="Dealing with stale information">
<t>
<figure>
<artwork>
Single AS
-------------------------------------------
/ RTR_SRC2- 10/8 \
| / |
| RR1 ---------- RR2 |
| / \ \ |
| RTR_SRC1 \ RTR_DST1 |
| | \ |
| 10/8 RR3 |
| | |
| RTR_DST2 |
| |
\ /
-------------------------------------------
Figure 8
</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_DST1 will receive the path from RR2 with accurate timestamp (end to end propagation) but RTR_DST2 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 8, 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_DST2 will receive a BGP timestamp vector containing stale timestamp informations as well as new ones.
</t>
<t>
The case of sending stale timestamp information can also appear with a single originator as soon as some redundancy in the BGP design is involved (multiple RRs, multiple ASBRs ...).
</t>
<t>
An external tool that monitors BGP timestamp should take care about analysing only end to end propagation scenarios.
</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>
</list>
</t>
<t>Using BMP to monitor BGP update propagation may complexify the design of the monitor solution.</t>
</section>
<section anchor="deployment" title="Deployment considerations">
<t>
This solution is not intended to perform timestamp imposition on all BGP updates.
</t>
<t>
Service provider implementing the BGP timestamp attribute must be aware of the propagation rules
of the NLRIs to be inspected.
If we consider an implementation scenario, where a path for NLRI is already propagated, a new path
may appear and starts to be propagated, propagation of this new path may stop at a certain point because
a BGP Speaker may consider the old path as the best one. Another scenario, could be that the two paths are installed,
and for a BGP Speaker within the path vector, the best path is changing because of an IGP metric change, this BGP Speaker will send a
new BGP update and timestamp information of the path will be updated but will have no more sense : origin timestamp will be quite old, but timestamps recorded
after this BGP Speaker will be recent.
This kind of scenario is complex to understand.
</t>
<t>
The deployment scenario we are targeting is really to inspect some specific NLRIs identified by the service provider where the propagation rules are well known (see <xref target="timestamp"/> as an example).
Service provider may rely on existing NLRIs (real routes), or ephemeral NLRIs (dedicated NLRIs for beaconing). Whatever the NLRI used, the tool used by the service provider
to collect and interpret the timestamp must be aware of the propagation rules and must record events only if propagation is end to end (from originator to listener).
</t>
<t>
The inspection list should be kept as small as possible in order to not introduce processing overhead and as a consequence slow down propagation.
Implementors should take care about reducing as much as possible the processing overhead introduced by the inspection list and timestamp imposition.
</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 ressources.
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 detailled 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;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:28 |