Re: [rbridge] announcing vlans question

Donald Eastlake <d3e3e3@gmail.com> Mon, 15 February 2010 22:47 UTC

Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85A628C12F for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Mon, 15 Feb 2010 14:47:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.947
X-Spam-Level:
X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SP+CDp6VtjH for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Mon, 15 Feb 2010 14:47:26 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 607BB3A7A4C for <trill-archive-Osh9cae4@lists.ietf.org>; Mon, 15 Feb 2010 14:47:26 -0800 (PST)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o1FMJDx9020265; Mon, 15 Feb 2010 14:19:14 -0800 (PST)
Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o1FMIadD020214 for <rbridge@postel.org>; Mon, 15 Feb 2010 14:18:38 -0800 (PST)
Received: by ewy2 with SMTP id 2so6103814ewy.5 for <rbridge@postel.org>; Mon, 15 Feb 2010 14:18:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NJqASF7ViP0WVsKPmkLt6Ci7B+3z/dOVF57GXOekHk0=; b=jrafiePGPFyXFiI/XEGBU1gJgAbMGYgdegbpO7OiJh9S3jDSH1tHBRDq+meeV4cUTG hoWH/gtPrEqzCQeuw2E9IBGTWrDods2D6O3qpYGs/tKyiVa3a6QhExCRN+OOZdobLSoB B5ITMrYbWo3IKGFLKTtNnPY73vJZ8j5IU3eo0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uywgfE9ovaKUWZryTnJhNJH+TOvJ2b6KxlHCsxyvi2tJ3PU3A/w5nBQKbgq4Zw7U7x xNro5DC4YAeRLCgRZxKtS3GbjFMTsa9SpWHSXIlDORklMB3lG2CTRwuYhDECQODvVjUr CAxiR9uLV3YrAQDNwe4MYcGFgilvN5cMQhibw=
MIME-Version: 1.0
Received: by 10.216.88.79 with SMTP id z57mr3626719wee.22.1266272314879; Mon, 15 Feb 2010 14:18:34 -0800 (PST)
In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893DC576D9F@SJEXCHCCR02.corp.ad.broadcom.com>
References: <9793EC0A42D76D4EB2A8F94D77E2138893DC576D91@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c1002150922l26a8803esa9095f7bc90944e4@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E2138893DC576D9F@SJEXCHCCR02.corp.ad.broadcom.com>
Date: Mon, 15 Feb 2010 17:18:34 -0500
Message-ID: <1028365c1002151418t39f56db5n54eed1db24cfdc11@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
To: Jeff Pickering <jeffpick@broadcom.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
Cc: "rbridge@postel.org" <rbridge@postel.org>
Subject: Re: [rbridge] announcing vlans question
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1239204044=="
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org

Hi Jeff,

On Mon, Feb 15, 2010 at 2:35 PM, Jeff Pickering <jeffpick@broadcom.com>wrote:

>  I understand the "cosiderable controversy" and think the argument goes
> something like this:
>
> - there should be a single designated vlan which is shared enabled among
> all rbs, in which case sending hellos only on that dvid is sufficient and
> safe.
> - but there may be a misconfiguration where this is not the case and
> multiple rbs may be appointed avf causing loops if you only send on the
> dvid.
> - to solve this problem the full announcing set is defined in the spec.
> this may still, in patholgical cases, result in multiple rbs being
>   appointed avf for the same vlan, but the AF bit and inhibition will
> result in only a single forwarder per-vlan.
> - in order to ensure safety in the zero configuration case, the full
> announcing set is the default.
>

That all sounds right to me.


> I am still concerned with scalability in cases of lots of adjs and lot of
> vlans,
>

There were people who argued very strongly for all RBridges always sending
Hellos on all enabled VLANs on all enabled port (except on ports configured
to use point-to-point Hellos).


