draft-litkowski-idr-bgp-timestamp-01.txt

<[email protected]>
Newsgroups gmane.ietf.bmwg
Message-ID <21602_1425574821_54F88BA5_21602_1733_1_9E32478DFA9976438E7A22F69B08FF9215C3A1A3@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Hi BMWG Folks,

I'm currently try to work on a solution to monitor propagation time within a BGP controlplane.
You will find below a draft reference.

I'm looking for your feedback on the proposed solution especially on it's accuracy.

Thanks in advance,

Stephane


-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Thursday, March 05, 2015 17:58
To: Jeffrey Haas; LITKOWSKI Stephane SCE/IBNF; Keyur Patel; Keyur Patel; Jeff Haas; LITKOWSKI Stephane SCE/IBNF
Subject: New Version Notification for draft-litkowski-idr-bgp-timestamp-01.txt


A new version of I-D, draft-litkowski-idr-bgp-timestamp-01.txt
has been successfully submitted by Stephane Litkowski and posted to the IETF repository.

Name:		draft-litkowski-idr-bgp-timestamp
Revision:	01
Title:		Timestamp support for BGP paths
Document date:	2015-03-05
Group:		Individual Submission
Pages:		26
URL:            http://www.ietf.org/internet-drafts/draft-litkowski-idr-bgp-timestamp-01.txt
Status:         https://datatracker.ietf.org/doc/draft-litkowski-idr-bgp-timestamp/
Htmlized:       http://tools.ietf.org/html/draft-litkowski-idr-bgp-timestamp-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-litkowski-idr-bgp-timestamp-01

Abstract:
   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.

   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.

   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.

   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.


                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.