[rbridge] AF change handling

[Suresh Boddapati <[e-mail]>]

I think there is a problem wrt handling the change in
AF status.

Consider the following example:

- A is an RBridge with two ports P1, P2 and P3 (all in
the same inner VLAN X). It does not have any
adjacencies on P1 and P2 so it ends up being the AF
for VLAN X on P1 and P2. P3 leads to the TRILL cloud.
- There is a host H1 in VLAN X connected to port P1 of
A.
- R is a remote RBridge connected to a host H2 in VLAN
X on one of its ports.

When H2 sends a frame for H1, through the learning
mechanism, R associates H1 with RBridge A.
Subsequently, R will TRILL Unicast all frames destined
for H1 to A. So far so good.

Now assume that a new RBridge B comes up on the
segment connected to P1 and becomes the DRB and
appoints itself as the AF for VLAN X on that port. So
A is no longer the AF for VLAN X on P1. Per the spec,
nothing happens at this point.

Frames sent by H2 to H1 will continue to be sent to A
by R, but A can no longer decapsulate and put them on
P1, since it is not the AF. What is A to do? 

This is similar to the recently discussed issue of
sending BPDU with TCN flag set when AF changes so that
the "local" bridges can clear their cache. One option
is for A to send something similar in its LSP.  If A
sends something saying "My AF state changed for this
VLAN on one of my ports", and all RBridges flush all
the MACs they had associated with A, it would work,
but this has scale implications. It may not be
desirable to flush all MACs associated with A just
because its AF status changed on one of its ports. It
may still be AF on other ports (in this example, A is
still AF for VLAN X on P2 and there may be a lot of
conversations active on that port, and all those MAC
addresses will get flushed unnecessarily).

Thanks,

Suresh



_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m4ULBUoM024863 for <[e-mail]>; Fri, 30 May 2008 14:11:35 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-3.tower-128.messagelabs.com!1212181889!2448482!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 29296 invoked from network); 30 May 2008 21:11:29 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 30 May 2008 21:11:29 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m4ULBIvq000167 for <[e-mail]>; Fri, 30 May 2008 14:11:28 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m4ULBI6s005801 for <[e-mail]>; Fri, 30 May 2008 16:11:18 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m4ULBHX1005795 for <[e-mail]>; Fri, 30 May 2008 16:11:17 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 30 May 2008 17:11:15 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] AF change handling
thread-index: AcjB4OTGptNWrlmkScqCsmtwwAQSvgAiKBxw
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Suresh Boddapati" <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m4ULBUoM024863
Cc: [e-mail]
Subject: Re: [rbridge] AF change handling
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2008 21:12:51 -0000
Status: RO
Content-Length: 5451

Hi Suresh,

Thanks for brining this up. I don't think there is any way of doing this
perfectly. You have your choice in a space of frames being black-holed,
addresses being unnecessarily forgotten, or scaling problems. 

Of course, you can always use the explicit end station address
distribution instances of TRILL IS-IS to fix this. Also it is not a
problem for multi-destination frames as, if necessary, the VLAN pruning
of distribution trees will be adjusted automatically. It might be a good
idea to add a specific provision that if Rbridge-A ceases to be an
appointed forwarder for VLAN-x for any ports, which is all you can tell
from the link state database currently, then all other Rbridges should
forget any addresses in VLAN-x they have learned from data which point
to Rbridge-A.

However, all that still does not address the worst case where Rbridge-A
ceases to be an appointed forwarder for VLAN-x on one or more of its
ports while remaining an appointed forwarder for that VLAN on one or
more other port.

One way to "fix" that, to the extent that bridges do, would be to have
an optional explicit topology change message to advise other Rbridges
that they should forget (or at least reduce their cache timer) any
addresses learned from data for the source Rbridge of the topology
change message. This message could be per VLAN or could have the VLANs
affected encoded in it...

Another possibility would be for an Rbridge to send out amnesia frames
listing the addresses it has learned locally on that port that the VLAN
that it is no longer going to be appointed forwarder for, telling other
Rbridges to forget those specific addresses for that VLAN... This would
probably work for modest numbers of addresses but that won't help if the
source Rbridge had suffered from cache overflow and might result in a
big burst of traffic if a lot of addresses are send out on a appointed
forwarder status change.

To avoid extra messages and do this via the link state data base, you
would need some additional encoding. I don't see how just some one bit
flag per Rbridge per VLAN would do it as you can never tell that any
particular Rbridge will see each successive update from any other
Rbridge, as far as I know. It might see update N and N+k but never see
N+1 through N+k-1 and the bit might have flipped twice over that
sequence. So I think you would have to do something which was logically
equivalent to the following: include in the link state data base for
each Rbridge a hash function of the ports for which it is appointed
forwarder for VLAN-x. For example, SHA-1 of the sorted MAC addresses of
all the ports which are appointed forwarders for VLAN-x. Then, when
Rbridge-1 notices this hash change for Rbridge-2 for VLAN-x, it would
know it could forget or shorten the cache timer for all VLAN-x addresses
that it learned for data from Rbridge-2.

If we had implemented the Port ID feature suggested by Silvano in the
base protocol, that would provide a way to send out a port specific
topology change message, as opposed to having to do things a the
granularity of Rbridges. (This feature is currently described in
draft-eastlake-trill-rbridge-options-00.txt.)

I suppose if we need to address this in the base protocol, right now I'd
favor the link state database technique described above.

Thanks,
Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Suresh Boddapati
Sent: Thursday, May 29, 2008 5:43 PM
To: [e-mail]
Subject: [rbridge] AF change handling

I think there is a problem wrt handling the change in
AF status.

Consider the following example:

- A is an RBridge with two ports P1, P2 and P3 (all in
the same inner VLAN X). It does not have any
adjacencies on P1 and P2 so it ends up being the AF
for VLAN X on P1 and P2. P3 leads to the TRILL cloud.
- There is a host H1 in VLAN X connected to port P1 of
A.
- R is a remote RBridge connected to a host H2 in VLAN
X on one of its ports.

When H2 sends a frame for H1, through the learning
mechanism, R associates H1 with RBridge A.
Subsequently, R will TRILL Unicast all frames destined
for H1 to A. So far so good.

Now assume that a new RBridge B comes up on the
segment connected to P1 and becomes the DRB and
appoints itself as the AF for VLAN X on that port. So
A is no longer the AF for VLAN X on P1. Per the spec,
nothing happens at this point.

Frames sent by H2 to H1 will continue to be sent to A
by R, but A can no longer decapsulate and put them on
P1, since it is not the AF. What is A to do? 

This is similar to the recently discussed issue of
sending BPDU with TCN flag set when AF changes so that
the "local" bridges can clear their cache. One option
is for A to send something similar in its LSP.  If A
sends something saying "My AF state changed for this
VLAN on one of my ports", and all RBridges flush all
the MACs they had associated with A, it would work,
but this has scale implications. It may not be
desirable to flush all MACs associated with A just
because its AF status changed on one of its ports. It
may still be AF on other ports (in this example, A is
still AF for VLAN X on P2 and there may be a lot of
conversations active on that port, and all those MAC
addresses will get flushed unnecessarily).

Thanks,

Suresh



_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4UJLurB018949 for <[e-mail]>; Fri, 30 May 2008 12:21:57 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 30 May 2008 12:21:46 -0700 (PDT)
Received: from [192.168.1.100] ([24.17.188.148]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 30 May 2008 12:21:46 -0700 (PDT)
Date: Fri, 30 May 2008 12:21:40 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Suresh Boddapati <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] AF change handling
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2008 19:22:48 -0000
Status: RO
Content-Length: 3103

Yes. What you're saying is correct. If on a layer 2 cloud, the appointed 
forwarder changes from being R1 to R2, then
all the remote RBridges that think R1 is the proper egress RBridge for 
all the endnodes on that cloud will be
sending traffic for those hosts to the wrong RBridge.

I'm not sure what can be done about that. Eventually these host entries 
will time out.
We could do something like what you suggest, namely, having R1 (when it 
is no longer appointed forwarder on one of
its links) send a multicast advisory message saying "use a short cache 
timer for all my VLAN X endnodes because I am no longer
appointed forwarder on one of my links". Perhaps this advisory message 
could even list some (or all, if they fit) of the MAC addresses
that were on that link.

This seems like it might be a good idea. It would be a MAY or SHOULD to 
send such a message.
It would be a MAY or SHOULD to look at the message.
It would be sent as a VLAN X multicast, so it would only be looked at by 
VLAN X forwarders on all the links.
We'd have to define a format for it.

Radia



Suresh Boddapati wrote:
> I think there is a problem wrt handling the change in
> AF status.
>
> Consider the following example:
>
> - A is an RBridge with two ports P1, P2 and P3 (all in
> the same inner VLAN X). It does not have any
> adjacencies on P1 and P2 so it ends up being the AF
> for VLAN X on P1 and P2. P3 leads to the TRILL cloud.
> - There is a host H1 in VLAN X connected to port P1 of
> A.
> - R is a remote RBridge connected to a host H2 in VLAN
> X on one of its ports.
>
> When H2 sends a frame for H1, through the learning
> mechanism, R associates H1 with RBridge A.
> Subsequently, R will TRILL Unicast all frames destined
> for H1 to A. So far so good.
>
> Now assume that a new RBridge B comes up on the
> segment connected to P1 and becomes the DRB and
> appoints itself as the AF for VLAN X on that port. So
> A is no longer the AF for VLAN X on P1. Per the spec,
> nothing happens at this point.
>
> Frames sent by H2 to H1 will continue to be sent to A
> by R, but A can no longer decapsulate and put them on
> P1, since it is not the AF. What is A to do? 
>
> This is similar to the recently discussed issue of
> sending BPDU with TCN flag set when AF changes so that
> the "local" bridges can clear their cache. One option
> is for A to send something similar in its LSP.  If A
> sends something saying "My AF state changed for this
> VLAN on one of my ports", and all RBridges flush all
> the MACs they had associated with A, it would work,
> but this has scale implications. It may not be
> desirable to flush all MACs associated with A just
> because its AF status changed on one of its ports. It
> may still be AF on other ports (in this example, A is
> still AF for VLAN X on P2 and there may be a lot of
> conversations active on that port, and all those MAC
> addresses will get flushed unnecessarily).
>
> Thanks,
>
> Suresh
>
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4UDxjLG026474 for <[e-mail]>; Fri, 30 May 2008 06:59:46 -0700 (PDT)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4UDxiW4006461 for <[e-mail]>; Fri, 30 May 2008 13:59:45 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4UDxiv9044097 for <[e-mail]>; Fri, 30 May 2008 09:59:44 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UDqEBM011942; Fri, 30 May 2008 09:52:14 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m4UDq3va011937; Fri, 30 May 2008 09:52:03 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Fri, 30 May 2008 09:52:03 -0400
From: James Carlson <[e-mail]>
To: Suresh Boddapati <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] AF change handling
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2008 14:01:13 -0000
Status: RO
Content-Length: 2494

Suresh Boddapati writes:
> the "local" bridges can clear their cache. One option
> is for A to send something similar in its LSP.  If A
> sends something saying "My AF state changed for this
> VLAN on one of my ports", and all RBridges flush all
> the MACs they had associated with A, it would work,
> but this has scale implications. It may not be

I agree that we need either a flush mechanism or some sort of a
redirection.  But I disagree on the severity of the issue: all that's
necessary is that we make DRB selection intentionally stable so that A
doesn't _want_ to give up its AF state on that port when B switches
on.

If you make the change sufficiently unlikely, then the effects of it
are much less interesting.  Letting administrators know that they can
hurt themselves by toying with priority is probably the right answer.

As for mitigating the problem, the active DRB switch-over case you
mention is actually the simple one.  The harder one is the case where
A is disconnected from a few networks where it was the DRB, some small
time period elapses, and then B starts up on the networks A has left.

In the active switch case, the routers involved "know" who the players
are and could (presumably) arrange to have some sort of summary
information distributed after the DRB election dust settles.  In the
blind case, nobody has any clue what's just happened.  As far as A
knows, the links are just disconnected.  As far as B knows, he's the
first RBridge to enter the room.  Neither knows about the other.

One way to deal with this would be to have an RBridge that either
loses its established DRB status on a port or has a port
administratively shut down (or hardware failure) withdraw its nickname
and then reinsert.  Nickname withdrawl already has to cause a flush of
the forwarding entries that map to that nickname.

A sufficiently clever implementation that has zillions of ports and is
concerned about having to flush on each port shut down could
presumably run multiple instances, use multiple nicknames, and split
the ports over the nicknames.  When you get down to a 1-to-1 mapping
of nicknames to ports, the flush-related overhead is minimized -- at
the cost of extra LSPs and nickname exhaustion.  Somewhere in the
middle is a happy medium.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from web81303.mail.mud.yahoo.com (web81303.mail.mud.yahoo.com [68.142.199.119]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m4TLginT008001 for <[e-mail]>; Thu, 29 May 2008 14:42:45 -0700 (PDT)
Received: (qmail 56753 invoked by uid 60001); 29 May 2008 21:42:44 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=YhWKLjlxm3N31MhXBsjucvNtuxlA8iuINNE2cndVlYGas+ZQCasQxJJ/L53qzIGOHNi6egRME6e+xbDwEEW2f56PdcKTAQZ00uzkaR8mqO/cdIB2ygCSU9Rf5AqvqT8/5YBh0oaEYlKUkDKT1wIJhx6qq+0UcjLIVlNEnKB5Uvo=;
X-YMail-OSG: ZilO6YkVM1n6kVHdFpRxI8nt0EhrqWyX4Hk7qsGM5XbWPij4DZWlUKrOwA6VivMw6A--
Received: from [66.129.224.36] by web81303.mail.mud.yahoo.com via HTTP; Thu, 29 May 2008 14:42:44 PDT
Date: Thu, 29 May 2008 14:42:44 -0700 (PDT)
From: Suresh Boddapati <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] AF change handling
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 May 2008 21:45:16 -0000
Status: RO
Content-Length: 1757

I think there is a problem wrt handling the change in
AF status.

Consider the following example:

- A is an RBridge with two ports P1, P2 and P3 (all in
the same inner VLAN X). It does not have any
adjacencies on P1 and P2 so it ends up being the AF
for VLAN X on P1 and P2. P3 leads to the TRILL cloud.
- There is a host H1 in VLAN X connected to port P1 of
A.
- R is a remote RBridge connected to a host H2 in VLAN
X on one of its ports.

