Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

Danny McPherson <> Wed, 30 April 2008 20:12 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 9531F3A69C9; Wed, 30 Apr 2008 13:12:32 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D19F93A6A53 for <>; Wed, 30 Apr 2008 13:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L7emSFdURl5e for <>; Wed, 30 Apr 2008 13:12:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E6C8D3A69C9 for <>; Wed, 30 Apr 2008 13:12:30 -0700 (PDT)
Received: by (Postfix, from userid 0) id B86672684A6; Wed, 30 Apr 2008 14:12:33 -0600 (MDT)
Received: from [] (VDSL-151-118-146-11.DNVR.QWEST.NET []) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by with SMTP; Wed, 30 Apr 2008 14:12:33 -0600 (MDT) (envelope-from
X-Avenger: version=0.7.8;; client-ip=; client-port=56682; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <>
From: Danny McPherson <>
To: "John G. Scudder" <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 14:12:18 -0600
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.919.2)
Cc: idr idr <>
Subject: Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Apr 30, 2008, at 11:45 AM, John G. Scudder wrote:
> The nice thing is that the feature is backward compatible and fails
> safe -- if the client doesn't know how to handle the community, then
> it sees itself in the ORIGINATOR_ID and drops the route.  No route, no
> routing information loop.  Granted the behavior of dropping the route
> is undesired, but not horrible.

Even your draft disagrees with this, else it wouldn't mention
the disabling RFC 1966 behavior (as opposed to the discard
based on ORIGINATOR_ID on the client that RFC 2796
introduced -  for no valid _protocol reason, mind you, which
annoys me considerably).  Along this vein, I would be quite
interested in someone providing an explanation of why this
behavior was changed from 1966 to 2796....

> Interesting -- one would have expected the vendor 'm' router to drop
> the routes even if it didn't understand ORIGINATOR_ID, due to the
> NEXT_HOP check.  I guess if the NEXT_HOP were getting rewritten...
> But in any event this particular case is academic because of the "fail
> safe" behavior discussed above -- any client that interoperates with a
> 2796 RR will fail safe.  (Any client that doesn't interoperate with a
> 2796 RR is arguably pretty broken at this point.)

Right, but see my point above...  This assumes all clients employ
the discard behavior of 2796.

> One of my co-authors may want to address this point.  From my PoV,
> suffice it to say there's real demand for the feature.

I'm sure there is demand to make 2547 configuration simpler, but
that doesn't mean it's something we should change fundamental
BGP behavior to facilitate.  I would be interested in here from your

> What is the redundant network state you're referring to?  The "address
> family overlays" I snipped out of the quote?

No, I've come to accept the AF overlays..   What troubles me is the fact
that we're using BGP to enable a RR to modify an update learned from
a client, and to reflect that update back to that client - just does  
good routing protocol hygiene to me, to save configuration overhead
on the client, when it'll surely be further required on the RRs.

Idr mailing list