Re: [trill] RPF entries ..RFC 6325 section 4.5.2

Donald Eastlake <> Tue, 22 May 2012 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDC7721F8505 for <>; Tue, 22 May 2012 06:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.669
X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q4RT5DfCHFnf for <>; Tue, 22 May 2012 06:23:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6D3AE21F84E6 for <>; Tue, 22 May 2012 06:23:01 -0700 (PDT)
Received: by yhq56 with SMTP id 56so6424684yhq.31 for <>; Tue, 22 May 2012 06:23:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jt3NBjG4/j1P3cT++4yBRDjP4X6ukU0miJu8f7pHQSo=; b=ckWd63Ph1bBa4ItoOthl56K5g7znP7OjNID5dVvRx6ES2M6Nwe9GnIc9bO6E65KgnZ tfDSRpVz7WzSKfDVmOiXwNSmuyA3BH5YsEuqnbwVBtrQgSLr0kdS1oP5SG+pieCwQO3i +CKvgiKwbQ0JsEXkxg8BNIIEC9kwYq5AhctQK3vKdTRLkXjP/T/W3fOghNQCVwbJh2mn sjkSycEEuw1uJfccjW80sfC7C7uTqJvXwoSmwDXIDFkHkI3zVTzdQpwThEoAQdUoo9bT vwmVh74G6M8dnGe5056w9W6gs2rP2QADSyggTJzsQQIVQO/QDy4CG9Pknv0tO3MWmZ/x abyQ==
Received: by with SMTP id rc3mr9367146igb.58.1337692980526; Tue, 22 May 2012 06:23:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 22 May 2012 06:22:40 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Tue, 22 May 2012 09:22:40 -0400
Message-ID: <>
To: gururam m <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [trill] RPF entries ..RFC 6325 section 4.5.2
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 May 2012 13:23:02 -0000


On Tue, May 22, 2012 at 6:14 AM, gururam m <> wrote:

> Hi,
>     I have a query related to the RPF check from RFC 6325.
> Let us say a TRILL domain setup has about 6 RBridges each with a single
> nickname and 6 multicast trees are computed by each RBridge in the TRILL
> domain and the trill domain setup is as shown below.
> RB1-------RB2--------RB3
>  |         |          |
>  |         |          |
> RB4-------RB5--------RB6
> As per my understanding each RB will have RPF entries that are equal
> to the ingress interfaces on that RB.

I think you are talking about TRILL Data traffic so I would avoid
using the word "ingress" here. In TRILL "ingress" normally refers to
receiving native traffic, not TRILL Data frames.

> For e.g RB1 has two interfaces hence it has two RPF entries and RB2,
> RB5 will have 3 RPF entries since it has 3 interfaces or to state
> the number of RPF entries on each RBridges depends on the number of
> ports that are part of the multicast trees on that particular
> RBridge.

TRILL does not constrain how the RPF (Reverse Path Forwarding) Check
entries are organized.

If you think about it as a lookup under the triple { tree number;
port; ingress RBridge nickname } that returns a boolean, then there
are a lot more entries than you are talking about. In this case
(number of ports)*(number of trees)*(number of possible ingress
RBridges) or (number of ports)*30. If you think about it as a lookup
under the double { tree number; ingress RBridge nicknme } that returns
the expected receiving port that you then compare with the actul
receiving port for the check, then there are 30 entries at each
RBridge in your example. (This assumes that no RBridge is announcing
the trees it is using as a subset of the computed trees. If one does,
it reduces the RPF Check information.)

Other methods are possible.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> Please correct me if my understanding is not correct.
> Regards
> Ram