When H2 sends a frame for H1, through the learning
mechanism, R associates H1 with RBridge A.
Subsequently, R will TRILL Unicast all frames destined
for H1 to A. So far so good.

Now assume that a new RBridge B comes up on the
segment connected to P1 and becomes the DRB and
appoints itself as the AF for VLAN X on that port. So
A is no longer the AF for VLAN X on P1. Per the spec,
nothing happens at this point.

Frames sent by H2 to H1 will continue to be sent to A
by R, but A can no longer decapsulate and put them on
P1, since it is not the AF. What is A to do? 

This is similar to the recently discussed issue of
sending BPDU with TCN flag set when AF changes so that
the "local" bridges can clear their cache. One option
is for A to send something similar in its LSP.  If A
sends something saying "My AF state changed for this
VLAN on one of my ports", and all RBridges flush all
the MACs they had associated with A, it would work,
but this has scale implications. It may not be
desirable to flush all MACs associated with A just
because its AF status changed on one of its ports. It
may still be AF on other ports (in this example, A is
still AF for VLAN X on P2 and there may be a lot of
conversations active on that port, and all those MAC
addresses will get flushed unnecessarily).

Thanks,

Suresh





Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4SNYwQ3012170 for <[e-mail]>; Wed, 28 May 2008 16:34:59 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 28 May 2008 16:34:53 -0700 (PDT)
Received: from [192.168.1.100] ([24.17.188.148]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 28 May 2008 16:34:52 -0700 (PDT)
Date: Wed, 28 May 2008 16:34:46 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Rbridge setting of BPDU Topology Change Flag
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 28 May 2008 23:36:51 -0000
Status: RO
Content-Length: 1493

This seems harmless and, as you said, polite. I think it should be a 
SHOULD. For a bit more explanation,
it's for bridges inside the link that have learned the direction of 
destinations off the link. A bridge was
thinking that D was in the direction of the previous VLAN forwarder, so 
if S (on the link) is
talking to D (off the link), a bridge might not forward it to the new 
VLAN forwarder, and D might
therefore not receive the traffic.

The topology change notification tells the bridges on the link to switch 
to a short cache timer, getting
rid of incorrect cache entries fairly quickly.


Radia



Eastlake III Donald-LDE008 wrote:
> Assume a bridged LAN with one or more bridges in connected to an Rbridge
> port. The bridges in that bridged LAN will, in general, learn MAC
> addresses based on native frames sent out that port by the Rbridge. When
> the appointed forwarder status of that Rbridge port changes, it seems to
> me it would be polite for the Rbridge to send a BPDU with the topology
> change flag set so as to clear MAC address cache entries in the
> bridge(s) that may no longer valid.
>
> Donald
> ====================================================
>  Donald E. Eastlake 3rd      [phone] (work)
>  Motorola Laboratories
>  111 Locke Drive
>  Marlborough, MA 01752 USA
>  [e-mail]
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m4RIsnbX018140 for <[e-mail]>; Tue, 27 May 2008 11:54:50 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-119.messagelabs.com!1211914488!25775070!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 18497 invoked from network); 27 May 2008 18:54:48 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 27 May 2008 18:54:48 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m4RIsctH005965 for <[e-mail]>; Tue, 27 May 2008 11:54:48 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m4RIsb22016703 for <[e-mail]>; Tue, 27 May 2008 13:54:37 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m4RIsbTs016696 for <[e-mail]>; Tue, 27 May 2008 13:54:37 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 27 May 2008 14:54:35 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rbridge setting of BPDU Topology Change Flag
thread-index: AcjAKxt9Tojud0s/Tu6Aqs5/ZFCQYg==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m4RIsnbX018140
Subject: [rbridge] Rbridge setting of BPDU Topology Change Flag
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 27 May 2008 18:55:32 -0000
Status: RO
Content-Length: 667

Assume a bridged LAN with one or more bridges in connected to an Rbridge
port. The bridges in that bridged LAN will, in general, learn MAC
addresses based on native frames sent out that port by the Rbridge. When
the appointed forwarder status of that Rbridge port changes, it seems to
me it would be polite for the Rbridge to send a BPDU with the topology
change flag set so as to clear MAC address cache entries in the
bridge(s) that may no longer valid.

Donald
====================================================
 Donald E. Eastlake 3rd      [phone] (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [e-mail]



Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4NM0kt7025590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 23 May 2008 15:00:48 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m4NM0ZtB028973; Fri, 23 May 2008 17:00:35 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 23 May 2008 17:00:34 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 23 May 2008 17:00:33 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] [Fwd: A Review of TRILL architecture document]
Thread-Index: Aci8+kAJ5eN+R0EjQIqpdH28+P2aYgAGtErA
References: <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "Pekka Savola" <[e-mail]>
X-OriginalArrivalTime: 23 May 2008 22:00:34.0807 (UTC) FILETIME=[6D291070:01C8BD20]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m4NM0kt7025590
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] [Fwd: A Review of TRILL architecture document]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2008 22:01:39 -0000
Status: RO
Content-Length: 10989

Pekka,

	Thanks for taking the time to do this review.

	Please see comments in line below.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Erik Nordmark
> Sent: Friday, May 23, 2008 1:13 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] [Fwd: A Review of TRILL architecture document]
> 
> This didn't appear to make it to the list.
> 
>     Erik
> 
> 
> -------- Original Message --------
> Subject: A Review of TRILL architecture document
> Date: Mon, 19 May 2008 14:58:47 +0300 (EEST)
> From: Pekka Savola <[e-mail]>
> To: [e-mail]
> CC: [e-mail], "W. Mark Townsley" 
> <[e-mail]>
> References: <[e-mail]>
> 
> (Let's hope this gets through to the list.)
> 
> In Philly meeting, I was volunteered to review the
> trill-rbridge-arch-05 document. Here are my comments on it.
> 
> substantial
> -----------
> 
> 1) the role and the timing of the document is not clear to me.  I like
> architecture documents that also serve as a shorter overview on the
> technology.  This document accomplishes this goal only partially but
> maybe its role is meant to be different.  The reason is that very many
> fundamental technical choices are left open in this document, to be
> defined in the protocol specification(s).

The timing of this document was dictated by the charter, and has been
ammended at least once already.  The original chartered completion
date was roughly a year earlier than the current chartered completion
date, and the draft is already late for that date (March, 2008).  Note
that the current scheduled completion for the protocol specififation -
also March, 2008 - represents significantly less of a delay, since the
protocol specification was originaly expected to complete not earlier
than 6 months _after_ the architecture specification.

See http://www.ietf.org/html.charters/trill-charter.html

Per working group instruction, the current version of the draft is
constrained _not_ to make choices the working group has deemed to
be appropriate for the protocol specification.

The closest match for the term systems architecture as the working
group consistently seems to identify it is something between the
1st and 8th definitions given in Wikipedia - i.e. -

1) The fundamental organization of a system, embodied in its components,

   their relationships to each other and the environment, and the 
   principles governing its design and evolution. 
   From ANSI/IEEE 1471-2000.

and

8) The structure of components, their interrelationships, and the 
   principles and guidelines governing their design and evolution over 
   time.

There are many other definitions of the term (clearly, since there are
at least 6 other definitions in Wikipedia - which are only "between 
these two defintions as a matter of physical placement), but these two 
are close to what I believe we are trying to achieve.  You may want to
note that - defined this way - an architecture is supposed to leave 
design details to design documents.

In addition, several working group members have asked that this ID/RFC
should provide a tutorial of the technology (much like your expectation
appears to be).  I think this is accomplished in section 5.  Could you
please provide a somewhat more detailed explanation of how the current
draft "accomplishes this goal only partially"?

> 
> This raises the question, what purpose is being served by publishing
> the architecture document now, in the form of "these are the options
> we're thinking of right now, we'll decide something later, or do
> something else completely"?  Would the document be clearer and more
> useful if we waited at least for the base protocol to finish (so we
> could nail down most of the uncertainties) before pushing this out?

The document serves multiple purposes as it is now:

o  It serves to document the considerations that apply to any design
   that might be applied to solving the problems defined in the PS&A
   draft.
o  It attempts to document specific considerations and choices made
   in the current protocol design specification.
o  It attempts to provide a tutorial of the technological approach.

In my opinion, if the architecture document is postponed much further,
it will have been completely overcome by events, and should be allowed
to retire gracefully.  In particular, I see little purpose in having
an architecture document that describes the "architecture" specific to
an existing design.

> 
> 2) there are two aspects of security which haven't been very well
> addressed (not in the protocol document either):
> 
>   a) zero-configuration deployment vs hijacks from hosts.  If I
> understand correctly, and end station could download an rbridge
> implementation, run it, and participate in campus IS-IS routing, get
> elected as root rbridge and redirect all traffic to itself.  This
> seems like a new threat, and seems worse than somewhat similar STP
> root bridge attack. (You can also deploy switches with STP disabled
> depending on topology but here that would not suffice.)

There is some confusion of terminology here, at least as I understand
it.  Architecurally, there is nothing about the technology that makes
it necessary to elect a "root rbridge" and the default assumption is
that each ingress serves as the "root" of a multi-point distribution
tree.

For the unicast case, the term "root rbridge" has no architectural
meaning whatsoever.

I suspect that the term you may mean is Designated RBridge - or (from
the protocol's terminology) Designated Forwarder.

However, the "security considerations" section clearly states that a
"configuration free" deployment requires an appropriate trust model.

It also states that - in the event that the deployment does not meet
this criteria - then the existing extensions that apply to routing
protocols (IS-IS specifically, in the current protocol design), can
be applied in the use of these protocols by RBridges.

Another thing to consider is that the architecture document is not
an instance of protocol design and - as such - is not implementable.
As such, publishing this document poses absolutely no security risk
to the Internet.  Hence, the contents of the security considerations
section are intended (as is the rest of the document) to provide the
"principles and guidelines" for use in design documents (in the case
of "security considerations", expectations of security considerations
in design documents).

> 
>   b) flooding attacks.  Currently a host may 1) send frames with
> destination addresses that no end station has in order to flood all
> the switches with traffic, or 2) send frames with lots of source
> addresses in order to overload the filtering database of bridge(s).
> 
> The architecture describes an option that IS-IS routing could be used
> (in suggested non-default mode) to carry end-station MAC addresses
> within the campus.  This implies a new threat because previously the
> MAC address information was not signalled between switches using a
> control plane protocol, it was part of data.  It is not clear how the
> IS-IS protocol and its SPF machinery is capable of dealing with this
> issue.  I recall that SPF computation can be CPU-intensive while it
> runs, and if the network topology / MAC addresses never converge, this
> could be bad.

This is a good point.  I propose to add text to the security section to
point out the relative risks for certain types of attack under different
asusmptions about how MAC destination forwarding information might be
acquired.

I will think about a specific proposed addition to the section to do
this and send it out later (late next week, or early the week after).

I welcome any suggestions you might have, or any suggestions anyone
might have - for that matter.

As you say, the default mode for acquiring this information (from the
data-plane) also has security issues which may be worse under certain
circumstances.  This is implied in the (brief) paragraph that mentions
the trade-off considerations that apply in selecting the learning mode
(page 22, next to last paragraph).

> 
> editorial
> ---------
> 
> s/desitnation/destination/
> 
> In S 5.2:
> 
>          In the DRB example, if the destination MAC address of a
received
>          frame does not correspond to a learned MAC destination
address
>          at an egress interface, it will forward the frame on all
>          interfaces for which it is either the designated RBridge.
> 
> Difficulties in parsing.  Should "either" be removed?

Yes to both of these.  Thanks for pointing them out.

> 
> Section 5.3.1.[123] are listed as such in TOC yet the notation in the
> body is 5.3.1-[123].  I suspect the former is more appropriate.

Yes, but that format is recognized by idnits as an "innappropriate use
of IP addresses" because of the #.#.#.# format that results.  To avoid
this annoying warning, I have been (trying to) consistently manually
change the output from generic text-printing the word document format
such that it uses the #.#.#-# format for the small number of sections
where this (annoying little) problem comes up.

> 
> In S 5.5.1:
> 
>          The link between (802.1D) bridges B-1 and B-2 is meant to be
>          disabled by STP.  In the RBridge case, however, there is no
>          indication (from STP) that this link is redundant.  
> Moreover, in
>          order to avoid breaking bridge learning, either RB-a or RB-b
>          will be the DR and - as a result, only one of the links (B-
>          1<=>RB-a, B-2<=>RB-b) will get used.
> 
> s/DR/DRB/ or something else?

DRB.  Again, thanks.

> 
>          [2]   Touch, J., R. Perlman, (ed.) "Transparent 
> Interconnection
>                of Lots of Links (TRILL): Problem and Applicability
>                Statement", work in progress, draft-touch-trill-prob-
>                00.txt, November, 2005.
> 
> This ref should be updated to point to draft-ietf-trill-prob.

Yes.

> 
> On Thu, 1 May 2008, Erik Nordmark wrote:
> > At the TRILL WG meeting in Philadelphia you volunteered to 
> review the
> > TRILL architecture document and send comments (or a "It is 
> fine" email)
> > to the WG mailing list.
> >
> > Can you review it in the next few weeks? If not, let us know.
> >
> > The document is at
> > www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-05.txt
> >
> > Please send comments on the document to the WG mailing list.
> >
> > If you have some other concerns please send them to the co-chairs.
> >
> >    Erik and Donald
> >
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4NHLHhi027677 for <[e-mail]>; Fri, 23 May 2008 10:21:18 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.17.57]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4NHLHrn013216 for <[e-mail]>; Fri, 23 May 2008 17:21:17 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4NHLG5Z122255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2008 10:21:17 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 May 2008 10:21:13 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] [Fwd: Re: Review of TRILL architecture document]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2008 17:21:43 -0000
Status: RO
Content-Length: 1334

Russ asked me to forward this to the list.

-------- Original Message --------
Subject: Re: Review of TRILL architecture document
Date: Tue, 13 May 2008 14:04:46 -0400
From: Russ White <[e-mail]>
To: Erik Nordmark <[e-mail]>
CC: W. Mark Townsley <[e-mail]>,        Eastlake III 
Donald-LDE008 <[e-mail]>
References: <[e-mail]>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've spent some time today going through this, and don't see any
problems....

:-)

Russ

