Re: [Idr] I-D Action: draft-dong-idr-node-target-ext-comm-01.txt

Robert Raszuk <> Mon, 08 July 2019 12:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E35912017F for <>; Mon, 8 Jul 2019 05:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0A4Hkwu_TRc1 for <>; Mon, 8 Jul 2019 05:02:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 063DC1201C6 for <>; Mon, 8 Jul 2019 05:02:30 -0700 (PDT)
Received: by with SMTP id h18so10275333qtm.9 for <>; Mon, 08 Jul 2019 05:02:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/pFxd8ts+ExcPjm3Hr+yh3+rHrnOoq2ApIIRK6YGnH8=; b=YDOhyrvcprs71TAOcdhgNkOmjv5mOxn2Ugi52xP0NWdr5IqtYJ2EjQMi8zeII2LlhG pwXKoiTdk4Jqkl0eDx2+Y4F9WytPmKOrWgWqIXmE3qqKAmj/OoKjlJpy0xQPNB26Qw2d LoWeOt0ZuPOy77MZ5d8ZoRolvHuBtTj2ph5hVOU4RIQzf0d4dUpjeR2rnnaHkUKZC2pU feYAqi5oLld3aHVIpx8sHFO8Tqf68fEqAbflX+Yi642hjYJ8lFdBgpSNQ0etTigH+2MQ 0iQ7zrDWPL3BwqzHanb+lM17tEJ01CHu28faWEOqbDZ8hPKgLYvLHM1R2X4Pulv5TGU5 xxlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/pFxd8ts+ExcPjm3Hr+yh3+rHrnOoq2ApIIRK6YGnH8=; b=Zyce5vzgzVbbKlckYxpEXd+OXgS5+V7FLpxBuVV8TWgOWmJP4WvWHd1FOrXzM4cLk+ WEGUGwRdNpSovc1cLkaTaOQ2QYojrkdrF15rnNZEqknkGLoA6GqyrtH4ZzJl4I4MQd4Y 80rYkADbWDQ8RValXchFoYtGsXBHdWFMxT96hlvclw6wAJ3XtAJZTJEtJeFTL1joppbv TNlwo1UWN9cz1er5+RCwkoekOw7+K2QAaODkM0Ezu4VcSPCoIGsW0IlEUc9gSy+Zxe2S UhUXwt1STFTSqFDElA136Q8wzKThll0BhvA3UKVs7B+nufbfPajkQKeOVvTGxyzzXl0m Oimw==
X-Gm-Message-State: APjAAAX1f8rd/SAuh3ugVePogurP/2EMmtTxt+1VOH7dcVBag5exTQ94 7HloyI4Hpmp4zr4EnlktFOy5KjzgRide3O9e+6U87Q==
X-Google-Smtp-Source: APXvYqzrPgifbmXohQaluAvLlf/JAZqVSRvp2PehKHkE0eqpi0TotjEzS6+zs8vDyguO5QdfXSV5Kqilxunrl4CTkWU=
X-Received: by 2002:a0c:e751:: with SMTP id g17mr14652857qvn.197.1562587349893; Mon, 08 Jul 2019 05:02:29 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 08 Jul 2019 14:02:18 +0200
Message-ID: <>
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <>, "Dongjie (Jimmy)" <>, Zhuangshunwan <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000ebd9e1058d2a37b4"
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-dong-idr-node-target-ext-comm-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2019 12:02:36 -0000

Dear authors,

Let me start by restating that using a p2mp protocol to distribute
information in a p2p fashion is a bad thing. Your proposal just further
encourages folks to do continue use of BGP along those lines which is not a
good thing.

Now few questions/observations:

* You are explicitly breaking RFC4456. The node which does your policy
enforcement - let's call it - BGP Policy based Update Replicator (BGP PUR)
- no longer follows RFC4456 recommendations of route propagation from
client to non-client and from non-client to client. Sure you may define
such new functional block in BGP but IMHO this is no longer a vanilla Route
Reflector with "just a little bit more filtering" :)

* Assume that in my 500 PEs IPv6 network I want to distribute some
information to 100 of them. Very conservative case. So with the current
draft I will need to send with each route BGP Extended Community Attribute
of the 2K size. Well assume that BGP Extended Message is not there at least
on one of the PEs the proposed scheme breaks. Did you ever consider to
actually define new attribute for this and support wildcard match/extended
community match length ?

* Can you describe the rational for keeping the Node Targets ext
communities still in the update when reflecting it to one of the targets on
the list ?

* Have you thought of using 4 octet BGP identifier instead of peering
address ? First you no longer need to struggle with IPv6 length, you no
longer worry about link-local peerings and you no longer need to touch all
senders when interface addresses get renumbered.

* RRs in general where designed and optimized to reflect all received
updates. RTC came and applied some outbound filters. Now your proposal
comes and applies new set of per peer dynamic filters. Putting
implementation details aside at min your proposal must define which filter
is more important RTC pushed from target or your Target RT pushed from

* How does your proposal works with RR hierarchy ? It seems pretty clear
that it only works with flat sender -- RR -- receiver architecture.

* How does your proposal work with confederations ?

* What happens when session to a peer goes down ? Would you now need to
remodify the list of Node Target Ext Comms and resend to other IBGP peers
including that node which you have lost IBGP to ?

Essentially what you are defining is to push dynamic filtering policy from
the src to the RRs hoping that RRs will honor it and apply proper outbound
filters. Moreover you are also adding new behaviour for RRs to modify
content of BGP attributes upon reflection. I think you are assuming that
all applicable implementations support dynamic update groups or are you
assuming that whenever such Node Target Ext Community arrive on the RR it
should switch for a given SAFI to per peer update generation ?


> On Mon, Jul 8, 2019 at 1:13 PM <> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>         Title           : BGP Extended Community for Identifying the
> Target Node
>         Authors         : Jie Dong
>                           Shunwan Zhuang
>                           Gunter Van de Velde
>         Filename        : draft-dong-idr-node-target-ext-comm-01.txt
>         Pages           : 7
>         Date            : 2019-07-08
> Abstract:
>    BGP has been used to distribute different types of routing and policy
>    information in the network.  In some cases, the information
>    distributed may be only intended for one or several particular
>    receiving BGP nodes in the network.  However, BGP does not have a
>    general mechanism for designating the receiving node of the routing
>    information.  This document defines a new type of BGP extended
>    community called "Node Target".  The mechanism of using the Node
>    Target extended community to steer BGP route distribution to
>    particular BGP nodes is specified.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or