[bmwg] draft-litkowski-idr-bgp-timestamp-01.txt

<stephane.litkowski@orange.com> Thu, 05 March 2015 17:00 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3A71A1A83 for <bmwg@ietfa.amsl.com>; Thu, 5 Mar 2015 09:00:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JHpQw8VuOpX for <bmwg@ietfa.amsl.com>; Thu, 5 Mar 2015 09:00:31 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13481A1A7F for <bmwg@ietf.org>; Thu, 5 Mar 2015 09:00:22 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 3C68C3740BF for <bmwg@ietf.org>; Thu, 5 Mar 2015 18:00:21 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 2444418004F for <bmwg@ietf.org>; Thu, 5 Mar 2015 18:00:21 +0100 (CET)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.247]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Thu, 5 Mar 2015 18:00:21 +0100
From: stephane.litkowski@orange.com
To: "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: draft-litkowski-idr-bgp-timestamp-01.txt
Thread-Index: AdBXZaIjVJq4l2dLR1e0MeCs29yAsg==
Date: Thu, 05 Mar 2015 17:00:20 +0000
Message-ID: <21602_1425574821_54F88BA5_21602_1733_1_9E32478DFA9976438E7A22F69B08FF9215C3A1A3@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821
Archived-At: <http://mailarchive.ietf.org/arch/msg/bmwg/r1sf0JiD-Tf5iKnTeCUBVte-Vao>
Subject: [bmwg] draft-litkowski-idr-bgp-timestamp-01.txt
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2015 17:00:35 -0000

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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
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.