Erik Nordmark wrote:
| At the TRILL WG meeting in Philadelphia you volunteered to review the
| TRILL architecture document and send comments (or a "It is fine" email)
| to the WG mailing list.
|
| Can you review it in the next few weeks? If not, let us know.
|
| The document is at
| www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-05.txt
|
| Please send comments on the document to the WG mailing list.
|
| If you have some other concerns please send them to the co-chairs.
|
|     Erik and Donald
|

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKdg+ER27sUhU9OQRAqGyAKDv6rGjjkxkknkCDzFtlvy4ypXTaACg1uyj
uC5l842xIhTdMA6j+iWrYis=
=GVCe
-----END PGP SIGNATURE-----


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4NHK8Xt027242 for <[e-mail]>; Fri, 23 May 2008 10:20:08 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.108.38]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4NHK3qU012601 for <[e-mail]>; Fri, 23 May 2008 17:20:03 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4NHK1wg122228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2008 10:20:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 May 2008 10:20:01 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Agenda items for Dublin?
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2008 17:20:31 -0000
Status: RO
Content-Length: 152

What are the items that we to discuss face-to-face in Dublin? We don't 
seem to have many open issues left in the protocol spec.

   Erik and Donald




Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4NHCeNY024181 for <[e-mail]>; Fri, 23 May 2008 10:12:41 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4NHCd2D019945 for <[e-mail]>; Fri, 23 May 2008 17:12:40 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4NHCUeJ122034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2008 10:12:36 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 May 2008 10:12:30 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] [Fwd: A Review of TRILL architecture document]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2008 17:13:45 -0000
Status: RO
Content-Length: 4748

This didn't appear to make it to the list.

    Erik


-------- Original Message --------
Subject: A Review of TRILL architecture document
Date: Mon, 19 May 2008 14:58:47 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: [e-mail]
CC: [e-mail], "W. Mark Townsley" <[e-mail]>
References: <[e-mail]>

(Let's hope this gets through to the list.)

In Philly meeting, I was volunteered to review the
trill-rbridge-arch-05 document. Here are my comments on it.

substantial
-----------

1) the role and the timing of the document is not clear to me.  I like
architecture documents that also serve as a shorter overview on the
technology.  This document accomplishes this goal only partially but
maybe its role is meant to be different.  The reason is that very many
fundamental technical choices are left open in this document, to be
defined in the protocol specification(s).

This raises the question, what purpose is being served by publishing
the architecture document now, in the form of "these are the options
we're thinking of right now, we'll decide something later, or do
something else completely"?  Would the document be clearer and more
useful if we waited at least for the base protocol to finish (so we
could nail down most of the uncertainties) before pushing this out?

2) there are two aspects of security which haven't been very well
addressed (not in the protocol document either):

  a) zero-configuration deployment vs hijacks from hosts.  If I
understand correctly, and end station could download an rbridge
implementation, run it, and participate in campus IS-IS routing, get
elected as root rbridge and redirect all traffic to itself.  This
seems like a new threat, and seems worse than somewhat similar STP
root bridge attack. (You can also deploy switches with STP disabled
depending on topology but here that would not suffice.)

  b) flooding attacks.  Currently a host may 1) send frames with
destination addresses that no end station has in order to flood all
the switches with traffic, or 2) send frames with lots of source
addresses in order to overload the filtering database of bridge(s).

The architecture describes an option that IS-IS routing could be used
(in suggested non-default mode) to carry end-station MAC addresses
within the campus.  This implies a new threat because previously the
MAC address information was not signalled between switches using a
control plane protocol, it was part of data.  It is not clear how the
IS-IS protocol and its SPF machinery is capable of dealing with this
issue.  I recall that SPF computation can be CPU-intensive while it
runs, and if the network topology / MAC addresses never converge, this
could be bad.

editorial
---------

s/desitnation/destination/

In S 5.2:

         In the DRB example, if the destination MAC address of a received
         frame does not correspond to a learned MAC destination address
         at an egress interface, it will forward the frame on all
         interfaces for which it is either the designated RBridge.

Difficulties in parsing.  Should "either" be removed?

Section 5.3.1.[123] are listed as such in TOC yet the notation in the
body is 5.3.1-[123].  I suspect the former is more appropriate.

In S 5.5.1:

         The link between (802.1D) bridges B-1 and B-2 is meant to be
         disabled by STP.  In the RBridge case, however, there is no
         indication (from STP) that this link is redundant.  Moreover, in
         order to avoid breaking bridge learning, either RB-a or RB-b
         will be the DR and - as a result, only one of the links (B-
         1<=>RB-a, B-2<=>RB-b) will get used.

s/DR/DRB/ or something else?

         [2]   Touch, J., R. Perlman, (ed.) "Transparent Interconnection
               of Lots of Links (TRILL): Problem and Applicability
               Statement", work in progress, draft-touch-trill-prob-
               00.txt, November, 2005.

This ref should be updated to point to draft-ietf-trill-prob.

On Thu, 1 May 2008, Erik Nordmark wrote:
> At the TRILL WG meeting in Philadelphia you volunteered to review the
> TRILL architecture document and send comments (or a "It is fine" email)
> to the WG mailing list.
>
> Can you review it in the next few weeks? If not, let us know.
>
> The document is at
> www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-05.txt
>
> Please send comments on the document to the WG mailing list.
>
> If you have some other concerns please send them to the co-chairs.
>
>    Erik and Donald
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4JKr9xf002098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 19 May 2008 13:53:10 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m4JKr8ou028616; Mon, 19 May 2008 15:53:08 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 19 May 2008 15:53:08 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 19 May 2008 15:53:07 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] long-awaited review comments ondraft-ietf-trill-rbridge-arch-05
Thread-Index: Aci20dkp7WcXMJ3xSDOM7bqGTyN05ADH9XcA
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 19 May 2008 20:53:08.0134 (UTC) FILETIME=[5780C460:01C8B9F2]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m4JKr9xf002098
Cc: TRILL/RBridge Working Group <[e-mail]>
Subject: Re: [rbridge] long-awaited review comments ondraft-ietf-trill-rbridge-arch-05
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2008 20:53:28 -0000
Status: RO
Content-Length: 1211

James,

	I did thank you for your review and comments and I
did not mean to do so in a perfunctory way.  I sincerely
appreciate your comments and the time you spent making
them.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:[e-mail]] 
> Sent: Thursday, May 15, 2008 5:15 PM
> To: Eric Gray
> Cc: TRILL/RBridge Working Group
> Subject: RE: [rbridge] long-awaited review comments 
> ondraft-ietf-trill-rbridge-arch-05
> Importance: High
> 
> Eric Gray writes:
> > 	While I personally agree with most of your comments, I do
> > not believe that I am at liberty to make changes along the lines
> > of many of the ones you suggest, because the existing text is the 
> > result of WG direction or prior consensus/decisions.
> 
> To be clear: I wasn't asking you (personally) to make any changes
> without working group consensus.
> 
> During the last IETF meeting in Philadelphia, there was a call for
> volunteers to read the document and offer comments on the list,
> because the document shouldn't go forward if it hasn't had review.  I
> offered my time up to do that review, and as a result, I was offering
> comments on the document.
> 



Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4FLUA8q021816 for <[e-mail]>; Thu, 15 May 2008 14:30:11 -0700 (PDT)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4FLUAAg004447 for <[e-mail]>; Thu, 15 May 2008 21:30:10 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4FLU9Gv007783 for <[e-mail]>; Thu, 15 May 2008 17:30:09 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m4FLFALI024897; Thu, 15 May 2008 17:15:10 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m4FLF79w024894; Thu, 15 May 2008 17:15:07 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 15 May 2008 17:15:07 -0400
From: James Carlson <[e-mail]>
To: Eric Gray <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: TRILL/RBridge Working Group <[e-mail]>
Subject: Re: [rbridge] long-awaited review comments ondraft-ietf-trill-rbridge-arch-05
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 May 2008 21:30:45 -0000
Status: RO
Content-Length: 27371

Eric Gray writes:
> 	While I personally agree with most of your comments, I do
> not believe that I am at liberty to make changes along the lines
> of many of the ones you suggest, because the existing text is the 
> result of WG direction or prior consensus/decisions.

To be clear: I wasn't asking you (personally) to make any changes
without working group consensus.

During the last IETF meeting in Philadelphia, there was a call for
volunteers to read the document and offer comments on the list,
because the document shouldn't go forward if it hasn't had review.  I
offered my time up to do that review, and as a result, I was offering
comments on the document.

> 	There were many reasons why I had initially made the "DRB
> assumption" and you have pointed out several of them.  However,
> I was given very explicit direction by the WG to remove the DRB
> assumption, which ultimately made it necessary to describe all
> of the specific complications involved in doing anything else.

Yep; understood.  If the consensus is to leave the architecture
document wishy-washy due to high level equivocation like this, then I
can certainly live with it.  I'm implementing to the protocol specs
rather than the architecture anyway.  ;-}

> >   This is eventually described in section 5.5, but that's quite a ways
> >   down in the document.
> 
> There are usually structure issues with any document.  Each different
> reader may find that they would prefer that some part of the content of
> the document was provided earlier than another.  This is not always an
> option.

When attempting to read the document as someone without intimate
RBridge knowlege, I think the very *first* question that reader has is
how traditional bridging and the new RBridges "see" each other.  How
does interoperability with existing equipment work?

In every single presentation I've given on our OpenSolaris RBridges
project, that question has come up.  In fact, I just gave a short talk
at our internal quarterly engineering status review today, and guess
what the only question was?

> For example, if the interaction information you requested above were to 
> appear toward the beginning of the document, it would be necessary to
> either assume the reader understands elements of the architecture that
> are implicitly included in these statements, or provide the description 
> of these things earlier in the document.  Pretty soon, you may find all
> of the information gets cycled and the specific content you wanted to
> see earlier is now pretty much where it was orignally.

I don't believe that to be true, because I'm identifying a need to set
out some boundary conditions first: the reader should not expect to
see us discussing STP interoperability (there isn't any because the
STP 'domain' ends at the RBridge doorstep) or how RBridge links are
disabled by STP (they're not).

But if the document authors don't feel they can do that without
damaging the structure of the document, then that's fine.  I've
offered my comments, and that's all I set out to do.

> Would it be sufficient to provide a pointer to section 5.5 at some point
> toward the beginning of the document?  If so, where specifically would
> you think it should be put?

Having a pointer that says "interoperability between traditional
bridges using Spanning Tree and RBridges is preserved by the rules
described in section 5.5" somewhere near the top (perhaps before or
amid the "as an overview, however" part on page 5) would help.

> > -
> > 
> >   Section 2.2 page 11:
> > 
> >     The term "R-tree" is defined, but then never used again.
> 
> This was specifically agreed to in the course of terminology alignment
> several meetings (and versions) ago.  Radia and Silvano requested that
> the architecture document should include this definition.  However, I
> argued at the time that this is specific to a particular specification
> of protocol, and not a term generally applicable to the architecture.
> 
> Hence the term is defined, and not used.

It looks like flotsam in the architecture document.  I suggest
removing it.

> > -
> > 
> >   3.2.1 doesn't give enough detail about the nature of the unicast
> >   forwarding database.  There must be entries of at least these forms:
[...]
> The exact proposed additions are actually not quite complete/accurate
> since the ingress and forwarding operations are 1) distinct (since the
> ingress operation also includes encapsulation) and 2) discussed in 
> different sections (ingress information is discussed in section 3.2.3
> and an ingress RBridge would contain - at least logically - an ingress 
> forwarding database, a unicast forwarding database and, possibly, a
> multi-point forwarding database).
> 
> At one point, the architecture did contain information at the level of
> detail suggested in this comment.  However, this level of detail was
> found to be objectionable by a number of people in earlier versions.

In *no* place does the document describe the form or abstract
operation of these databases required for the forwarding functions.

That's important, and it is indeed architectural.  It's not an
implementation detail that can be deferred to a protocol
specification.  The database itself doesn't appear inside the
protocol.  It's a fundamental assumption of the mechanism used in
forwarding and it's necessary to understand it in order to understand
egress learning behavior.

(Honestly, given the amount of architectural information that's
present in the protocol specification, I'm not sure why I should argue
about this point -- collapsing the documents would be a better
solution -- but as long as we're trying to separate architectural
matters from protocol matters, we're not quite getting there.)

>        'The Unicast TRILL Forwarding Database contains data specific to 
>         RBridge forwarding for unicast traffic. The specific fields 
>         contained in this table are to be defined in RBridge protocol 
>         specifications. In the abstract, however, the table should 
>         contain forwarding direction and encapsulation associated with 
>         an RBridge encapsulated frame received - determined by the TRILL
> 
>         "shim" header destination and VLAN (if applicable).'  

That's exactly what I'm pointing out as insufficient in terms of
architecture.

> > -
> > 
> >   Section 3.2.2., on page 15, the term "Egress RBridge" is defined for
> >   the multi-destination case in part with this text:
[...]
> This comment is somewhat misleading.

I don't believe it is.

> Egress RBridge (as a role in a network) is defined in the terminology 
> section.
> 
> Immediately preceding this (and other) definition(s) is the following
> paragraph:
> 
>         'In discussing entries to be included in the Multi-destination 
>         TRILL Forwarding Database, the following entities are 
>         temporarily defined, or further qualified:'

Right.  That's exactly what I'm pointing out as difficult to
understand.  Using the same term with different definitions within a
single document is dangerous.

> This is an editorial choice, and should not produce confusion for most
> readers.

I guess I'm just not "most readers," then.

> Perhaps it would be potentially less confusing if the entire set of 
> "qualified" definitions were included in a NOTE in which they were
> also made to look significantly less like "definitions"?

Possibly, though I'm not sure how that would function.

The higher level issue that I'm pointing out is that you're using
English as though it were a programming language -- complete with
clear lexical scoping rules and unambiguous syntax.  Unfortunately,
written prose isn't like that, even in a specification, and
particularly in an IETF document.

The essence of a good RFC is clarity.  It's the ability to produce
interoperable implementations by multiple vendors and by multiple
readers who may be separated by time, distance, and native language.

I don't believe it's wise to sacrifice clarity for the sake of
precision or economy.

> >   I think the text should be shortened up considerably and clarified,
> >   because this point is effectively drowned out by too many words.
> >   (This comment applies to similarly affected sections, such as 5.2,
> >   which seems to be crawling with degenerates.  ;-})
> 
> Unfortunately, I agree with this comment completely and cannot take any
> action on it - at least not on the basis of a single comment from one
> reviewer.

