[trill] Suggestion on RFC 6325 section 4.5.2, single parent ECMP link selection.

"Ramkumar Parameswaran (ramkumar)" <ramkumar@cisco.com> Wed, 22 August 2012 15:34 UTC

Return-Path: <ramkumar@cisco.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D6DEA21F85AA for <trill@ietfa.amsl.com>; Wed, 22 Aug 2012 08:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4J9jENY2wONU for <trill@ietfa.amsl.com>; Wed, 22 Aug 2012 08:34:49 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id A730B21F8598 for <trill@ietf.org>; Wed, 22 Aug 2012 08:34:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11007; q=dns/txt; s=iport; t=1345649688; x=1346859288; h=from:to:subject:date:message-id:mime-version; bh=x7urPArs2guwEEXdncPE+BtVi/IUFiwqxYSOO9TfIFg=; b=W2U1K08lSn0L+FzZujqjEJdo+cBr6jGQxocTlpLFfcHFv0tO0pJycL3W F/kBBXfDgUKrF0Melx0ddFEkhRuSHrzi2cqZES8Me6Km1itDhCYNf0WQW K2gnm3SgqeGfz/1o8tqFL667S5RD6pTjwFj+1TfcKPPqPsqnbcSN7GwUM s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAOv6NFCtJXG9/2dsb2JhbABFgkq3f4EHgicOBAEUPgIkAYEAJwQ1h2uXSYEooFOSJAOVUo4tgWaCYw
X-IronPort-AV: E=Sophos; i="4.77,808,1336348800"; d="scan'208,217"; a="111189741"
Received: from rcdn-core2-2.cisco.com ([]) by rcdn-iport-9.cisco.com with ESMTP; 22 Aug 2012 15:34:48 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com []) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7MFYmSD020012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <trill@ietf.org>; Wed, 22 Aug 2012 15:34:48 GMT
Received: from xmb-rcd-x15.cisco.com ([]) by xhc-rcd-x12.cisco.com ([]) with mapi id 14.02.0298.004; Wed, 22 Aug 2012 10:34:47 -0500
From: "Ramkumar Parameswaran (ramkumar)" <ramkumar@cisco.com>
To: "trill@ietf.org" <trill@ietf.org>
Thread-Topic: Suggestion on RFC 6325 section 4.5.2, single parent ECMP link selection.
Thread-Index: AQHNgHupUthoY2E1xEuAqXewoT2QYQ==
Date: Wed, 22 Aug 2012 15:34:47 +0000
Message-ID: <CC5A4A25.3C56%ramkumar@cisco.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--33.100600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_CC5A4A253C56ramkumarciscocom_"
MIME-Version: 1.0
Subject: [trill] Suggestion on RFC 6325 section 4.5.2, single parent ECMP link selection.
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Aug 2012 15:34:49 -0000


With regard to the Parallel Link check in section 4.5.2 of RFC 6325, item 3 talks about how to select links in multi-destination trees when a node in a multi-destination tree has a single parent connected to it by multiple links. The section in the RFC identifies how to select a link in the bundle,over which all multi-destination traffic may traverse, when the links are of type P2P or LAN links with pseudonode suppressed. Specifically, a single link is selected and traffic for all multi-destination trees is carried over the selected link.

When a node is connected to a single parent across several LAN links which advertise a pseudonode (when pseudonode is not suppressed), RFC 6325 section 4.5.1 already specifies a way to load balance multi-destination traffic across these links by pulling a unique link into each multi-destination tree.

This is illustrated in the following example

         |   Node B      | -> upstream, closer to tree root.


             /  |   | \

            |   |   |  |

            |01 02  |03|04

            |   |   |  |

             \  |   |  /


         |   Node A      |

Consider Node A and node B being connected to each other on 4 independent LAN links. Each of the four links above is a LAN link with a DRB elected and pseudo-node advertised. The number to the right of the link identifies the pseudo-node id operational on the link. In this situation, per 4.5.1, since seven byte system id is considered in load-balancing links across trees, other factors holding, link 01 will be assigned to Tree 1, link 02

will be assigned to tree 2 and so on.

However, if the links were P2P links with 01, 02, 03, and 04 being the extended circuit id of the node with higher system id (B, say), then per 4.5.2, link 04 would be pulled into all multi-destination trees, with no load-balancing on any of the other links.

For P2P links and pseudonode suppressed LAN links, we were wondering whether the following variant can be accommodated, so that multi-destination traffic can be  spread over more links, with better link utilization:

Modified Approach: Once a dominant link-type is identified using the tie-break rule specified in item 3 (P2P or LAN link with suppressed pseudo node), if there is more than one link of the dominant type, then such links are arranged in ascending order of parent's Extended Circuit ID or Pseudonode ID,  given serial numbers starting with 0, and assigned to trees with a logic similar to the multi-parent ECMP case:

Link on Tree T = (T-1) mod N where N is the number of parallel links

The parallel link check in section 4.5.2 must be modified to allow only the

adjacency that is selected for the tree that the packet arrived on.

No change in metric advertisement is needed with regard to the rest of the network, and in line with what is mentioned in 6325, the notion of mapping continues to remain local to the two adjacent nodes RB1-RB2.

Please let us know if the approach suggested above is feasible or if we may have missed something.