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

Danny McPherson <> Wed, 30 April 2008 21:19 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 970723A6CF4; Wed, 30 Apr 2008 14:19:50 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E902A3A6A4E for <>; Wed, 30 Apr 2008 14:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7e34C6lQ4kgu for <>; Wed, 30 Apr 2008 14:19:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 177323A6CD6 for <>; Wed, 30 Apr 2008 14:19:44 -0700 (PDT)
Received: by (Postfix, from userid 0) id B3267268494; Wed, 30 Apr 2008 15:19:47 -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 15:19:47 -0600 (MDT) (envelope-from
X-Avenger: version=0.7.8;; client-ip=; client-port=56772; 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 15:19:31 -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

> Not so.  The reason for that is to allow RR hierarchy to be used.
> Since the point of the draft is that the route's originator has to see
> it, it's important that RR's transparently pass it through.  I'm at a
> loss to see how you can interpret this as a tacit disagreement with my
> statement above.

Then why the 1966 text at all, that was my point.

> I suggest you take it up with that RFC's authors or check the archives
> -- I don't know the answer.  (I would say that implementability can  
> be  
> a "valid_protocol reason" though.)

Heh, that's the high road :-)

> Well, that OR they properly implement the base spec and drop routes
> which have themselves as NEXT_HOP.
> Do you really think that a client which doesn't interoperate with 2796
> RRs is viable in a network at all?  Especially one which also violates
> the base spec by not checking the NEXT_HOP?

I've seen it before in a real network.

> OK, I don't see where this is "redundant network state" to speak of.
> Well, I guess for each route treated in this way there's one extra
> route exported from the RR to the route's originator -- but then again
> that is a route which the RR has to export to the rest of the network
> anyway.  So the RR does in effect no extra work.  The PE receiving the
> route does store a little extra stuff, but then again there would be
> some state for that route if it was locally exported between VRFs
> too.  Seems to me as though state -- both dynamic and configuration --
> is more-or-less a wash.

Well, upon thinking about this a bit more, it also seems silly to
me that a network would be architected in such a way as to allow
problems with an 'upstream' RR to affect connectivity between
two VRFs on the same PE.  I'd think to an operator trying to ensure
availability would be worth the configuration overhead, even if
some folks consider the extra 'state' a wash.

Idr mailing list