I guess my time was well spent.  ;-}

> Also, as you undoubtedly know, "degenerate" is a precise mathematical 
> term meaning "a limiting case of a mathematical system that is more 

Of course.

> symmetrical or simpler in form than the general case."  My favorite
> example is a degenerate circle represented by the equation -

You might have noticed that the phrase "degenerate case" is used twice
in this section and appears to refer to two subtly different cases.

> >   The *important* part is whether any equipment that may form a
> >   non-RBridge L2 data path between RBridge ports must allow TRILL
> >   communication between those ports such that RBridges can safely
> >   elect or determine a single Designated RBridge.  It doesn't matter
> >   how that path is formed (802.1D is one possibility), just that it
> >   exists.
> 
> I won't argue whether or not this true, it is not quite the point.
> 
> The issue discussed is entirely about the need to be compatible with 
> bridge learning (defined for 802.1 bridges).  If - in fact - the issue
> was limited to links between RBridges, my answer might be different.
> 
> If we do not need to be consistent with bridge learning (in either a
> transit or ingress/egress case), a lot of things are different.  But
> the key difference - for this section - is that it is important for
> RBridges to provide forwarding that is consistent with the way that
> bridge learning works.  In the simplest approach - where we treat a
> set of (spanning tree) connected bridges as a single link between
> RBridges (or a single stub connected to a single RBridge), and have
> a single RBridge that provides egress/ingress to the RBridge campus
> - then the specifics of the topology and the way that bridge learning
> occurs would be unecessary.

I'll offer that injecting explicit end-station forwarding entries into
the TRILL database (one of the options that's discussed multiple times
in the text, along with all of its disadvantages) is *NOT* consistent
with traditional bridge learning, so it's apparent that strict
consistency with 802.1D or 802.1Q isn't the point, either.

> This may not be precisely clear to people in the IETF, generally.  It
> is probably not the case that everyone immediately realizes that the
> frames delivered to an ingress RBridge do not (usually) have the MAC 
> DA of that RBridge, nor that frames delivered from an egress RBridge 
> do not (usually) have the MAC SA of the egress RBridge.  Because these
> things are true, however, it is necessary for the RBridges to behave 
> in a way that is consistent with bridge learning.

It would be a bizarre bridge indeed that requires the end stations to
somehow "know" the local bridge MAC address in order to set the MAC DA
correctly, or that alters the MAC source address of the original frame
in transit.  I don't see how that could possibly work right.  What
you're talking about above seems to be the behavior of a router, not a
bridge.

I expect RBridges to be (first and foremost) layer two bridges.  I'm
surprised that we have to talk about consistency with 802.1D or 802.1Q
learning, as the learning that RBridges must do is actually somewhat
different (particularly the tunnel egress portion), and because the
learning that other bridges do (or don't do!) is completely invisible
to any RBridge implementation.

Even if we were somehow completely inconsistent with those other
documents, I fail to see how it would be an architectural issue for
RBridges, which _must_ be able to stand on their own.

> >   This latter bit is crucial.  It's what requires the encapsulator
> >   (which fills in a source nickname) and decapsulator (which will be
> >   the target of return traffic) to be the same node, or at least
> >   requires the encapsulator to fill in the decapsulator's nickname as
> >   the "sender."
> 
> This is - IMO - a level of detail below architecture.  In particular,
> the mechanistic details of RBridge learning very definitely do not 
> belong in an architectural specification.

I don't agree.  It's a crucial bit of the architecture.  It's how the
learning function operates, and it's one of the things that
distinguishes RBridges from regular bridges.

The document goes to the trouble of describing learning based on
source MAC address on the sender (encapsulator) RBridge, but then
leaves out how the destination (decapsulator) RBridge learns the
reverse path.  That seems like a hole to me.

> In addition, the proposed additional text is actually architecturally
> incorrect.
> 
> For one thing, the choice to learn on decapsulation is the current
> approach assumed as default in the protocol specification but is not
> an architectural requirement at all.

If you do data-based learning, rather than injecting the end station
addresses into the IS-IS data, then you *MUST* do as I outline above.
There's no other option other than flooding everything, and that's not
reasonably viable.

> >   This is duplication of the information already in 3.2.3.  This could
> >   be trimmed down.
> 
> I am unsure how this information is in any way related to the text in
> section 3.2.3 (Ingress TRILL Forwarding Database).

The two sections, one after the other, are almost word-for-word
identical.  This is a comment on the layout of the text.

> In addition, this is a single sentence statement that is very relevant 
> to the text in surrounding paragraphs.  The preceding paragraph talks 
> about the fact that the current assumption (of the WG, in the protocol 
> specification referenced) is that the ingress forwarding database is 
> populated by learning from (potentially flooded) data frames on egress.

Except, as you've pointed out before, that's a "detail" of the
protocol implementation ... right?

> >   The architecture document should describe how the system is intended
> >   to operate and what the parts should do.  I don't see a reason to
> >   insert loopholes that allow for unspecified future variations.  At
> >   best, it's a distraction, because we don't know how to make that
> >   work.  (And, in fact, I suspect it does _NOT_ work in any case,
> >   because it breaks learning.)
> 
> It's interesting that you did pick up on the learning problem, but did
> not see that this was the point of a lot of the text in section 4.1.
> Minimally, I will try to make at least that much clearer.
> 
> Again, there is no "architectural" reason to restrict implementations
> - or protocol specifications - to behavioral assumptions such as the
> ones you suggest.  This was not my choice, but direction from the WG.

The architectural reason to do so is that it allows the receiver (the
egress RBridge) to *assume* that the sender's nickname is the reverse
path for the source MAC address in the decapsulated packet.

If this assumption is broken, then there's no way to do this right, as
long as the architecture allows for data-driven learning.  The section
of text I'm commenting on is this:

        Note that an egress RBridge will - in most case - be the RBridge 
        determined to be the primary point of attachment for a 
        destination end station on the local link or VLAN accessed via 
        its egress interface(s). Exceptions to this might exist under 
        circumstances in which use of distinct RBridges for ingress and 

Note that it says "in most case" [sic].  It's allowing for egress
RBridge and ingress (PPOA) being different, and I don't think that's a
viable architecture.

> And - unlike the ATM suggestion you mention - this particular degree of
> "architectural freedom" has everything to do with Ethernet technologies 
> RBridges are expected to be compatible with.  As an example, consider
> the following scenario:
>                 _____
>     S-1 <------|     |------> RB-1
>     S-2 <------| H-1 |
>     S-3 <------|_____|------> RB-2
> 
> In this case, S-1, S-2 and S-3 are end stations, H-1 is a Hub, and 
> RB-1 and RB-2 are RBridges.  While I am not recommending it, there
> is no "architectural" reason to prohibit RB-1 from being a PPOA for
> S-1 and S-3, while RB-2 is the PPOA for S-2.

Agreed.  That works fine.  That's not the problem I'm pointing out.

If RB-2 is the PPOA for S-2, and encapsulates the packets for S-2, but
the RB-2 is unable or unwilling to be the decapsulation point, how
does it know to put RB-1's nickname into the TRILL header?

That's what happens if you allow a protocol implementation to split up
the encapsulation point from the decapsulation point: there has to be
some way for the encapsulator to present the right TRILL nickname as
the source such that the return packets will be sent to the
decapsulation point.  The architecture contains nothing that would
allow this to happen in any obvious way.  (Or, really, any reason to
bother supporting such a thing.)

In other words, I see this as just a needless complication.

(It's possible that you're trying to describe a transient condition
that may occur during re-election of a new DRB.  If so, then perhaps
it should be made clear that although this *could* happen, it's not
the expected long-term behavior of the system.)

> I do not deny that this is confusing.  Those WG members who read any
> of the first 4 or 5 versions (at least), would be able to point out 
> that I had tried to avoid this confusion by assuming that a DRB will
> be used.

My comment in this section wasn't actually about the DRB selection.
It was instead about split encapsulation/decapsulation by a single end
station.

> >   I'm surprised that section 5.4 doesn't discuss why IS-IS was chosen,
> >   or what special things need to be done with it in order to make it
> >   work here (such as setting a fixed "area" value).
> 
> There is no completely unarguable reason for making the choice to 
> use IS-IS.  Also, the basis for making the choice is irrelevant to
> the architecture specification.  The fact that the choice was made 
> is only included as a result of a process decision to discontinue
> efforts to make progress on another document that was actually the
> appropriate place to make such observations.

Just as the choice to use IS-IS is architectural, the high-level
changes that must be made to IS-IS in order to make it usable as the
chosen solution (i.e., how well it fits the fundamental requirements)
are *also* architectural issues.

If you don't want the fit-to-function of IS-IS to be architectural,
then I think the choice of the routing protocol needs to be ruled out
of scope for this document as well.  (No, I don't think that's a good
idea at all, but I don't see how the architectural choice of IS-IS as
a basis can be made off-hand without discussing the implications.)

> If you would care to propose specific text - and we can achieve a
> degree of WG consensus - as to why IS-IS was chosen, I would be 
> okay with adding it.
> 
> The reason I ask is that I am not certain that the real reasons
> why IS-IS was chosen are both appropriate for inclusion in, and 
> consistently likely to remain true over the life of, an RFC.

For one thing, it runs directly on the link layer, and can be
specified such that no user configuration is necessary to make it
work.  In contrast, the alternatives (such as OSPF) run on network
layer protocols that require explicit configuration of subnets and the
like.

> With respect to setting a 'fixed "area" value' people who've been
> to most of the meetings will probably recall that I asked about 
> this and was told that it was not the case.  If this has in fact
> changed, I was not told about it.

If that's not done, then how do we ever achieve our zero-configuration
goal?

This seems obvious to me, and it's something we've discussed several
times in the working group.  It's a point on which I believe we
already have substantial consensus.

> Can you provide a specific reference?  There is no instance of
> either the word "area" or the word "fixed" that has anything to
> do with this topic in the protocol specification.  The word "area"
> is mostly used in connection with the "options" portion of the
> TRILL header, and the word "fixed" is used with enablement status
> and the assignment of VLAN 1.

See draft-eastlake-trill-rbridge-isis-00, section 2.1, bullet item 3:

   3. TRILL uses a distinct, constant IS-IS Area Address that would
      never appear as a real Layer 3 IS-IS area address. This Area
      Address is the value zero. (See Section 4.1.)

> Also, is it really appropriate to include this level of detail in
> the architecture document?  This sounds like a protocol operation
> specification...

The use of a fixed area is architectural.  The exact area number and
the optional features that might be related to it are not.

> >   This also looks like material that's in the same category as the 5.2
> >   advice about separate ingress/egress.  It's possible that someone
> >   could define a "new" version of RBridges that either forwards STP
> >   messages (!) or has each RBridge acting as an STP node in a single
> >   network (!!), but neither of those is really the solution we're
> >   trying to describe.  It's not part of the architecture.
> 
> An architecture does not describe a solution.  This should be clear
> from the title, which is intended to indicate that this document
> describes the architecture that applies to a solution to the TRILL
> "problem."  The abstract further clarifies that the role of this 

I emphatically disagree with that position.

First of all, we already have an abstract problem statement.  It's
described in draft-ietf-trill-prob-02.

That's not something I believe this document needs to do.  Instead,
this document needs to describe the architecture of a solution to the
problem statement.  "Architecture," in this instance, means the
components, interactions, and behaviors that will be and *should be*
combined to produce the desired results.  The problem itself isn't
architecture, as far as I understand it.

That necessarily describes a solution, and I don't see how we can have
an architecture document that doesn't actually address a solution.  If
that's what you and the other wg participants really want, then please
leave my name off as a reviewer.  That's a dead end to me.

This sort of all-and-the-kitchen-sink approach, where we don't make
actual decisions in this working group, but instead allow for a range
of purported but never realized "options" is _exactly_ what will lead
to interoperability problems and a failure of the group to specify
something useful.

I fear a lack of specificity much more than I do "offending" one or
more working group participants who don't want to have a simple and
unambiguous document.  Pretending as though we'll design something
that will work utterly differently with regard to STP is, in my
opinion, a terrible mistake.  We're on better ground when we rule
_out_ useless possibilities than when we make unending allowances for
them.

It's always easier to add options and features in the future than it
is to rule out mistaken features that were added just for the sake of
flexibility.

> The fact that these terms are not defined (at least in section 2)
> is that there was no consensus in a terminology alignment effort to 
> include these terms.  In addition, it is (as you said) somewhat
> obvious what these terms mean (though I disagree that knowing much
> about RBridges is required; it is actually more important to know
> a little bit about STP).

I think the reader must actually understand *both*.

> Further, it seems somewhat pretentious to define terminology in the
> main architecture text that is only used in a tutorial subsection
> of the document.  Understading of this text is "nice-to-have" but
> not necessary.

Pretension or not, I don't see how defining the terms nowhere but
using them regardless is a solution to that particular problem.

> If you look into the "wiring-closet" problem, you will see that it
> is possible (with some potential solutions to this problem) to have
> STP race conditions, or oscillations, depending on exactly how the
> protocols interact.

I did look into the problem, but I don't see any such modes.

If TRILL starts up first, then we end up with separate routes.  If
that STP link comes up later, then we'll have a temporary loop
(mitigated by TRILL's hop count) until the two RBridge neighbors
discover each other, and establish a new single DRB.

In the other order, TRILL will immediately detect the path, and set up
a single DRB as expected.

In either case, the situation is then stable.  TRILL does *not* cause
STP to recalculate anything.  TRILL doesn't shut down links, which are
the only things that STP really cares about here.

There's no oscillation, because there's no path that allows for
feedback -- a necessary condition of oscillation.  There is
potentially a *transient* as the topology settles, but the system is
dynamically stable.

> Since the WG is apparently not interested in solving that problem
> - in spite of feedback from IEEE 802.1 that doing so is important
> - there is little reason to go into the details.  This is even more
> true, given the fact that section 5 is now a tutorial.

I think it's an interesting problem to solve, and worth mentioning,
but far from the threat that you seem to be describing.

In particular, network reconfiguration can by itself create such a
temporary loop without ever needing to invoke the "wiring closet
problem."  That's why the TRILL headers will have hop counts.  It's in
the nature of the beast when you start to deal with routing protocols.

I don't doubt that such things make 802.1 folks queasy.

> > Note that 
> >         scaling concerns may dictate otherwise, either in specific of 
> >                                                           ^^^^^^^^ ?
> >         RBridge protocol specification, or in deployment.  
> 
> I had noticed this one as well.  It either originally said, or was 
> meant to say, "... specific instances of ..."
> 
> I propose to remove "specific of", making the text read "... either
> in RBridge protocol specification, or in deployment."

OK.

> - with -
> 
>   "Entries contain an indication of the interface a broadcast, 
>    multicast or flooded frame is forwarded on for all applicable
>    {root RBridge, egress RBridge} pairs."

OK.  The rest is still in future tense, but that corrects the odd jump
in mood.

> I propose to fix the sentence structure by replacing the first 
> sentence with:
> 
>   "The Ingress TRILL Forwarding Database is used to determine 
>    how arriving traffic will be encapsulated for forwarding,
>    toward the egress RBridge, via the TRILL Campus."

OK.

-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4FJo7kP014416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 15 May 2008 12:50:08 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m4FJo6SX025428; Thu, 15 May 2008 14:50:06 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 15 May 2008 14:50:06 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 15 May 2008 14:45:44 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] long-awaited review comments ondraft-ietf-trill-rbridge-arch-05
Thread-Index: Aci2CmWGQZtKoDdZRfS/so8dEZ433wAWUuTg
References: <[e-mail]>
From: "Eric Gray" <[e-mail]>
To: "James Carlson" <[e-mail]>
X-OriginalArrivalTime: 15 May 2008 19:50:06.0365 (UTC) FILETIME=[DFBD9CD0:01C8B6C4]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m4FJo7kP014416
Cc: TRILL/RBridge Working Group <[e-mail]>
Subject: Re: [rbridge] long-awaited review comments ondraft-ietf-trill-rbridge-arch-05
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 15 May 2008 19:50:58 -0000
Status: RO
Content-Length: 34294

James,

	Thank you for the review and comments.  Sorry to have taken 
so long to get back to you on them, but I am currently in Eilat,
Israel for an Interim meeting of IEEE 802.1 Interworking.

	While I personally agree with most of your comments, I do
not believe that I am at liberty to make changes along the lines
of many of the ones you suggest, because the existing text is the 
result of WG direction or prior consensus/decisions.

	I explicitly invite WG members to read this review and to
indicate support (or lack thereof) for making the changes you've
suggested - in particular, those relating to the fact that the
current Architecture document does not assume use of designated
RBridges.  

	There were many reasons why I had initially made the "DRB
assumption" and you have pointed out several of them.  However,
I was given very explicit direction by the WG to remove the DRB
assumption, which ultimately made it necessary to describe all
of the specific complications involved in doing anything else.

	Also, I must wait for other reviewer comments before I can
start making changes in any case.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of James Carlson
> Sent: Wednesday, May 14, 2008 5:22 PM
> To: TRILL/RBridge Working Group
> Subject: [rbridge] long-awaited review comments 
> ondraft-ietf-trill-rbridge-arch-05
> 
> Here are my long-awaited review comments on the TRILL architecture
> document.  I intentionally read through it as someone who wanted an
> introduction to RBridges -- not someone who already knows the contents
> of the protocol draft, or who has spent too many hours staring at IEEE
> documents.  Many of the things I found were related to that.
> 
> In the notes below, individual notes are separated by a single "-" on
> a line.  The notes are indented two spaces.  The final section has
> minor editorial nits.
> 
> 
> -
> 
>   How do STP and RBridges interact?  We need to make it clear fairly
>   early on that neither regular bridges nor RBridges will forward STP
>   messages, but that regular bridges will forward TRILL IS-IS traffic
>   while RBridges will not.  Thus the expected model is that:
> 
>   - Directly connected STP-speakers see each other, and do tree
>     computation as usual.  Those separated by RBridges are effectively
>     on different networks.
> 
>   - RBridges don't see any of the STP-only speakers as part of the
>     topology, and thus consider any sequence of regular bridges to be
>     one hop.
> 
>   This is eventually described in section 5.5, but that's quite a ways
>   down in the document.

There are usually structure issues with any document.  Each different
reader may find that they would prefer that some part of the content of
the document was provided earlier than another.  This is not always an
option.

For example, if the interaction information you requested above were to 
appear toward the beginning of the document, it would be necessary to
either assume the reader understands elements of the architecture that
are implicitly included in these statements, or provide the description 
of these things earlier in the document.  Pretty soon, you may find all
of the information gets cycled and the specific content you wanted to
see earlier is now pretty much where it was orignally.

Moreover, some structure decisions are a result of previous comments,  
specific requests made against earlier versions or a compromise that
was acceptable to the majority of the commenters at some time.  In the
specific case of interactions between spanning tree and trill protocol,
there was some argument earlier (from Donald, I believe) that this ID
should not include any discussion of these interactons, accept possibly
in an appendix.  However, it was also argued that the interactions were
relevant to the architecture and that - because the architecture ID is
strictly informative in any case - there is no particular reason to put 
this kind of information in an appendix.

So it is part of a tutorial instead.

Would it be sufficient to provide a pointer to section 5.5 at some point
toward the beginning of the document?  If so, where specifically would
you think it should be put?

> 
> -
> 
>   Section 2.2 page 11:
> 
>     The term "R-tree" is defined, but then never used again.

This was specifically agreed to in the course of terminology alignment
several meetings (and versions) ago.  Radia and Silvano requested that
the architecture document should include this definition.  However, I
argued at the time that this is specific to a particular specification
of protocol, and not a term generally applicable to the architecture.

Hence the term is defined, and not used.

> 
> -
> 
>   3.2.1 doesn't give enough detail about the nature of the unicast
>   forwarding database.  There must be entries of at least these forms:
> 
>     { Destination MAC } -> { TRILL egress address }
> 
>     { TRILL address } -> { output link, MAC next hop }
> 
>   The first represents ingress behavior, and the second is TRILL
>   transit.  It's possible to compose together the first entry with the
>   second, avoiding a double look-up, so that the first entry looks
>   like this:
> 
>     { Destination MAC } -> { TRILL egress address, output 
> link, MAC next hop }
> 
>   But the second type of entry must exist for TRILL forwarding within
>   a campus.  It's also possible to optimize the case where the egress
>   is the local system and thus normal bridge forwarding is needed.
>   That case looks like:
> 
>     { Destination MAC } -> { output link }
> 
>   However, a system must always recognize its TRILL address and use
>   that to select an action of decapsulation followed by normal
>   bridging behavior, which means look-up based on the inner MAC header
>   to find a local entry of the above form.

The exact proposed additions are actually not quite complete/accurate
since the ingress and forwarding operations are 1) distinct (since the
ingress operation also includes encapsulation) and 2) discussed in 
different sections (ingress information is discussed in section 3.2.3
and an ingress RBridge would contain - at least logically - an ingress 
forwarding database, a unicast forwarding database and, possibly, a
multi-point forwarding database).