> but also want to allow for "misconfiguration". I think there could be a way
> to start announcing on the "full set" as defined and then fall back to only
> the dvid if yoiu discover the dvid is enabled on all rbs on a link. It would
> work like this:
>
> - An rb that is not DR would only choose as desginated vlan one of its
> enabled vlans. Its view of the dvid would be included in the vlaf subtlv.
> - Such an rb that could not accept the DRs view of the dvid would continue
> to hello on its view if the dvid.
> - All rbs announce on the full set (per-spec DR status dependent) when an
> interface is enabled or the vlan set changes.
>
or a port becomes uninhibited.

> - When any rb hears a hello that has in its vlaf subtlv a dvid value not
> equal to its dvid, it sets a timer.
> - When the timer expires, an rb can fall back to only sending on the dvid.
>


I dont think this requires any spec change except for a non-dr refusing to
> accept as dvid a non-enabled vlan id. This would not affect anyone not
> desiring to implement the above. And it would also address the case of an
> RB sending absolutely no hellos, which IMO is extermely counter-intuitive
> and
> will cause network managers a lot of confusion.
>

I'm not sure what's so counter-intuitive about a misconfigured RBridge
acting oddly and not sending any Hellos. If all the RBridges on a link
aren't configured to have the same Desired Designated VLAN and to have that
VLAN enabled on their ports that connect to that link, something odd and
probably wrong is going on with the configuration. This is one of the first
things TRILL campus configuration tools should check for. Under your scheme,
I guess such a misconfigured RBridge would send Hellos, unless no VLAN was
enabled on the port, but there is no guarantee that any other RBridge could
hear the Hellos it was sending, so I'm not sure how much point there is to
it.


> Jeff
>

Thanks,
Donald


>
>  ------------------------------
> *From:* Donald Eastlake [mailto:d3e3e3@gmail.com]
> *Sent:* Monday, February 15, 2010 12:23 PM
> *To:* Jeff Pickering
> *Cc:* rbridge@postel.org
> *Subject:* Re: [rbridge] announcing vlans question
>
> Hi Jeff,
>
> On Mon, Feb 15, 2010 at 9:18 AM, Jeff Pickering <jeffpick@broadcom.com>wrote:
>
>>
>> If a non-drb is configured to announce on all vlans, but does not have the
>> vlan enabled that is the designated vlan
>> announce by the drb, the non-drb will send helos only on vlan for which it
>> is avf.
>>
>
> This is all on a per port basis.
>
> I assume you mean by "configured to announce on all vlans" that the
> Announcing Set for that port is set to all VLANs. Yes, in that case the
> non-drb's port will send Hellos only on VLANs for which it is an appointed
> forwarder.
>
> Generally speaking, if there are RBridge ports that don't have the
> designated VLAN enabled, arguably your network is mis-configured. Most
> commonly one would expect all the RBridges in a campus to be configured to
> designated the same VLAN if they are DRB and one would expect that that VLAN
> would be enabled on all RBridge ports connected to inter-RBridge links. But,
> of course, more complex configurations may be fine.
>
>
>>  But if such an rb is not avf on any
>> vlans, it looks like it will send no hellos. Or does such an rb not accept
>> the drb's desginated vlan in such a case?
>> Is there text addressing this is the spec?  All I see is the following
>> from 4.4.3:
>>
>>
>> RBridges send TRILL Hellos Outer.VLAN tagged with
>>    the Designated VLAN, unless that VLAN is not enabled on the port.
>>
>
> Right, the RBridge port does not send any Hellos, because sending Hellos
> would generally just add useless traffic. Consider:
>
> (1) Since the designated VLAN is disabled at the port, no inter-rbridge
> traffic can flow through the port (i.e., no TRILL encapsulated data or LSPs
> ...)
>
> (2) Since the port is not an appointed forwarder for any VLAN, no native
> traffic can flow through the port (i.e., no data will be picked up and
> encapsulated and no data will be decapsulated and sent.
>
> So the port is basically orphaned from the link, although there still are
> frames that could flow on the port, such as LLDP frames.
>
> There was considerable controversy in the working group over how many
> Hellos to send and the provisions in the current draft are the compromise
> that was arrived at. The parenthetical at the top of page 51 of the draft
> contemplates sending more Hellos than called for by the set operation
> expressions.
>
> Thanks,
> Donald
>
>  Jeff
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge@postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge