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

[Robert Raszuk <[e-mail]>]

Hello Shunwan,

The expected behaviour when processing such wide community would be not to
execute the prepend to AS 10000.

Of course if you already have other policy permitting such append it will
be executed, but this is outside of the scope.

Cheers,
r.



On Thu, Mar 26, 2015 at 1:33 PM, Zhuangshunwan <[e-mail]>
wrote:

>  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?
>
>
>
> --Shunwan
>
>
>
> *发件人:* Idr [mailto:[e-mail]] *代表 *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
> URL:
> http://www.ietf.org/internet-drafts/draft-raszuk-wide-bgp-communities-05.txt
> Status:
> https://datatracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/
> Htmlized:
> http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-05
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-raszuk-wide-bgp-communities-05
>
> Abstract:
>    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
>
>
>