At one point, the architecture did contain information at the level of
detail suggested in this comment.  However, this level of detail was
found to be objectionable by a number of people in earlier versions.

Because of the fact that the protocol specification design team was -
at the time - in the process of evolving the details of the content of
the corresponding information base AND was also heavily represented in 
the pool of those people who were providing the strongest objections, 
one (or more) subsequent versions contained an explicit statement that
the information provided represented a logical model only and did not
constrain either protocol specifications or implementations.

This text - at least in part - remains in section 3.2 text immediately
preceding section 3.2.1.

At a later point - marked I believe by a change in the makeup of the 
protocol design team - even this qualified text was considered to be
objectionable and possibly incorrect.  Hence - by mutual consent of
all parties - all detailed text of the nature suggested in this comment
was removed and replaced by the following paragraph:

       'The Unicast TRILL Forwarding Database contains data specific to 
        RBridge forwarding for unicast traffic. The specific fields 
        contained in this table are to be defined in RBridge protocol 
        specifications. In the abstract, however, the table should 
        contain forwarding direction and encapsulation associated with 
        an RBridge encapsulated frame received - determined by the TRILL

        "shim" header destination and VLAN (if applicable).'  

> 
> -
> 
>   Section 3.2.2., on page 15, the term "Egress RBridge" is defined for
>   the multi-destination case in part with this text:
> 
>         o  Egress RBridge - an RBridge that is the tail end of a path 
>            corresponding to a specific Multi-destination TRILL 
>            Forwarding Database entry. All RBridges within a 
> TRILL Campus 
> 
>   I think this gets a bit confusing, because there are also "Egress
>   RBridges" in the unicast case, and using the same formally term for
>   two potentially different things seems like a mistake.  As
>   alternatives, I suggest:
> 
>   - Change "Egress RBridge" into a role that an RBridge plays in the
>     network, and define it in terms of the responsibilities of that
>     role outside of this section.  The section on multi-destination
>     traffic can then clarify how a node 'knows' it must play that
>     role.  (For unicast, it's easy.  The nickname in the destination
>     field is *your* nickname.)
> 
>   - Create a new, distinct term that encompasses the specific behavior
>     and role of a multi-destination egress.

This comment is somewhat misleading.

Egress RBridge (as a role in a network) is defined in the terminology 
section.

Immediately preceding this (and other) definition(s) is the following
paragraph:

        'In discussing entries to be included in the Multi-destination 
        TRILL Forwarding Database, the following entities are 
        temporarily defined, or further qualified:'

This is an editorial choice, and should not produce confusion for most
readers.  In this I may be mistaken, but - in the context of where it 
is used - my 'editorial' opinion was that inventing a new term to
describe the role of a multi-destination egress RBridge, as an entry 
in a database (as opposed to an entity in the network), would be more 
confusing, rather than less. 

The principal reason for "qualifying" these definitions is to make it
clearer that (from an architectural perspective), these are still the
same entities, but they play a different role in this database than 
they do in the role of forwarding frames.  

Perhaps it would be potentially less confusing if the entire set of 
"qualified" definitions were included in a NOTE in which they were
also made to look significantly less like "definitions"?

> 
> -
> 
>   Section 3.2.2., on page 16, it says:
> 
>         Multi-destination TRILL Forwarding Database entries may also 
>         include Multicast-Group Address specific information relative 
>         to each egress RBridge that is a member of a given well-known 
>         multicast group, to allow scoping of multicast forwarding by 
>         multicast group. 
> 
>   Why are the words "well-known" used here?  The point of well-known
>   group addresses is that the handling is already defined --
>   membership isn't really needed.  Shouldn't this say "of a given
>   multicast group"?  (If not, then what exactly is the significance of
>   limiting these entries to *just* those for well-known group
>   addresses?)

I will happily remove the phrase "well-known."

> 
> - 
> 
>   Section 4.1, page 17:
> 
>         At an architectural level, it is sufficient to note that
>         every end station attached to a TRILL Campus should have a
>         primary point of attachment to the TRILL Campus, as might
>         be defined (for example) by a Designated RBridge.  
>         Furthermore, if it is [...]
> 
>   I read that several times, and then had to refer to other sections
>   before the actual meaning of this text became clear.  "Primary point
>   of attachment" doesn't mean to me what it must have meant to the
>   author.  When I first read it, I thought it was a wire or subnet.
>   Then I started thinking in terms of DLPI PPAs.  Then I got _really_
>   confused.  ;-}
> 
>   The apparent meaning of this text is that, for each end station on
>   each VLAN, there must be at most one RBridge that acts as the TRILL
>   encapsulation/decapsulation gateway when talking to other nodes in
>   the rest of the campus.  And one way to do that is to have a
>   per-VLAN Designated RBridge.
> 
>   There's no actual "attachment" of any sort.
> 
>   Unfortunately, the text takes several unclear paragraphs to say
>   that.  It seems that part of the reason it's so unclear is that the
>   document is trying to drive far out of its way in order to be "fair"
>   to other possible proposals other than having a Designated RBridge.
>   Perhaps we could even do per-end-station elections.
> 
>   I think the text should be shortened up considerably and clarified,
>   because this point is effectively drowned out by too many words.
>   (This comment applies to similarly affected sections, such as 5.2,
>   which seems to be crawling with degenerates.  ;-})

Unfortunately, I agree with this comment completely and cannot take any
action on it - at least not on the basis of a single comment from one
reviewer.

The current wording is the result of extensive comments on the notion
that the architecture draft has no particular reason to limit protocol
specifications to use of a designated RBridge.  However, the complexity
associated with trying to be fair to other potential approaches means
spending some time and effort in describing the consequences and issues 
associated with particular choices (especially the choice not to allow
us to assume use of a DRB in the architecture).

The term "primary point of attachment" was my choice, and I was not 
very happy with it either.  In any specific case, an RBridge that is
the designated ingress/egress for any particular set of end-stations
is the RBridge to which they are "attached" (in the exact same sense
that they might be "attached" to a bridge - for learning purposes).

I discussed this usage in detail in a "status" presentation a few WG
meetings ago (I could look up exactly which one, but is it really 
worth it?).  I asked for suggestions for another term at that time
and received none.

Personally, I would have preferred to use "designated RBridge" - but
I suspected that would not have been accepted by those who argued to
remove the "DRB assumption."

I am happy to use any reasonable term instead, and provide a detailed
definition as well.  It is - IMO - not the case that there can be "at
most one" DRB-equivalent for any end-station, but explaining that in
a precise definition is bound to be even more confusing.  As sages
say, be careful what you ask for.

Also, as you undoubtedly know, "degenerate" is a precise mathematical 
term meaning "a limiting case of a mathematical system that is more 
symmetrical or simpler in form than the general case."  My favorite
example is a degenerate circle represented by the equation -

     2    2
    X  + Y  = 0

- which obviously describes a single point located at the origin of a 
cartesian coordinate system in X and Y.

I prefer not to replace either of the two uses of this word, as to
do so would be to go from a term that has at least one definition 
that is precisely correct, to another term that does not.

> 
> -
> 
>   In general, I think section 4.1 worries itself too much about the
>   definitions of bridges (802 references and such) and far too little
>   about the architectural implications for RBridges.
> 
>   We (those creating TRILL-based RBridges) don't care about bridges.
>   We should not have to.  We shouldn't have to specify that bridges
>   need to "be consistent" with 802.1D or 802.1Q -- they either are or
>   aren't, and that's the problem of the bridge vendor.
> 
>   I note that the document didn't spend any time talking about the
>   standards for repeaters.  Those have about as much bearing to the
>   matter here.
> 
>   The *important* part is whether any equipment that may form a
>   non-RBridge L2 data path between RBridge ports must allow TRILL
>   communication between those ports such that RBridges can safely
>   elect or determine a single Designated RBridge.  It doesn't matter
>   how that path is formed (802.1D is one possibility), just that it
>   exists.

