Re: [trill] Thoughts on active-active edge

Sunny Rajagopalan <sunny.rajagopalan@us.ibm.com> Wed, 12 December 2012 00:44 UTC

Return-Path: <sunny.rajagopalan@us.ibm.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 8E02011E80AE for <trill@ietfa.amsl.com>; Tue, 11 Dec 2012 16:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 AbaVSOB7gysA for <trill@ietfa.amsl.com>; Tue, 11 Dec 2012 16:44:55 -0800 (PST)
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7C21E80AF for <trill@ietf.org>; Tue, 11 Dec 2012 16:44:55 -0800 (PST)
Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <trill@ietf.org> from <sunny.rajagopalan@us.ibm.com>; Tue, 11 Dec 2012 17:44:54 -0700
Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 11 Dec 2012 17:23:46 -0700
Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id B62361FF0041 for <trill@ietf.org>; Tue, 11 Dec 2012 17:23:26 -0700 (MST)
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBC0NXg1298922 for <trill@ietf.org>; Tue, 11 Dec 2012 17:23:33 -0700
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBC0NX7D016519 for <trill@ietf.org>; Tue, 11 Dec 2012 17:23:33 -0700
Received: from d03nm127.boulder.ibm.com ([9.16.16.115]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBC0NXfY016515 for <trill@ietf.org>; Tue, 11 Dec 2012 17:23:33 -0700
In-Reply-To: <CAFOuuo4zvX5AtD-oGRRftuZaKmhY7C7-SvDjznMOdzUj+Q3fGQ@mail.gmail.com>
References: <CAFOuuo4zvX5AtD-oGRRftuZaKmhY7C7-SvDjznMOdzUj+Q3fGQ@mail.gmail.com>
To: Radia Perlman <radiaperlman@gmail.com>
MIME-Version: 1.0
X-KeepSent: A64C269F:4ABA3691-87257AD2:00001E14; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: <OFA64C269F.4ABA3691-ON87257AD2.00001E14-88257AD2.0002264A@us.ibm.com>
From: Sunny Rajagopalan <sunny.rajagopalan@us.ibm.com>
Date: Tue, 11 Dec 2012 16:23:30 -0800
X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF2|October 8, 2012) at 12/11/2012 17:23:32, Serialize complete at 12/11/2012 17:23:32
Content-Type: multipart/alternative; boundary="=_alternative 0002264988257AD2_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12121200-7282-0000-0000-000011F801CC
Cc: trill@ietf.org
Subject: Re: [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: Wed, 12 Dec 2012 00:44:56 -0000

Hi, Radia
I like this idea a lot better than the other proposals floating around. 
The +ve is that it can be done with today's ISIS. The -ve is that you'll 
need a minor hardware change -  today's hardware generally doesn't have 
the ability to use a different source rbridge depending on whether the 
packet is unicast or multicast. 

ISIS on  an rbridge that is emulating a pseudonode nickname can send out 
mac reachability information for endnodes attached to it, associating the 
mac addresses with the pseudonode nickname. Any multicast group with local 
receivers must also be advertised as belonging to the pseudonode.

At the other end, hardware already has the ability to "fix" mac entries so 
that they don't get rewritten when new information comes in. I do think 
this is necessary, because I believe we will see mac flips not just in the 
unicast-multicast interleave case, but also in the pure multicast case 
(load balancing could be using the layer 4 header, and that could cause 
different links to be used, even when the smac and dmac stays the same).

This means, of course, that if the mac moves to an rbridge that's not part 
of the pseudonode group then the new rbridge will have to send out an 
update so that everyone else can fix up their entries and remove the 
"fixed" property from the entry in hardware.

The approaches we've seen so far are complex, require the maintenance of 
multiple trees, use up the nickname space, and have constraints in the 
external non-trill topologies that can be used. This approach has none of 
the problems, and has my vote.
--
Sunny




From:   Radia Perlman <radiaperlman@gmail.com>
To:     trill@ietf.org, 
Date:   12/11/2012 12:54 PM
Subject:        [trill] Thoughts on active-active edge
Sent by:        trill-bounces@ietf.org



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_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill