[trill] TRILL OAM Requirements: available paths

Erik Nordmark <nordmark@acm.org> Fri, 27 April 2012 16:53 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD00421F8633 for <trill@ietfa.amsl.com>; Fri, 27 Apr 2012 09:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edep7-3nM0jW for <trill@ietfa.amsl.com>; Fri, 27 Apr 2012 09:53:27 -0700 (PDT)
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2640B21F85FB for <trill@ietf.org>; Fri, 27 Apr 2012 09:53:27 -0700 (PDT)
Received: from [10.33.22.115] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3RGrOpQ031742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 09:53:25 -0700
Message-ID: <4F9ACF05.9070302@acm.org>
Date: Fri, 27 Apr 2012 09:53:25 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: trill@ietf.org
References: <4F9ACE0E.7030408@sonic.net>
In-Reply-To: <4F9ACE0E.7030408@sonic.net>
X-Forwarded-Message-Id: <4F9ACE0E.7030408@sonic.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [trill] TRILL OAM Requirements: available paths
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: Fri, 27 Apr 2012 16:53:27 -0000

Two requirements use the wording "all available paths." and "all 
available ECMP paths.", respectively and I'm not sure I know what that 
means.

Take the following example picture:

                R1
               /  \
              /    \
             /      \
            /        \
           /          \
        RB11          RB12
        /  \          /  \
       /    \        /    \
    RB111  RB112  RB121  RB122
       \      \    /      /
        \      \  /      /
         \      \/      /
          ------R2------

We can see that there are 4 paths with 3 hops to get from R1 to R2, with 
two layers of ECMP decisions. But how many available paths are there?

Given that the RBridges make independent ECMP decisions, and how they do 
that is a local matter, it could be the case that for any packet, if R1 
picks the left link, then R11 would also pick the left link; if R1 picks 
the right link, then R12 also picks the right link.
Thus there would be no packet (data or OAM) that would cause packets 
between R1 and R2 to pass via RB112 or RB121.

Even if we ignore that as unlikely, there is still the fact that R1 
can't easily tell how many (shortest) paths there might be between it 
and R2. With single-level TRILL the LSDB could be used to tell, but if 
we ever go to multi-level that wouldn't be the case any more.
And even if R1 knows that there are 4 potential paths, it can't format a 
data packet (or format the flow entropy in an OAM packet) in such a way 
that particular paths get chosen by downstream ECMP decisions.

Thus for any notion of "all available paths" that make sense to me, we'd 
need an OAM approach that can explore the topology one hop at a time and 
at each hop explore all the possible ECMP choices. Using the entropy 
doesn't help with this (but the entropy is critical for following the 
path taken by a particular flow of data packets).

Hence it would be good to clarify what the assumptions are behind this 
notion of all available paths.

Thanks,
     Erik