I won't argue whether or not this true, it is not quite the point.

The issue discussed is entirely about the need to be compatible with 
bridge learning (defined for 802.1 bridges).  If - in fact - the issue
was limited to links between RBridges, my answer might be different.

If we do not need to be consistent with bridge learning (in either a
transit or ingress/egress case), a lot of things are different.  But
the key difference - for this section - is that it is important for
RBridges to provide forwarding that is consistent with the way that
bridge learning works.  In the simplest approach - where we treat a
set of (spanning tree) connected bridges as a single link between
RBridges (or a single stub connected to a single RBridge), and have
a single RBridge that provides egress/ingress to the RBridge campus
- then the specifics of the topology and the way that bridge learning
occurs would be unecessary.

However, architecturally, there is no reason to assume that this must
be the case.  For example (not as a recommendation), it is possible
for RBridges to be aware of both how bridge learning occurs and the
details of the bridge topology in such a way that load-sharing could
be done without impact on local bridge forwarding.

This may not be precisely clear to people in the IETF, generally.  It
is probably not the case that everyone immediately realizes that the
frames delivered to an ingress RBridge do not (usually) have the MAC 
DA of that RBridge, nor that frames delivered from an egress RBridge 
do not (usually) have the MAC SA of the egress RBridge.  Because these
things are true, however, it is necessary for the RBridges to behave 
in a way that is consistent with bridge learning.

Use of a designated RBridge makes this relatively trivial, but is -
as discussed previously - not a valid architectural assumption in the
opinion of several vocal members of the WG.

> 
> -
> 
>   Section 5.2, page 21:
> 
>         As described previously, RBridge learning is similar 
> to typical
>         bridge learning - i.e. - all RBridges listen 
> promiscuously to L2
>         Frames on each local LAN and acquire end station location
>         information associated with source MAC addresses in L2 frames
>         they observe.
> 
>   All egress RBridges should also learn from the L2 frames that they
>   decapsulate.  The two cases are distinct and important parts of
>   learning:
> 
>   - The ingress learns on which local port the end station exists,
>     just like any ordinary bridge would do.
> 
>   - The egress learns which nickname is the remote encapsulator (and
>     thus per section 4.1, decapsulator) for that end station.  This
>     part is unlike an ordinary bridge.
> 
>   This latter bit is crucial.  It's what requires the encapsulator
>   (which fills in a source nickname) and decapsulator (which will be
>   the target of return traffic) to be the same node, or at least
>   requires the encapsulator to fill in the decapsulator's nickname as
>   the "sender."

This is - IMO - a level of detail below architecture.  In particular,
the mechanistic details of RBridge learning very definitely do not 
belong in an architectural specification.

In addition, the proposed additional text is actually architecturally
incorrect.

For one thing, the choice to learn on decapsulation is the current
approach assumed as default in the protocol specification but is not
an architectural requirement at all.

> 
> -
> 
>   Section 5.2, page 22:
> 
>         The trade-off is between the complexity associated 
> with flooding 
>         data verses the complexity associated with flooding 
> reachability 
>         information.   
> 
>   This is duplication of the information already in 3.2.3.  This could
>   be trimmed down.

I am unsure how this information is in any way related to the text in
section 3.2.3 (Ingress TRILL Forwarding Database).

Also, note the text at the beginning of section 5 where the very first
sentence says:

   "This section is intended primarily to serve as a tutorial for 
    RBridge operations."

This was the result of a specific request that the architecture draft
should include such a tutorial.  

As such, it may contain text that is redundant.

In addition, this is a single sentence statement that is very relevant 
to the text in surrounding paragraphs.  The preceding paragraph talks 
about the fact that the current assumption (of the WG, in the protocol 
specification referenced) is that the ingress forwarding database is 
populated by learning from (potentially flooded) data frames on egress.

The immediately subsequent paragraph mentions at least one application 
in which this could be a poor choice (as an engineering trade off).  
The single sentence paragraph to which you refer simply describes the 
specific trade-off that applies to the decision.

It is both appropriate and necessary to the flow of the text to include
this statement at this point.

> 
> -
> 
>   Section 5.2, page 23:
> 
>         Note that an egress RBridge will - in most case - be 
> the RBridge 
>         determined to be the primary point of attachment for a 
>         destination end station on the local link or VLAN 
> accessed via 
>         its egress interface(s). Exceptions to this might exist under 
>         circumstances in which use of distinct RBridges for 
> ingress and 
> 
>   I think this digression should just be removed.  Not only is it in
>   conflict with the intent of section 4.1, but (like the whole "point
>   of attachment" thing) it's a point of unnecessary confusion.
> 
>   If it becomes feasible for some RBridge implementation strategy to
>   allow for distinct ingress/egress nodes in some cases, then I think
>   it's that other document's problem to describe how the deviation
>   that document describes is consistent with the overall story,
>   including (particularly) the egress node's learning capability.
> 
>   By this same token, any implementation could be arbitrarily strange
>   in areas not specified by the architectural document.  For instance,
>   someone could implement all of this with ATM and map nicknames into
>   VCIs.  It's not really possible (or even useful) to describe all the
>   ways one could go strange.
> 
>   The architecture document should describe how the system is intended
>   to operate and what the parts should do.  I don't see a reason to
>   insert loopholes that allow for unspecified future variations.  At
>   best, it's a distraction, because we don't know how to make that
>   work.  (And, in fact, I suspect it does _NOT_ work in any case,
>   because it breaks learning.)

It's interesting that you did pick up on the learning problem, but did
not see that this was the point of a lot of the text in section 4.1.
Minimally, I will try to make at least that much clearer.

Again, there is no "architectural" reason to restrict implementations
- or protocol specifications - to behavioral assumptions such as the
ones you suggest.  This was not my choice, but direction from the WG.

Unhappily, this particular direction from the working group is at least
technically correct.  As I admitted at the time, this was an effort on
my part to avoid having to describe the complexity involved in making 
any other assumptions.

And - unlike the ATM suggestion you mention - this particular degree of
"architectural freedom" has everything to do with Ethernet technologies 
RBridges are expected to be compatible with.  As an example, consider
the following scenario:
                _____
    S-1 <------|     |------> RB-1
    S-2 <------| H-1 |
    S-3 <------|_____|------> RB-2

In this case, S-1, S-2 and S-3 are end stations, H-1 is a Hub, and 
RB-1 and RB-2 are RBridges.  While I am not recommending it, there
is no "architectural" reason to prohibit RB-1 from being a PPOA for
S-1 and S-3, while RB-2 is the PPOA for S-2.  There is in this case
a strong likelihood that no learning is involved that would become
confused.

How this might be supported is out of scope for architecture, and I
do not include - or explicitly hint at - any such example, nor do I
say that this scenario (or any like it) needs to be supported by 
a specific protocol solution.  I do state that there are things a
protocol specification must define in the event that it does decide
to support anything as complicated as this.

I do not deny that this is confusing.  Those WG members who read any
of the first 4 or 5 versions (at least), would be able to point out 
that I had tried to avoid this confusion by assuming that a DRB will
be used.

Since WG members argued that the architectural specification is not 
allowed to make such an assumption, the architecture document now 
needs to provide all of the nicely complicated descriptions of the 
consequences of not assuming that a DRB is going to be used.

Dinesh Dutt and Joe Touch were among the people who argued that the
"DRB assumption" should be removed.  At least one of the WG chairs
also felt that it probably should be removed.  Nobody, other than 
myself, had any objection to this argument (though I did mention 
that it would significantly complicate the architecture and I also 
tried to socialize the complexity involved with at least a few of 
the active WG participants) at the time.

> 
> -
> 
>   Sections 5.3.2-2 and 5.3.2-3, pages 28 and 29: there's a lot of
>   duplication here.
> 
> -
> 
>   I'm surprised that section 5.4 doesn't discuss why IS-IS was chosen,
>   or what special things need to be done with it in order to make it
>   work here (such as setting a fixed "area" value).

There is no completely unarguable reason for making the choice to 
use IS-IS.  Also, the basis for making the choice is irrelevant to
the architecture specification.  The fact that the choice was made 
is only included as a result of a process decision to discontinue
efforts to make progress on another document that was actually the
appropriate place to make such observations.

If you would care to propose specific text - and we can achieve a
degree of WG consensus - as to why IS-IS was chosen, I would be 
okay with adding it.

The reason I ask is that I am not certain that the real reasons
why IS-IS was chosen are both appropriate for inclusion in, and 
consistently likely to remain true over the life of, an RFC.

With respect to setting a 'fixed "area" value' people who've been
to most of the meetings will probably recall that I asked about 
this and was told that it was not the case.  If this has in fact
changed, I was not told about it.

Can you provide a specific reference?  There is no instance of
either the word "area" or the word "fixed" that has anything to
do with this topic in the protocol specification.  The word "area"
is mostly used in connection with the "options" portion of the
TRILL header, and the word "fixed" is used with enablement status
and the assignment of VLAN 1.

I also checked current IS-IS WG drafts, and did not see anything
obviously likely to include this.

Also, is it really appropriate to include this level of detail in
the architecture document?  This sounds like a protocol operation
specification...

> 
> -
> 
>   Section 5.5, page 30:
> 
>         o  Transparent Participation (Transparent-STP) 
>         o  Active Participation (Participate-STP) 
>         o  Blocking Participation (Block-STP) 
> 
>   I don't see that these terms are defined anywhere.  It seems
>   somewhat obvious what they mean -- *if* you already understand
>   RBridges -- but they're likely to confuse.
> 
>   This also looks like material that's in the same category as the 5.2
>   advice about separate ingress/egress.  It's possible that someone
>   could define a "new" version of RBridges that either forwards STP
>   messages (!) or has each RBridge acting as an STP node in a single
>   network (!!), but neither of those is really the solution we're
>   trying to describe.  It's not part of the architecture.

An architecture does not describe a solution.  This should be clear
from the title, which is intended to indicate that this document
describes the architecture that applies to a solution to the TRILL
"problem."  The abstract further clarifies that the role of this 
document is to propose "an architecture for RBridge systems as a 
solution to the TRILL problem" and goes on to say that protocol and
mechanisms (which would be part of an actual solution) are specified
elsewhere.

Perhaps I should be more explicit in stating that actual solutions
(including protocol and mechanisms) are specified elsewhere?

The fact that a solution could be defined that includes either of
the two (currently unchosen) alternatives is a perfectly valid
reason why they are mentioned in an architecture document.

Furthermore, the fact that these terms exist - and are not included
in the Terminology section - is the result of a long-term debate 
about the possible alternatives, as well as the fact that it still
might be necessary to specify one of them to resolve one or more 
specific issues with RBridge solution(s) specification(s).  See,
for instance, the wiring closet problem in section 5.5.1.

The fact that these terms are not defined (at least in section 2)
is that there was no consensus in a terminology alignment effort to 
include these terms.  In addition, it is (as you said) somewhat
obvious what these terms mean (though I disagree that knowing much
about RBridges is required; it is actually more important to know
a little bit about STP).

Further, it seems somewhat pretentious to define terminology in the
main architecture text that is only used in a tutorial subsection
of the document.  Understading of this text is "nice-to-have" but
not necessary.

> 
> -
> 
>   Section 5.5.1, page 32:
> 
>         Finally, note that there is a chicken-and-egg problem 
>         associated with RBridge participation in STP where 
>         RBridges may themselves be connected by spanning trees. 
> 
>   I'm not positive that this problem actually occurs.  If an RBridge
>   runs STP, the port will be blocked until STP finishes its usual set
>   of listening/learning/forwarding timers, so the RBridge network
>   won't see or use the link either.
> 
>   STP is the egg, and TRILL is the chicken.  I think.

Some negativity is only natural.  I fogive you.  :-)

If you look into the "wiring-closet" problem, you will see that it
is possible (with some potential solutions to this problem) to have
STP race conditions, or oscillations, depending on exactly how the
protocols interact.

Since the WG is apparently not interested in solving that problem
- in spite of feedback from IEEE 802.1 that doing so is important
- there is little reason to go into the details.  This is even more
true, given the fact that section 5 is now a tutorial.

> 
> - Editorial nits
> 
>   Section 1, page 4:
> 
>         The principal objectives of this architecture is to 
> provide an 
>                                                       ^^ are
> 
>         allow some level of optimization support to be provided in 
>         compliant implementations, in as many case as possible. 
>                                               ^^^^ cases

Thanks, these will be fixed.

> 
>   Section 3.2.1, page 14:
> 
>         for each VLAN, if this is supported by configuration. 
> Note that 
>         scaling concerns may dictate otherwise, either in specific of 
>                                                           ^^^^^^^^ ?
>         RBridge protocol specification, or in deployment.  

I had noticed this one as well.  It either originally said, or was 
meant to say, "... specific instances of ..."

I propose to remove "specific of", making the text read "... either
in RBridge protocol specification, or in deployment."

> The Unicast 
> 
>   Section 3.2.2., page 15:
> 
>         o  Zero or more entries grouped for each root RBridge 
> - keyed by 
>            some root RBridge identifier - used to determine [...]
>            of broadcast, multicast, and flooded frames originally 
>            RBridge encapsulated by that ingress within the [...] 
>            ^^^^^^^ TRILL

Yes, I will correct this.

> 
>         Each entry would contain an indication of which 
> single interface 
>         a broadcast, multicast or flooded frame would be 
> forwarded for 
> 
> 	(The text suddenly jumps into subjunctive mood rather than
> 	staying in future tense.  It's unclear to me why this is so,
> 	but it looks like an error in the text.)

Not sure I agree that there is an issue with tense here, but I
probably need to re-formulate this text to make it readable.

I propose to replace the text -

  "Each entry would contain an indication of which single interface 
   a broadcast, multicast or flooded frame would be forwarded for 
   each (root RBridge, egress RBridge) pair."

- with -

  "Entries contain an indication of the interface a broadcast, 
   multicast or flooded frame is forwarded on for all applicable
   {root RBridge, egress RBridge} pairs."

> 
>   Section 3.2.3, page 16:
> 
>         The Ingress TRILL Forwarding Database determines how arriving 
>         traffic will be encapsulated, for forwarding toward 
> the egress 
>                                     ^
>         RBridge, via the TRILL Campus. It becomes configured 
> in much the 
>                ^

I propose to fix the sentence structure by replacing the first 
sentence with:

  "The Ingress TRILL Forwarding Database is used to determine 
   how arriving traffic will be encapsulated for forwarding,
   toward the egress RBridge, via the TRILL Campus."

> 
>   Section 4.6, page 20:
> 
>         It is the combination of the local MAC desitnation 
>                                                ^^^^^^^^^^^

Thanks, I will fix the spelling of destination.
 
> 
> 
> -- 
> James Carlson, Solaris Networking              
> <[e-mail]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4ELTJGc029645 for <[e-mail]>; Wed, 14 May 2008 14:29:20 -0700 (PDT)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4ELTJVi020381 for <[e-mail]>; Wed, 14 May 2008 21:29:19 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4ELTJWM042846 for <[e-mail]>; Wed, 14 May 2008 17:29:19 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m4ELLk4S021390 for <[e-mail]>; Wed, 14 May 2008 17:21:49 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m4ELLYq6021383; Wed, 14 May 2008 17:21:34 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 14 May 2008 17:21:34 -0400
From: James Carlson <[e-mail]>
To: TRILL/RBridge Working Group <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] long-awaited review comments on draft-ietf-trill-rbridge-arch-05
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2008 21:30:46 -0000
Status: RO
Content-Length: 13264

Here are my long-awaited review comments on the TRILL architecture
document.  I intentionally read through it as someone who wanted an
introduction to RBridges -- not someone who already knows the contents
of the protocol draft, or who has spent too many hours staring at IEEE
documents.  Many of the things I found were related to that.

In the notes below, individual notes are separated by a single "-" on
a line.  The notes are indented two spaces.  The final section has
minor editorial nits.


-

  How do STP and RBridges interact?  We need to make it clear fairly
  early on that neither regular bridges nor RBridges will forward STP
  messages, but that regular bridges will forward TRILL IS-IS traffic
  while RBridges will not.  Thus the expected model is that:

  - Directly connected STP-speakers see each other, and do tree
    computation as usual.  Those separated by RBridges are effectively
    on different networks.

  - RBridges don't see any of the STP-only speakers as part of the
    topology, and thus consider any sequence of regular bridges to be
    one hop.

  This is eventually described in section 5.5, but that's quite a ways
  down in the document.

-

  Section 2.2 page 11:

    The term "R-tree" is defined, but then never used again.

-

  3.2.1 doesn't give enough detail about the nature of the unicast
  forwarding database.  There must be entries of at least these forms:

    { Destination MAC } -> { TRILL egress address }

    { TRILL address } -> { output link, MAC next hop }

  The first represents ingress behavior, and the second is TRILL
  transit.  It's possible to compose together the first entry with the
  second, avoiding a double look-up, so that the first entry looks
  like this:

    { Destination MAC } -> { TRILL egress address, output link, MAC next hop }

  But the second type of entry must exist for TRILL forwarding within
  a campus.  It's also possible to optimize the case where the egress
  is the local system and thus normal bridge forwarding is needed.
  That case looks like:

    { Destination MAC } -> { output link }

  However, a system must always recognize its TRILL address and use
  that to select an action of decapsulation followed by normal
  bridging behavior, which means look-up based on the inner MAC header
  to find a local entry of the above form.

-

  Section 3.2.2., on page 15, the term "Egress RBridge" is defined for
  the multi-destination case in part with this text:

        o  Egress RBridge - an RBridge that is the tail end of a path 
           corresponding to a specific Multi-destination TRILL 
           Forwarding Database entry. All RBridges within a TRILL Campus 

  I think this gets a bit confusing, because there are also "Egress
  RBridges" in the unicast case, and using the same formally term for
  two potentially different things seems like a mistake.  As
  alternatives, I suggest:

  - Change "Egress RBridge" into a role that an RBridge plays in the
    network, and define it in terms of the responsibilities of that
    role outside of this section.  The section on multi-destination
    traffic can then clarify how a node 'knows' it must play that
    role.  (For unicast, it's easy.  The nickname in the destination
    field is *your* nickname.)

  - Create a new, distinct term that encompasses the specific behavior
    and role of a multi-destination egress.

-

  Section 3.2.2., on page 16, it says:

        Multi-destination TRILL Forwarding Database entries may also 
        include Multicast-Group Address specific information relative to 
        each egress RBridge that is a member of a given well-known 
        multicast group, to allow scoping of multicast forwarding by 
        multicast group. 

  Why are the words "well-known" used here?  The point of well-known
  group addresses is that the handling is already defined --
  membership isn't really needed.  Shouldn't this say "of a given
  multicast group"?  (If not, then what exactly is the significance of
  limiting these entries to *just* those for well-known group
  addresses?)

- 

  Section 4.1, page 17:

        At an architectural level, it is sufficient to note that every 
        end station attached to a TRILL Campus should have a primary 
        point of attachment to the TRILL Campus, as might be defined 
        (for example) by a Designated RBridge.  Furthermore, if it is 

  I read that several times, and then had to refer to other sections
  before the actual meaning of this text became clear.  "Primary point
  of attachment" doesn't mean to me what it must have meant to the
  author.  When I first read it, I thought it was a wire or subnet.
  Then I started thinking in terms of DLPI PPAs.  Then I got _really_
  confused.  ;-}

  The apparent meaning of this text is that, for each end station on
  each VLAN, there must be at most one RBridge that acts as the TRILL
  encapsulation/decapsulation gateway when talking to other nodes in
  the rest of the campus.  And one way to do that is to have a
  per-VLAN Designated RBridge.

  There's no actual "attachment" of any sort.

  Unfortunately, the text takes several unclear paragraphs to say
  that.  It seems that part of the reason it's so unclear is that the
  document is trying to drive far out of its way in order to be "fair"
  to other possible proposals other than having a Designated RBridge.
  Perhaps we could even do per-end-station elections.

  I think the text should be shortened up considerably and clarified,
  because this point is effectively drowned out by too many words.
  (This comment applies to similarly affected sections, such as 5.2,
  which seems to be crawling with degenerates.  ;-})

-

  In general, I think section 4.1 worries itself too much about the
  definitions of bridges (802 references and such) and far too little
  about the architectural implications for RBridges.

  We (those creating TRILL-based RBridges) don't care about bridges.
  We should not have to.  We shouldn't have to specify that bridges
  need to "be consistent" with 802.1D or 802.1Q -- they either are or
  aren't, and that's the problem of the bridge vendor.

  I note that the document didn't spend any time talking about the
  standards for repeaters.  Those have about as much bearing to the
  matter here.

  The *important* part is whether any equipment that may form a
  non-RBridge L2 data path between RBridge ports must allow TRILL
  communication between those ports such that RBridges can safely
  elect or determine a single Designated RBridge.  It doesn't matter
  how that path is formed (802.1D is one possibility), just that it
  exists.

-

  Section 5.2, page 21:

        As described previously, RBridge learning is similar to typical
        bridge learning - i.e. - all RBridges listen promiscuously to L2
        Frames on each local LAN and acquire end station location
        information associated with source MAC addresses in L2 frames
        they observe.

  All egress RBridges should also learn from the L2 frames that they
  decapsulate.  The two cases are distinct and important parts of
  learning:

  - The ingress learns on which local port the end station exists,
    just like any ordinary bridge would do.

  - The egress learns which nickname is the remote encapsulator (and
    thus per section 4.1, decapsulator) for that end station.  This
    part is unlike an ordinary bridge.

  This latter bit is crucial.  It's what requires the encapsulator
  (which fills in a source nickname) and decapsulator (which will be
  the target of return traffic) to be the same node, or at least
  requires the encapsulator to fill in the decapsulator's nickname as
  the "sender."

-

  Section 5.2, page 22:

        The trade-off is between the complexity associated with flooding 
        data verses the complexity associated with flooding reachability 
        information.   

  This is duplication of the information already in 3.2.3.  This could
  be trimmed down.

-

  Section 5.2, page 23:

        Note that an egress RBridge will - in most case - be the RBridge 
        determined to be the primary point of attachment for a 
        destination end station on the local link or VLAN accessed via 
        its egress interface(s). Exceptions to this might exist under 
        circumstances in which use of distinct RBridges for ingress and 

  I think this digression should just be removed.  Not only is it in
  conflict with the intent of section 4.1, but (like the whole "point
  of attachment" thing) it's a point of unnecessary confusion.

  If it becomes feasible for some RBridge implementation strategy to
  allow for distinct ingress/egress nodes in some cases, then I think
  it's that other document's problem to describe how the deviation
  that document describes is consistent with the overall story,
  including (particularly) the egress node's learning capability.

  By this same token, any implementation could be arbitrarily strange
  in areas not specified by the architectural document.  For instance,
  someone could implement all of this with ATM and map nicknames into
  VCIs.  It's not really possible (or even useful) to describe all the
  ways one could go strange.

  The architecture document should describe how the system is intended
  to operate and what the parts should do.  I don't see a reason to
  insert loopholes that allow for unspecified future variations.  At
  best, it's a distraction, because we don't know how to make that
  work.  (And, in fact, I suspect it does _NOT_ work in any case,
  because it breaks learning.)

-

  Sections 5.3.2-2 and 5.3.2-3, pages 28 and 29: there's a lot of
  duplication here.

-

  I'm surprised that section 5.4 doesn't discuss why IS-IS was chosen,
  or what special things need to be done with it in order to make it
  work here (such as setting a fixed "area" value).

-

  Section 5.5, page 30:

        o  Transparent Participation (Transparent-STP) 
        o  Active Participation (Participate-STP) 
        o  Blocking Participation (Block-STP) 

  I don't see that these terms are defined anywhere.  It seems
  somewhat obvious what they mean -- *if* you already understand
  RBridges -- but they're likely to confuse.

  This also looks like material that's in the same category as the 5.2
  advice about separate ingress/egress.  It's possible that someone
  could define a "new" version of RBridges that either forwards STP
  messages (!) or has each RBridge acting as an STP node in a single
  network (!!), but neither of those is really the solution we're
  trying to describe.  It's not part of the architecture.

-

  Section 5.5.1, page 32:

        Finally, note that there is a chicken-and-egg problem associated 
        with RBridge participation in STP where RBridges may themselves 
        be connected by spanning trees. 

  I'm not positive that this problem actually occurs.  If an RBridge
  runs STP, the port will be blocked until STP finishes its usual set
  of listening/learning/forwarding timers, so the RBridge network
  won't see or use the link either.

  STP is the egg, and TRILL is the chicken.  I think.

- Editorial nits

  Section 1, page 4:

        The principal objectives of this architecture is to provide an 
                                                      ^^ are

        allow some level of optimization support to be provided in 
        compliant implementations, in as many case as possible. 
                                              ^^^^ cases

  Section 3.2.1, page 14:

        for each VLAN, if this is supported by configuration. Note that 
        scaling concerns may dictate otherwise, either in specific of 
                                                          ^^^^^^^^ ?
        RBridge protocol specification, or in deployment.  The Unicast 

  Section 3.2.2., page 15:

        o  Zero or more entries grouped for each root RBridge - keyed by 
           some root RBridge identifier - used to determine forwarding 
           of broadcast, multicast, and flooded frames originally 
           RBridge encapsulated by that ingress within the TRILL Campus. 
           ^^^^^^^ TRILL

        Each entry would contain an indication of which single interface 
        a broadcast, multicast or flooded frame would be forwarded for 

	(The text suddenly jumps into subjunctive mood rather than
	staying in future tense.  It's unclear to me why this is so,
	but it looks like an error in the text.)

  Section 3.2.3, page 16:

        The Ingress TRILL Forwarding Database determines how arriving 
        traffic will be encapsulated, for forwarding toward the egress 
                                    ^
        RBridge, via the TRILL Campus. It becomes configured in much the 
               ^

  Section 4.6, page 20:

        It is the combination of the local MAC desitnation (which is for 
                                               ^^^^^^^^^^^
        a locally attached RBridge) and the TRILL encapsulation that 


-- 
James Carlson, Solaris Networking              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m4DDjimB012423 for <[e-mail]>; Tue, 13 May 2008 06:45:45 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-153.messagelabs.com!1210686342!10141741!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 12681 invoked from network); 13 May 2008 13:45:43 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-12.tower-153.messagelabs.com with SMTP; 13 May 2008 13:45:43 -0000
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m4DDjeWO010279 for <[e-mail]>; Tue, 13 May 2008 06:45:42 -0700 (MST)
Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m4DDjdCp001311 for <[e-mail]>; Tue, 13 May 2008 08:45:40 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m4DDjcC7001295 for <[e-mail]>; Tue, 13 May 2008 08:45:38 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B4FF.A03CDB37"
Date: Tue, 13 May 2008 09:45:34 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Rbridge Protocol draft questions
thread-index: Aci0FhMUhwvJH9TuRoSxiTbIQndkFAAl6/tw
References: <[e-mail]>
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "David Melman" <[e-mail]>
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Rbridge Protocol draft questions
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2008 13:46:45 -0000
Status: RO
Content-Length: 11982

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8B4FF.A03CDB37
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
See below at @@@

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of David Melman
Sent: Monday, May 12, 2008 5:54 AM
To: [e-mail]
Subject: [rbridge] Rbridge Protocol draft questions


In reading draft-ietf-trill-rbridge-protocol-07.txt, I have some
questions:
=20
In the Forwarding Behavior of native unknown DA, Multicast, and
Broadcast frames (described in sec 4.4.1):
=20
1) If there are links for which the Rbridge is the appointed forwarder
for the VLAN, should the packet be forwarded in native format out each
of those links, in addition to being TRILL encapsulated and sent on the
multi-destination tree?   The text does not describe forwarding in
native format on the links in which the Rbridge is the appointed
forwarder for the VLAN; however the behavior is described in regards to
forwarding of TRILL multi-destination packets.
=20
@@@ Yes, unknown DA, multicast, and broadcast native frames need to be
forwarded in native form out all RBridge ports where the RBridge is an
appointed forwarder for their VLAN, end station service has not been
disabled, and multicast pruning does not prune such transmission. Note
that in -07, the pseudo code dominates that text and there is a more
complete description covering more of these corner cases in Section 5.
The working group has decided that the text should dominate the pseudo
code so the text will have to be made complete.
=20
2) Might the TRILL encapsulated packet need to forwarded on more than
one link, e.g. if there are 2 or more downstream branches in the
multi-destination tree?=20
=20
@@@ Sure.=20
=20
In the Forwarding Behavior of  Unicast TRILL data frames (described in
sec 4.4.2.2.1):
=20
1) Text says "If M=3D=3D1 the frame is discarded".  But in the case the
inner MAC DA is unknown in ingress Rbridge FDB, the M bit is set to 1.
So this check to verify M=3D=3D1 seems to be a bug.=20
=20
@@@ I think you're right. Thanks for spotting this. At 4.4.2.2.1, if
M=3D=3D1, it should just handle the frame as in 4.4.2.2.2.=20
=20
2) For the Transit Rbridge case (i.e. egress Rbridge nickname !=3D local
Rbridge nickname), the text states: "the frame forwarded to the next hop
Rbridge towards the egress Rbridge using the Forwarding Database".  Is
this lookup in the "Forwarding Database" based on the inner MAC DA and
inner VLAN-ID, or is it intended that the Forwarding Database lookup be
based on the Trill header Egress RBridge nickname only?  If the prior,
what is the forwarding behavior in case the inner MAC DA is unknown on
the transit Rbridge - would it be similar to the native case?=20
=20
@@@ For known unicast, forwarding is based on the Egress RBridge
nickname. Transit RBridges don't learn the MAC addresses of end stations
attached to ingress and egress RBridges and have no need to do so. This
might, of course, lead you to question what a transit RBridge does with
a known unicast TRILL data frame if the egress RBridge nickname is
unknown. The answer is that there is, as yet, no provision for that
contingency in the protocol document. But presumably it silently drops
the frame (and increments some MIB variable but we haven't specified the
RBridge MIB yet).
=20
Thanks
David=20
=20
@@@ Thanks,
@@@ Donald
=20

------_=_NextPart_001_01C8B4FF.A03CDB37
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D437375903-13052008>Hi,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D437375903-13052008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D437375903-13052008>See below at @@@</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>David=20
Melman<BR><B>Sent:</B> Monday, May 12, 2008 5:54 AM<BR><B>To:</B>=20
[e-mail]<BR><B>Subject:</B> [rbridge] Rbridge Protocol draft=20
questions<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D074422607-12052008></SPAN></FONT></FONT><FONT face=3DArial><FONT =

size=3D2><SPAN class=3D074422607-12052008>In reading <FONT=20
face=3D"Times New Roman"><FONT size=3D3>d<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
HE">raft-ietf-trill-rbridge-protocol-07.txt,=20
I have some questions:</SPAN></FONT></FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D074422607-12052008></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D+0><FONT size=3D2><SPAN=20
class=3D074422607-12052008>In the Forwarding Behavior of&nbsp;native =
unknown DA,=20
Multicast, and Broadcast frames (described in sec=20
4.4.1):</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D+0><FONT size=3D2><SPAN=20
class=3D074422607-12052008></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D074422607-12052008>1) </SPAN>If there are links for which the =
Rbridge is=20
the appointed forwarder for the VLAN, should the packet be forwarded in =
native=20
format out&nbsp;<SPAN class=3D074422607-12052008>each of those =
</SPAN>link<SPAN=20
class=3D074422607-12052008>s, </SPAN></FONT></FONT></FONT></FONT><FONT=20
size=3D+0><FONT size=3D+0><FONT face=3DArial size=3D2>in addition to =
being&nbsp;<SPAN=20
class=3D074422607-12052008>TRILL </SPAN>encapsulated and&nbsp;<SPAN=20
class=3D074422607-12052008>sent on the</SPAN>&nbsp;multi-destination=20
tree?&nbsp;<SPAN class=3D074422607-12052008>&nbsp; The&nbsp;text =
does&nbsp;not=20
describe forwarding in native format on the links in which the Rbridge =
is the=20
appointed forwarder for the VLAN; however the behavior is described in =
regards=20
to forwarding of TRILL multi-destination=20
packets.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D437375903-13052008><FONT face=3DArial size=3D2>@@@ =
Yes, unknown DA,=20
multicast,&nbsp;and broadcast native frames need to be forwarded in =
native form=20
out all RBridge ports where the RBridge is an appointed forwarder for =
their=20
VLAN, end station service has not been disabled, and multicast pruning =
does not=20
prune such transmission. Note that in -07, the pseudo code dominates =
that text=20
and there is a more complete description covering more of these corner =
cases in=20
Section 5. The working group has decided that the text should dominate =
the=20
pseudo code so the text will have to be made =
complete.</FONT></SPAN></DIV>
<DIV><SPAN class=3D437375903-13052008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2>2<SPAN =
class=3D074422607-12052008>)=20
</SPAN><SPAN class=3D074422607-12052008>Might the TRILL encapsulated=20
packet&nbsp;need to forwarded on more than one link, e.g. if there are 2 =
or more=20
downstream branches in the multi-destination tree?<SPAN=20
class=3D437375903-13052008>&nbsp;</SPAN></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D074422607-12052008><SPAN=20
class=3D437375903-13052008></SPAN></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D074422607-12052008><SPAN=20
class=3D437375903-13052008>@@@ =
Sure.&nbsp;</SPAN></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial size=3D2><SPAN=20
class=3D074422607-12052008>In the Forwarding Behavior of&nbsp;</SPAN> =
Unicast=20
TRILL data frames (described in sec 4.4.2.2.1):</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial><FONT =
size=3D2>1) Text says=20
"If M=3D=3D1 the frame is discarded".&nbsp; But in the case the inner =
MAC DA is=20
unknown in ingress Rbridge FDB, the M bit is set to 1.&nbsp; So this =
check to=20
verify M=3D=3D1 seems to be a bug.<SPAN class=3D437375903-13052008><FONT =

color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D437375903-13052008></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D437375903-13052008>@@@ I think you're right. Thanks for spotting =
this. At=20
4.4.2.2.1, if M=3D=3D1, it should just handle the frame as in 4.4.2.2.2. =

</SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial size=3D2>2) For =
the Transit=20
Rbridge case (i.e. egress Rbridge nickname !=3D local Rbridge nickname), =
the text=20
states: "the frame forwarded to the next hop Rbridge towards the egress =
Rbridge=20
using the Forwarding Database".&nbsp; Is this lookup in =
the&nbsp;"Forwarding=20
Database" based on the inner MAC DA&nbsp;and inner VLAN-ID, or is it =
intended=20
that the Forwarding Database lookup be based on&nbsp;the Trill=20
header&nbsp;Egress RBridge nickname only?&nbsp; If the prior, what is =
the=20
forwarding behavior in case the inner MAC DA is unknown on the transit =
Rbridge -=20
would it be similar to the native case?&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><SPAN =
class=3D437375903-13052008><FONT=20
face=3DArial size=3D2>@@@ For known unicast, forwarding is based on the =
Egress=20
RBridge nickname. Transit RBridges don't learn the MAC addresses of end =
stations=20
attached to ingress and egress RBridges and have no need to do so. This =
might,=20
of course, lead you to question what a transit RBridge does with a known =
unicast=20
TRILL data frame if the egress RBridge nickname is unknown. The answer =
is that=20
there is, as yet, no provision for that contingency in the protocol =
document.=20
But presumably it silently drops the frame (and increments some MIB =
variable but=20
we haven't specified the RBridge MIB yet).</FONT></SPAN></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial=20
size=3D2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial size=3D2>David=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial =
size=3D2></FONT></SPAN><SPAN=20
class=3D074422607-12052008><FONT face=3DArial =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><SPAN =
class=3D437375903-13052008><FONT=20
face=3DArial size=3D2>@@@ Thanks,</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><SPAN =
class=3D437375903-13052008><FONT=20
face=3DArial size=3D2>@@@ Donald</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><SPAN =
class=3D437375903-13052008><FONT=20
face=3DArial size=3D2></FONT></SPAN>&nbsp;</DIV></SPAN></BODY></HTML>

------_=_NextPart_001_01C8B4FF.A03CDB37--


Received: from il.marvell.com (shoshil.marvell.com [199.203.130.250]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4C9rqKj026032 for <[e-mail]>; Mon, 12 May 2008 02:53:54 -0700 (PDT)
Received: from msil-owa01.marvell.com ([10.4.5.100]) by il.marvell.com (8.13.1/8.13.1) with ESMTP id m4C9rngH016946 for <[e-mail]>; Mon, 12 May 2008 12:53:50 +0300 (IDT)
Received: from msilexch01.marvell.com ([10.4.5.104]) by msil-owa01.marvell.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 May 2008 12:53:49 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B416.13D2AF23"
Date: Mon, 12 May 2008 12:53:48 +0300
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rbridge Protocol draft questions
Thread-Index: Aci0FhMUhwvJH9TuRoSxiTbIQndkFA==
From: "David Melman" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 12 May 2008 09:53:49.0860 (UTC) FILETIME=[140AEE40:01C8B416]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Rbridge Protocol draft questions
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 12 May 2008 09:54:26 -0000
Status: RO
Content-Length: 6659

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8B416.13D2AF23
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In reading draft-ietf-trill-rbridge-protocol-07.txt, I have some
questions:
=20
In the Forwarding Behavior of native unknown DA, Multicast, and
Broadcast frames (described in sec 4.4.1):
=20
1) If there are links for which the Rbridge is the appointed forwarder
for the VLAN, should the packet be forwarded in native format out each
of those links, in addition to being TRILL encapsulated and sent on the
multi-destination tree?   The text does not describe forwarding in
native format on the links in which the Rbridge is the appointed
forwarder for the VLAN; however the behavior is described in regards to
forwarding of TRILL multi-destination packets.
=20
2) Might the TRILL encapsulated packet need to forwarded on more than
one link, e.g. if there are 2 or more downstream branches in the
multi-destination tree?
=20
In the Forwarding Behavior of  Unicast TRILL data frames (described in
sec 4.4.2.2.1):
=20
1) Text says "If M=3D=3D1 the frame is discarded".  But in the case the
inner MAC DA is unknown in ingress Rbridge FDB, the M bit is set to 1.
So this check to verify M=3D=3D1 seems to be a bug.
=20
2) For the Transit Rbridge case (i.e. egress Rbridge nickname !=3D local
Rbridge nickname), the text states: "the frame forwarded to the next hop
Rbridge towards the egress Rbridge using the Forwarding Database".  Is
this lookup in the "Forwarding Database" based on the inner MAC DA and
inner VLAN-ID, or is it intended that the Forwarding Database lookup be
based on the Trill header Egress RBridge nickname only?  If the prior,
what is the forwarding behavior in case the inner MAC DA is unknown on
the transit Rbridge - would it be similar to the native case?=20
=20
=20
Thanks
David=20
=20

------_=_NextPart_001_01C8B416.13D2AF23
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3268" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D074422607-12052008></SPAN></FONT></FONT><FONT face=3DArial><FONT =

size=3D2><SPAN class=3D074422607-12052008>In reading <FONT=20
face=3D"Times New Roman"><FONT size=3D3>d<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
HE">raft-ietf-trill-rbridge-protocol-07.txt,=20
I have some questions:</SPAN></FONT></FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D074422607-12052008></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT><FONT size=3D2><SPAN =
class=3D074422607-12052008>In the=20
Forwarding Behavior of&nbsp;native unknown DA, Multicast, and Broadcast =
frames=20
(described in sec 4.4.1):</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT><FONT size=3D2><SPAN=20
class=3D074422607-12052008></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D074422607-12052008>1)=20
</SPAN>If there are links for which the Rbridge is the appointed =
forwarder for=20
the VLAN, should the packet be forwarded in native format out&nbsp;<SPAN =

class=3D074422607-12052008>each of those </SPAN>link<SPAN=20
class=3D074422607-12052008>s, =
</SPAN></FONT></FONT></FONT></FONT><FONT><FONT><FONT=20
face=3DArial size=3D2>in addition to being&nbsp;<SPAN =
class=3D074422607-12052008>TRILL=20
</SPAN>encapsulated and&nbsp;<SPAN class=3D074422607-12052008>sent on=20
the</SPAN>&nbsp;multi-destination tree?&nbsp;<SPAN=20
class=3D074422607-12052008>&nbsp; The&nbsp;text does&nbsp;not describe =
forwarding=20
in native format on the links in which the Rbridge is the appointed =
forwarder=20
for the VLAN; however the behavior is described in regards to forwarding =
of=20
TRILL multi-destination packets.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT size=3D2>2<SPAN =
class=3D074422607-12052008>)=20
</SPAN><SPAN class=3D074422607-12052008>Might the TRILL encapsulated=20
packet&nbsp;need to forwarded on more than one link, e.g. if there are 2 =
or more=20
downstream branches in the multi-destination=20
tree?</SPAN></FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial size=3D2><SPAN=20
class=3D074422607-12052008>In the Forwarding Behavior of&nbsp;</SPAN> =
Unicast=20
TRILL data frames (described in sec 4.4.2.2.1):</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial size=3D2>1) =
Text says "If=20
M=3D=3D1 the frame is discarded".&nbsp; But in the case the inner MAC DA =
is unknown=20
in ingress Rbridge FDB, the M bit is set to 1.&nbsp; So this check to =
verify=20
M=3D=3D1 seems to be a bug.</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial size=3D2>2) For =
the Transit=20
Rbridge case (i.e. egress Rbridge nickname !=3D local Rbridge nickname), =
the text=20
states: "the frame forwarded to the next hop Rbridge towards the egress =
Rbridge=20
using the Forwarding Database".&nbsp; Is this lookup in =
the&nbsp;"Forwarding=20
Database" based on the inner MAC DA&nbsp;and inner VLAN-ID, or is it =
intended=20
that the Forwarding Database lookup be based on&nbsp;the Trill=20
header&nbsp;Egress RBridge nickname only?&nbsp; If the prior, what is =
the=20
forwarding behavior in case the inner MAC DA is unknown on the transit =
Rbridge -=20
would it be similar to the native case?&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial=20
size=3D2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial size=3D2>David=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D074422607-12052008><FONT face=3DArial =
size=3D2></FONT></SPAN><SPAN=20
class=3D074422607-12052008>&nbsp;</DIV></SPAN></BODY></HTML>

------_=_NextPart_001_01C8B416.13D2AF23--