[trill] Thoughts on active-active edge

Radia Perlman <radiaperlman@gmail.com> Tue, 11 December 2012 20:53 UTC

Return-Path: <radiaperlman@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 04F7111E8097 for <trill@ietfa.amsl.com>; Tue, 11 Dec 2012 12:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFrdt1gad90K for <trill@ietfa.amsl.com>; Tue, 11 Dec 2012 12:53:07 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1488421F84D9 for <trill@ietf.org>; Tue, 11 Dec 2012 12:53:06 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id fc26so4470288vbb.31 for <trill@ietf.org>; Tue, 11 Dec 2012 12:53:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=95341daxn6WohJ/PSFkELGXz9bOZN6lNQEiAprXHWc0=; b=gW5EWHVHMf42PiISRh114iNc78I94EtQ53NgUHF9/xJUIfsHiIuqcfp5PfBowozxo6 pF/ZIV7uytgFrgr9Lt97YKB8RgbcGIGi0KxWG5uylLzHJEYvTrORQLIKgvTYSdLnU0zu xz+pM0VwKvel0YGDm/HDNS9qaJIDxmJHm5frMOGpWIHRtPlR6Av5CDbPfNxMvSTvECEm ueTElKMAyFLqZlV+NolS3SEkrrClcScXGWxTsW2PXKFGptApDE4s53mUhU0CUkKQr+tX eLymM+5nQanamXndMmhiunOSN9oNgTTLUsCP+tSspDbpIMTfxH6SHAeTPz1pfB2m1Fvt Grug==
MIME-Version: 1.0
Received: by 10.52.92.144 with SMTP id cm16mr10563364vdb.36.1355259186515; Tue, 11 Dec 2012 12:53:06 -0800 (PST)
Received: by 10.58.207.138 with HTTP; Tue, 11 Dec 2012 12:53:06 -0800 (PST)
Date: Tue, 11 Dec 2012 12:53:06 -0800
Message-ID: <CAFOuuo4zvX5AtD-oGRRftuZaKmhY7C7-SvDjznMOdzUj+Q3fGQ@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: trill@ietf.org
Content-Type: multipart/alternative; boundary=20cf307cff96640dc504d099de76
Subject: [trill] Thoughts on active-active edge
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: Tue, 11 Dec 2012 20:53:08 -0000

I'm not too happy about any of the proposed solutions to the active-active
edge issue, and wondering if there might be a simpler approach.

To review the problem:

Suppose R1, R2, and R3 are all attached to a set of endnodes (say, through
a hypervisor).  Let's say "E" is one of the endnodes multihomed through R1,
R2, R3.  Let's say "R8" is a distant RBridge (one several hops away from
R1, R2, and R3).

a) If R1, R2, and R3 use their own nickname when encapsulating a frame from
E, then R8 will see frequent changes of E's location (between R1, R2, and
R3).  Furthermore, it would be nice if the path from R8 to E could go via
the shortest path (if, for instance, R2 is much closer to R8 than R1).

b) If R1, R2, and R3 use a pseudonode nickname (say P) for all the
multihomed endnodes, then the RPF check doesn't work when the "wrong"
RBridge injects the encapsuated packet into the campus.  (the tree will
have only one of R1, R2, or R3 attached to the pseudonode, say R2, so when
R2 injects using the pseuodnode as ingress nickname, the RPF check will
work, but it will not work if R1 or R3 inject).

--------------

So...this might have been discussed before, but it might not hurt to look
at it with fresh eyes again.



*******************
Proposed rule: R1, R2, and R3 should use the pseudonode nickname when
encapsulating unicast, but use their own nickname when encapsulating
multidestination.
***********************

Result:  R8 will see endnode changes for E, but not very frequent;  R8 will
only see changes when traffic from E alternates between multidestination
and unicast.

Question: Are perceived endnode moves a problem?  Why?

If endnode changes are, for some reason, a problem, we could have R1, R2,
and R3 announce in LSPs, that they are attached to pseudonode P as an
active/active group, and therefore, endnode moves between P and anything in
the set {R1, R2, R3} should not raise alarms.  Better yet, would be to say
if endnode E is attached to P, then don't move it to {R1, R2, or R3}.

Radia