Re: [trill] TRILL OAM Requirements: available paths

Donald Eastlake <d3e3e3@gmail.com> Mon, 30 April 2012 01:27 UTC

Return-Path: <d3e3e3@gmail.com>
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 673E321F85A3 for <trill@ietfa.amsl.com>; Sun, 29 Apr 2012 18:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.743
X-Spam-Level:
X-Spam-Status: No, score=-103.743 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ziEfHYq8r2dd for <trill@ietfa.amsl.com>; Sun, 29 Apr 2012 18:27:10 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1621F8534 for <trill@ietf.org>; Sun, 29 Apr 2012 18:27:10 -0700 (PDT)
Received: by iazz13 with SMTP id z13so4355237iaz.31 for <trill@ietf.org>; Sun, 29 Apr 2012 18:27:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=UL1f3gNHdVqFPmPuSlCa4RcaLiZgfhAiu/+DlGYVLnI=; b=tpowRS8P4j0BJFGm4dfmUq0J+UaE9DIe+FUwVRl8k7+a5d5DSzMEHa2bUKKNCNVsGp j2CDgQo4RaVP0hJR2ZV+8kTzFH3wqKFezs1FrWQow2/sylF8rmf/ypv8L+YUD53vgcub Ay2MZYJLdTlimzHonHZvt9z6cZDfGgkx3UynQxzKK07Z3l9iW6uGZJPqPx9+J+9ITzJ4 7UMfq2C9uxLhVCfqjcjHEzoTlme5a+b05vCROOosJl5aMyiQMDyZD2Zx+pkbriE8ruzE uX/GM7W1u9VX9xHg/1iUm7sd4pox8Qpv98X1sLMbcD8e8b/QNp5IJJpiYgrSZvEHSvkT QZKQ==
Received: by 10.50.184.133 with SMTP id eu5mr8966986igc.13.1335749230172; Sun, 29 Apr 2012 18:27:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.59.201 with HTTP; Sun, 29 Apr 2012 18:26:50 -0700 (PDT)
In-Reply-To: <4F9CB95E.4030902@acm.org>
References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <OF909960BD.8F0E0541-ON872579ED.007407A1-882579ED.0074C8A0@us.ibm.com> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> <4F9CB95E.4030902@acm.org>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 29 Apr 2012 21:26:50 -0400
Message-ID: <CAF4+nEFvxSHEF+7+yL_fwPFO=ftjCXFamShhs22iv0YmuhGvbQ@mail.gmail.com>
To: trill@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [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: Mon, 30 Apr 2012 01:27:11 -0000

I don't think the wording "all paths" should ever be used. If you the
it literally, it would even include paths that go through some
RBridges more than once.

I don't particularly like "all ECMP paths" either. I think the
clearest wording is "all least cost paths" if you are talking about
known unicast. (And "all distribution tree paths" if you were talking
about multi-destination frames.)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark <nordmark@acm.org> wrote:
> On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote:
>>
>> Of course it is possible. The IS-IS topology table provide the
>> information on all available ECMP paths to a specific destination when
>> the egress RBRidge nickname is known. That is what TRILL unicast
>> forwarding table all about. Not sure why you are saying it is not
>> possible to know all ECMP paths.
>
>
> You are talking about what Santosh called "all theoretically available
> paths". Those can be determined from IS-IS.
>
> But the document talks about "all available paths" and I don't know what
> that is supposed to mean. Do you have a succinct definition?
>
> What is clear to me is that there can be a subset of the paths that are
> determined from IS-IS that would never be used, because no entropy in a
> packet would every pick that path.
>
> Is the requirement in the document that the OAM solution should be able to
> test those paths?
>
>
>> What path among available paths to be selected for a specified is a
>> local matter. That is what all about flow entropy discovery. Like I
>> stated earlier how it is discovered is a framework and solution issue.
>
>
> Agreed.
>
>
>> If you need some reference how it is done in the MPLS world RFC 4379 is
>> a good reference.
>
>
> AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop.
> TRILL does, which makes these aspects different.
>
> Regards,
>   Erik
>
>
>> -----Original Message-----
>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf
>> Of Erik Nordmark
>> Sent: Friday, April 27, 2012 4:07 PM
>> To: Santosh Rajagopalan
>> Cc: trill@ietf.org
>> Subject: Re: [trill] TRILL OAM Requirements: available paths
>>
>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote:
>>>
>>> I agree, the wording needs to be tightened to say "all possible ecmp
>>> paths" rather than "all available paths". An operator working out
>>> R1-R2 communication is interested in all possible paths data traffic
>>> could take rather than all theoretically available paths.
>>
>>
>> The issue is that there is nothing in the TRILL dataplane nor IS-IS
>> control plane which helps the operator determine that some paths
>> (through RB121 and RB112 in the example) are not possible; the ECMP
>> input and hashing is a completely local matter on each RBridge.
>>
>> It isn't useful to state a requirement around something that can't be
>> determined.
>>
>>     Erik
>>
>>>
>>>
>>> From: Erik Nordmark<nordmark@acm.org>
>>> To: trill@ietf.org
>>> Date: 04/27/2012 09:53 AM
>>> Subject: [trill] TRILL OAM Requirements: available paths Sent by:
>>> trill-bounces@ietf.org
>>> ----------------------------------------------------------------------
>>> --
>>>
>>>
>>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> trill mailing list
>>> trill@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trill
>>>
>>>
>>
>> _______________________________________________
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
>>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill