Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt

Zhuangshunwan <> Thu, 26 March 2015 12:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BDFC81B2CD2 for <>; Thu, 26 Mar 2015 05:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YWxl-03Mpyas for <>; Thu, 26 Mar 2015 05:33:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EF931B2CCD for <>; Thu, 26 Mar 2015 05:33:19 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BQS75409; Thu, 26 Mar 2015 12:33:17 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 26 Mar 2015 12:33:15 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 20:33:08 +0800
From: Zhuangshunwan <>
To: Robert Raszuk <>, idr wg <>
Thread-Topic: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt
Thread-Index: AdBZK68bN1BCIhIeS2ydNnWIffKe0AOkHFBg
Date: Thu, 26 Mar 2015 12:33:07 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB98588D28952ENKGEML512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Mar 2015 12:33:23 -0000

Hi Robert,

I have a comment to the example in this document:

>9.2.  Example Wide Community Encoding

>     AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as
>     Amsterdam (100) or to peers marked Moscow (104), but not to peers
>     in New York (101).

If  AS 64496 has another peer AS (e.g., AS 10000),  AS 10000 not containing in Target TLV, and also not containing in Exclude Target TLV.
When AS 64496 sends a bgp route to AS 10000, what a policy it will be executed ?
Prepend or not prepend 4 TIMES to peer as 10000?

Maybe I misunderstand the case?


发件人: Idr [] 代表 Robert Raszuk
发送时间: 2015年3月8日 7:09
收件人: idr wg
主题: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt

A new version of I-D, draft-raszuk-wide-bgp-communities-05.txt
has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name:           draft-raszuk-wide-bgp-communities
Revision:       05
Title:          Wide BGP Communities Attribute
Document date:  2015-03-06
Group:          Individual Submission
Pages:          23

   Route tagging plays an important role in external BGP [RFC4271]
   relations, in communicating various routing policies between peers.
   It is also a very common best practice among operators to propagate
   various additional information about routes intra-domain.  The most
   common tool used today to attach various information about routes is
   through the use of BGP communities [RFC1997].

   Such information is important to allow BGP speakers to perform some
   mutually agreed actions without the need to maintain a separate
   offline database for each tuple of prefix and associated set of
   action entries.

   This document defines a new encoding which will enhance and simplify
   what can be accomplished today with the use of BGP communities.  The
   most important addition this specification makes over currently
   defined BGP communities is the ability to specify, carry as well as
   use for execution an operator's defined set of parameters.  It also
   provides an extensible platform for any new community encoding needs
   in the future.

The IETF Secretariat