[rbridge] draft-eastlake-trill-802-protocols-00.txt

[Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Interaction of RBridges and 802 Protocols
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-802-protocols-00.txt
	Pages		: 16
	Date		: 2007-2-27
	
   This is a working document discussing the relationship of RBridges,
   that is, devices implementing the protocol being developed by the
   IETF TRILL working group, and various IEEE 802.1 and 802.3 protocols.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-eastlake-trill-802-protocols-0
0.txt



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 l1SIVpui011156 for <[e-mail]>; Wed, 28 Feb 2007 10:31:52 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-153.messagelabs.com!1172687510!2215619!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.103]
Received: (qmail 32144 invoked from network); 28 Feb 2007 18:31:50 -0000
Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-15.tower-153.messagelabs.com with SMTP; 28 Feb 2007 18:31:50 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l1SIViKt014377 for <[e-mail]>; Wed, 28 Feb 2007 11:31:50 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1SIVhPA000945 for <[e-mail]>; Wed, 28 Feb 2007 12:31:43 -0600 (CST)
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: Wed, 28 Feb 2007 13:31:42 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-eastlake-trill-802-protocols-00.txt
Thread-Index: AcdbZrFdkXiMf1z0RXmZpju4lDhxMA==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
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 l1SIVpui011156
Subject: [rbridge] draft-eastlake-trill-802-protocols-00.txt
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 Feb 2007 18:32:15 -0000
Status: RO
Content-Length: 581

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Interaction of RBridges and 802 Protocols
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-802-protocols-00.txt
	Pages		: 16
	Date		: 2007-2-27
	
   This is a working document discussing the relationship of RBridges,
   that is, devices implementing the protocol being developed by the
   IETF TRILL working group, and various IEEE 802.1 and 802.3 protocols.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-eastlake-trill-802-protocols-0
0.txt



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 l1G1P91S023186 for <[e-mail]>; Thu, 15 Feb 2007 17:25:11 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-128.messagelabs.com!1171589108!7779850!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 24899 invoked from network); 16 Feb 2007 01:25:08 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 16 Feb 2007 01:25:08 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1G1P4Cu023588 for <[e-mail]>; Thu, 15 Feb 2007 18:25:08 -0700 (MST)
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 l1G1P3gL010823 for <[e-mail]>; Thu, 15 Feb 2007 19:25:03 -0600 (CST)
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 Feb 2007 20:24:01 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Publication Request for draft-ietf-trill-routing-reqs-02.txt 
Thread-Index: AcdQYeRkX5e2wgPyRZimbBUfZ6iQ4gA6mcCw
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
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 l1G1P91S023186
Cc: [e-mail], [e-mail]
Subject: [rbridge] Publication Request for draft-ietf-trill-routing-reqs-02.txt
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, 16 Feb 2007 01:25:46 -0000
Status: RO
Content-Length: 7671

We request that "TRILL Routing Requirements in Support of RBridges",
http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt
be published as an Informational RFC. Below is the PROTO form.

Donald & Erik (co-chairs, TRILL)


   (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Donald Eastlake 3rd.
Yes.

   (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The working group is quite active in reviewing documents and this
document had WG consensus and passed WG Last Call. No specific review by
non-WG members occurred.

Working Group Last Call:
Initiation:
http://www.postel.org/pipermail/rbridge/2006-October/001458.html
Conclusion:
http://www.postel.org/pipermail/rbridge/2006-November/001776.html

   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

   (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

This high level document has a normative reference to the Rbridge
architecture document which is not at the same state of maturity.
However, as discussed with the Responsible AD, a request to publish is
being made at this time. Per the TRILL charter we need this document to
be able to formally select the routing protocol to use, which formally
needs to precede a routing group WG doing their extensions. It is also
believed that foreseeable changes to the architecture document are
unlikely to require changes to this less detailed document.

The following royalty free reciprocal type IPR disclosure relates to all
work in the TRILL WG including this document:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=439
There has been no discussion of IPR for this document in the working
group that I can recall

   (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is a broad consensus.

   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

   (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

There are no nits but one warning that the document does not have an
"intended status" section and one warning that the normative reference
"might" be a downref (which it is not).

   (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes, references are split. "The Architecture of an RBridge Solution to
TRILL"
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
by the same author is a normative reference not yet ready for
advancement but not a downward reference. See answer 1.d above.

   (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

Yes. No IANA actions.

   (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes. There are no such sections.

   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

RBridges provide the ability to have an entire domain, with multiple
physical links, look to IP like a single subnet. The design allows for
zero configuration of switches within an RBridge domain, optimal
pair-wise routing, safe forwarding even during periods of temporary
loops, and potential additional advantages as well.  The design also
supports VLANs, allows forwarding tables to be based on destinations
within the RBridge domain (rather than station destinations, allowing
internal forwarding tables to be smaller than in conventional bridge
systems).

The intent is to re-use one or more existing routing protocols to
accomplish these goals.

This document lays out the background and specific requirements of
potential routing protocols to be considered for use in this design. In
particular, this document defines what is needed to accommodate this
design using IS-IS (or OSPF) as a basis for RBridge protocols.

          Working Group Summary

This document has working group consensus.

          Document Quality

This document is of good quality.

          Personnel

The Document Shepherd for this document is Donald Eastlake 3rd. The
Responsible Area Director is Mark Townsley.

  (end)



Received: from mail.belairnetworks.com (mail.belairnetworks.com [142.46.200.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l1EEq6iZ027838 for <[e-mail]>; Wed, 14 Feb 2007 06:52:07 -0800 (PST)
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: Wed, 14 Feb 2007 09:52:05 -0500
Message-ID: <B3785208FF6119459354E44B555ADC0A010C4910@POSTAL2>
In-Reply-To: <B3785208FF6119459354E44B555ADC0A010C490F@POSTAL2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQAAODW0AAAWoMEABf4qaQAAKgrFAABEcc0APc5z5QAAAz4ZA=
From: "Jeff Joslin" <[e-mail]>
To: "Jeff Joslin" <[e-mail]>, <[e-mail]>
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 l1EEq6iZ027838
Subject: Re: [rbridge] Global MAC Addresses
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 Feb 2007 14:52:55 -0000
Status: RO
Content-Length: 7531

Woops, hit Send by mistake. 

SVL and IVL behave differently in two cases:
1. Devices that use the same MAC address on different physical ports.
Sun workstations did this until relatively recently.

2. Certain fancy network devices change VLAN IDs. One example
application is a bridge that intercepts all inter-host communications
(i.e., communications not between a host and a router), applies
filtering rules, and forwards any passed frames on a different VLAN.

In both these (admittedly obscure) cases, SVL does the Wrong Thing. It
also opens a security hole that allows clever attackers to access VLANs
to which they should not have access. Despite all this, modern Ethernet
switch processors often support SVL mode. I can only assume this is
because the chip designers implemented the spec without really
understanding it.

I am not really sure what this means for Rbridges, except that we should
expect to encounter SVL bridges in the wild, but we should most
definitely not optimize for them.

Jeff

> -----Original Message-----
> From: Jeff Joslin
> Sent: 14 February 2007 9:44 AM
> To: [e-mail]
> Subject: RE: [rbridge] Global MAC Addresses
> 
> I am coming late to the party, but SVL and IVL (i.e.,
Shared/Independent
> VLAN Learning) are subjects where I have learned lessons the hard way.
> 
> SVL was introduced during the 802.1Q standardization process as a
kludge
> that allowed existing hardware to achieve some level of VLAN support.
SVL
> uses the same forwarding-table format as non-VLAN-aware bridges, but
after
> choosing the destination port for a frame, the bridge does an
additional
> lookup to verify that the destination port belongs to the VLAN
indicated
> on the frame. In contrast, IVL uses the (VLAN,DA) pair to find the
> destination port.
> 
> SVL and IVL behave differently in two cases:
> 1. Devices that use the
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: 25 January 2007 7:42 PM
> > To: Caitlin Bestler
> > Cc: [e-mail]
> > Subject: Re: [rbridge] Global MAC Addresses
> >
> > Caitlin,
> >
> > 	I assume we are still talking about the -02 version of the
> > base protocol specification.  In that document, I could not find
> > any text that looked remotely like it was saying what you point
> > out below.
> >
> > 	I chatted briefly with one of the VLAN experts here at the
> > IEEE 802.1 meeting earlier and it seems that there is a mode of
> > operation (called "shared learning" or "shared VLAN learning")
> > where it is possible for VLAN bridges to learn MAC addresses for
> > multiple VLANs when they are heard on any of those VLANs.
> >
> > 	I do not know the details of how this is configured, but
> > from a preliminary sort of "poking around" it looks like it is
> > configured by making multiple VLANs part of a group for shared
> > VLAN learning.  So, apparently, the default is individual (or
> > independent - depending on who you talk to) VLAN learning.
> >
> > 	It also looks like VLAN learning and forwarding in general
> > does not use quite the same logical model that you've described.
> > As I said above, I haven't actually seen anywhere in the protocol
> > specification that expresses a VLAN learning and forwarding model
> > as you've described it, but it is possible that it does and - if
> > it does - that seems to be incorrect.
> >
> > 	Apparently, the VLAN learning and forwarding model uses the
> > concatenation - not of VLAN ID and MAC DA - but of FID and MAC DA
> > (where FID - forwarding database ID - MAY be the same for multiple
> > VLANs).  Since this is a description of how a forwarding decision
> > is made within an implementation, its value as a model is only to
> > explain what is expected from implementations in terms of external
> > visible behavior (meaning it doesn't have to actually be done that
> > way, it just has to look like it is).
> >
> > 	If the protocol specification describes a different model,
> > it may lead to confusion.  However, I did not see any place where
> > it clearly does.  For example, the statement "frame must be not be
> > delivered to links in any VLAN other than the one to which they
> > are addressed" is compatible with either learning mode - unless a
> > broken learning mode was selected for a specific VLAN deployment.
> >
> > 	Probably the most important reason why forwarding entries
> > MUST be scoped in some way in VLAN bridging is to prevent one or
> > more attackers from gaining access to VLANs they are not part of
> > by using MAC addresses directly.
> >
> > 	Finally, in order for an IPv6 address to be invalid in a
> > global context as a result of deriving it from a MAC address is
> > if more than one instance of the same MAC address exists within
> > the same network prefix.  If the network prefixes are different,
> > then the IPv6 addresses will be different.  Hence the only time
> > you can have a problem with IPv6 addresses derived in this way,
> > is if the MAC addresses are not even locally unique.
> >
> > 	Interstingly enough, I am really sure that the IPv6 folks
> > have looked at this before.  And I am also sure that at least one
> > suggested solution has been considered.  I do not know if any (of
> > possibly many) proposals were actually adopted but, if none were,
> > it would be because the IPv6 people did not see this as a problem.
> >
> > --
> > Eric
> >
> > > -----Original Message-----
> > > From: Caitlin Bestler [mailto:[e-mail]]
> > > Sent: Thursday, January 25, 2007 3:51 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: [e-mail]
> > > Subject: RE: [rbridge] Global MAC Addresses
> > >
> > > Eric Gray (LO/EUS) wrote:
> > >
> > > >
> > > >>
> > > >> Without explicitly stating it, the current draft recognizes
that
> > > >> because RBridges *share* data amongst themselves that they
> > > will find
> > > >> it challenging to do so without sharing semantics as well.
> > > >> Having RBridges disagree on whether the VLAN-ID is a key
> > > field or an
> > > >> attribute field could create some interesting problems.
> > > >> And there is certainly strong rationale for standardizing on
the
> > > >> VLAN-ID as key field approach.
> > > >
> > > > Agreed.  A specification draft cannot be ambivalent on issues
> > > > of this nature.
> > > >
> > > > Are you saying that is what is happening here?  Can you give
> > > > specific text examples where this is happening?
> > > >
> > >
> > > If RBridge R learns of MAC X on VLAN Y that information is
explicitly
> > > NOT forwarded to RBridge S unless RBridge S is not part of VLAN Y.
> > >
> > > If RBridge S has MAC X as belonging to VLAN Z then we would have
> > > a conflict if either of the RBridges considered the "L2 Key" to
> > > be just the MAC address. Nominally global IPv6 addresses which
> > > actually reach *different* destinations.
> > >
> > > Such conflicts were much more benign when bridges merely forwarded
> > > packets and didn't forward location data.
> > >
> > > There enumeration of RBridge retained data also states that L2
> > > and L2/L3 tracking data is per-VLAN.
> > >
> > > The justification for this is that "global" MAC addresses are in
> > > fact not global. That's counter-intuitive enough that I think it
> > > at least needs to be explicitly noted.
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail.belairnetworks.com (mail.belairnetworks.com [142.46.200.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l1EEiNYm025662 for <[e-mail]>; Wed, 14 Feb 2007 06:44:23 -0800 (PST)
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: Wed, 14 Feb 2007 09:44:19 -0500
Message-ID: <B3785208FF6119459354E44B555ADC0A010C490F@POSTAL2>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQAAODW0AAAWoMEABf4qaQAAKgrFAABEcc0APc5z5Q
From: "Jeff Joslin" <[e-mail]>
To: <[e-mail]>
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 l1EEiNYm025662
Subject: Re: [rbridge] Global MAC Addresses
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 Feb 2007 14:45:08 -0000
Status: RO
Content-Length: 6101

I am coming late to the party, but SVL and IVL (i.e., Shared/Independent
VLAN Learning) are subjects where I have learned lessons the hard way.

SVL was introduced during the 802.1Q standardization process as a kludge
that allowed existing hardware to achieve some level of VLAN support.
SVL uses the same forwarding-table format as non-VLAN-aware bridges, but
after choosing the destination port for a frame, the bridge does an
additional lookup to verify that the destination port belongs to the
VLAN indicated on the frame. In contrast, IVL uses the (VLAN,DA) pair to
find the destination port.

SVL and IVL behave differently in two cases:
1. Devices that use the 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: 25 January 2007 7:42 PM
> To: Caitlin Bestler
> Cc: [e-mail]
> Subject: Re: [rbridge] Global MAC Addresses
> 
> Caitlin,
> 
> 	I assume we are still talking about the -02 version of the
> base protocol specification.  In that document, I could not find
> any text that looked remotely like it was saying what you point
> out below.
> 
> 	I chatted briefly with one of the VLAN experts here at the
> IEEE 802.1 meeting earlier and it seems that there is a mode of
> operation (called "shared learning" or "shared VLAN learning")
> where it is possible for VLAN bridges to learn MAC addresses for
> multiple VLANs when they are heard on any of those VLANs.
> 
> 	I do not know the details of how this is configured, but
> from a preliminary sort of "poking around" it looks like it is
> configured by making multiple VLANs part of a group for shared
> VLAN learning.  So, apparently, the default is individual (or
> independent - depending on who you talk to) VLAN learning.
> 
> 	It also looks like VLAN learning and forwarding in general
> does not use quite the same logical model that you've described.
> As I said above, I haven't actually seen anywhere in the protocol
> specification that expresses a VLAN learning and forwarding model
> as you've described it, but it is possible that it does and - if
> it does - that seems to be incorrect.
> 
> 	Apparently, the VLAN learning and forwarding model uses the
> concatenation - not of VLAN ID and MAC DA - but of FID and MAC DA
> (where FID - forwarding database ID - MAY be the same for multiple
> VLANs).  Since this is a description of how a forwarding decision
> is made within an implementation, its value as a model is only to
> explain what is expected from implementations in terms of external
> visible behavior (meaning it doesn't have to actually be done that
> way, it just has to look like it is).
> 
> 	If the protocol specification describes a different model,
> it may lead to confusion.  However, I did not see any place where
> it clearly does.  For example, the statement "frame must be not be
> delivered to links in any VLAN other than the one to which they
> are addressed" is compatible with either learning mode - unless a
> broken learning mode was selected for a specific VLAN deployment.
> 
> 	Probably the most important reason why forwarding entries
> MUST be scoped in some way in VLAN bridging is to prevent one or
> more attackers from gaining access to VLANs they are not part of
> by using MAC addresses directly.
> 
> 	Finally, in order for an IPv6 address to be invalid in a
> global context as a result of deriving it from a MAC address is
> if more than one instance of the same MAC address exists within
> the same network prefix.  If the network prefixes are different,
> then the IPv6 addresses will be different.  Hence the only time
> you can have a problem with IPv6 addresses derived in this way,
> is if the MAC addresses are not even locally unique.
> 
> 	Interstingly enough, I am really sure that the IPv6 folks
> have looked at this before.  And I am also sure that at least one
> suggested solution has been considered.  I do not know if any (of
> possibly many) proposals were actually adopted but, if none were,
> it would be because the IPv6 people did not see this as a problem.
> 
> --
> Eric
> 
> > -----Original Message-----
> > From: Caitlin Bestler [mailto:[e-mail]]
> > Sent: Thursday, January 25, 2007 3:51 PM
> > To: Eric Gray (LO/EUS)
> > Cc: [e-mail]
> > Subject: RE: [rbridge] Global MAC Addresses
> >
> > Eric Gray (LO/EUS) wrote:
> >
> > >
> > >>
> > >> Without explicitly stating it, the current draft recognizes that
> > >> because RBridges *share* data amongst themselves that they
> > will find
> > >> it challenging to do so without sharing semantics as well.
> > >> Having RBridges disagree on whether the VLAN-ID is a key
> > field or an
> > >> attribute field could create some interesting problems.
> > >> And there is certainly strong rationale for standardizing on the
> > >> VLAN-ID as key field approach.
> > >
> > > Agreed.  A specification draft cannot be ambivalent on issues
> > > of this nature.
> > >
> > > Are you saying that is what is happening here?  Can you give
> > > specific text examples where this is happening?
> > >
> >
> > If RBridge R learns of MAC X on VLAN Y that information is
explicitly
> > NOT forwarded to RBridge S unless RBridge S is not part of VLAN Y.
> >
> > If RBridge S has MAC X as belonging to VLAN Z then we would have
> > a conflict if either of the RBridges considered the "L2 Key" to
> > be just the MAC address. Nominally global IPv6 addresses which
> > actually reach *different* destinations.
> >
> > Such conflicts were much more benign when bridges merely forwarded
> > packets and didn't forward location data.
> >
> > There enumeration of RBridge retained data also states that L2
> > and L2/L3 tracking data is per-VLAN.
> >
> > The justification for this is that "global" MAC addresses are in
> > fact not global. That's counter-intuitive enough that I think it
> > at least needs to be explicitly noted.
> >
> >
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l11N1qtV004300 for <[e-mail]>; Thu, 1 Feb 2007 15:01:53 -0800 (PST)
Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Thu, 01 Feb 2007 15:01:43 -0800
X-Server-Uuid: D7CB97D3-6392-476F-BE46-AB3D6F515C9A
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EC0892AF; Thu, 1 Feb 2007 15:01:42 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CA8832BB for <[e-mail]>; Thu, 1 Feb 2007 15:01:41 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EWD64419; Thu, 1 Feb 2007 15:01:24 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id D342520501 for <[e-mail]>; Thu, 1 Feb 2007 15:01:23 -0800 ( PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 1 Feb 2007 15:01:23 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: VLAN Scoping / MAC Uniqueness
Thread-Index: AcdGQ0mg9ev6ooLJQ7yBeKtRGud5dwADiLvA
From: "Caitlin Bestler" <[e-mail]>
To: [e-mail]
X-WSS-ID: 69DCAEDD3EK34410803-01-01
Content-Type: text/plain; charset=us-ascii
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 l11N1qtV004300
Subject: [rbridge] VLAN Scoping / MAC Uniqueness
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, 01 Feb 2007 23:02:19 -0000
Status: RO
Content-Length: 3806

I'm going to try to distill the MAC uniqueness issue down
to the RBridge specific issue of RBridge information
sharing, and whether any new wrinkles are being introduced
or whether RBridges as specified are compatible with
current VLAN practices.

The potential issue revolves around this statement:

   Station information need only be delivered to RBridges supporting
   the VLAN in which the station resides. So, for instance, if station
   E is discovered through a VLAN A frame, then E's location need only
   be delivered to other RBridges that are attached to VLAN A links.

That's from section 3 of the routing requirements, but the 
same requirement is expressed elsewhere.

Now consider the following scenario, which is admittedly
highly unconventional and almost certainly the result of
bad network administration):

	RBridge A has access to VLANs 1 and 2.
	RBridge B has access to VLANs 2 and 3.
	RBridge C has access to VLAN 3.

	RBridge A detects MAC Address X on VLAN 2.
	RBridge A informs RBridge B that it has Address X on VLAN 2.

	RBridge C detects MAC Address X on VLAN 3.
	RBRidge C informs RBridge B that it has Address X on VLAN 3.

Now, if RBridge B considers VLANs 2 and 3 to be distinct trees
for the purposes of learning addresses there are no problems
with this scenario.

But if RBridge B handles VLANs 2 and 3 in the same learning
tree, then "X is on VLAN 3 handled by RBridge C" replaces
"X is on VLAN 2 handle by RBriddge A". But that update
is only made on RBridge B -- it is NOT made on RBridge A.

One resolution is to require that RBridges treat each
each VLAN as a distinct instance and organize their
data accordingly. My current reading is that the protocol
document does in fact make this requirement, but perhaps
is not as explicit about it as desirable.

If that requirement is understood by ALL RBridges, it
is indeed safe to only share data about VLAN 3 with
RBridges that support VLAN 3.

On the other hand, if RBridges are allowed to do shared
tree learning (just as conventional bridges are allowed
currently) then the real requirement would be:

	Station information need only be delivered to RBridges
supporting
	the naming scope of the VLAN in which the state resides. So, for
	instance, if station E is discovered through a VLAN A frame, and
	VLAN A is part of naming scope X, then E's location need only
	be delivered to other RBridges that are attached to VLANs that
	are part of naming scope X.

That would of course beg the issue, how does an RBridge know what
naming scopes other RBridges use? It would increase the complexity
of information shared through discovery.

Further, if only a single RBridge used global/single-tree learning
then all other RBridges would have to send it *all* updates. So the
value of attempting to track the naming scopes of each RBridge seems
minimal to me.

This suggests three options:

	1) Require all RBridges to scope on a per-VLAN basis.
	   The only real flaw in this is that it is a RBridge
	   requirement that does not apply to conventional bridges.

	2) Allow all RBridges to have whatever scoping rules they
	   want, but require that all updates go to all RBridgges.
	   Each RBridge can judge for itself it the information is
	   relevant to it, and organize that data however it wants.

	3) Punt: require the network adminstrator to ensure that naming
	   scopes enforced by RBRidges are "consistent" and provide
	   only text-based suggestions on how to achieve this.

What I would not suggest is actually mapping this complexity to
achieve zero configuration no matter how deranged the VLAN
deployment is. Anyone using "global" MAC addreses that have
less than "global" scope should be responsible for doing at
least a little bit of planning and not rely on run-time systems
to catch their mistakes.





Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l11Ko8Rd027741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 1 Feb 2007 12:50:09 -0800 (PST)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1C3D9272B3; Thu,  1 Feb 2007 20:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCisc-00086L-Ra; Thu, 01 Feb 2007 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 01 Feb 2007 15:50:02 -0500
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-routing-reqs-02.txt
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, 01 Feb 2007 20:50:41 -0000
Status: RO
Content-Length: 3529

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: TRILL Routing Requirements in Support of RBridges
	Author(s)	: E. Gray
	Filename	: draft-ietf-trill-routing-reqs-02.txt
	Pages		: 11
	Date		: 2007-2-1
	
RBridges provide the ability to have an entire domain, with multiple 
   physical links, look to IP like a single subnet. The design allows 
   for zero configuration of switches within an RBridge domain, optimal 
   pair-wise routing, safe forwarding even during periods of temporary 
   loops, and potential additional advantages as well.  The design also
   supports VLANs, allows forwarding tables to be based on destinations 
   within the RBridge domain (rather than station destinations, allowing 
   internal forwarding tables to be smaller than in conventional bridge 
   systems).
   The intent is to re-uses one or more existing routing protocols to
   accomplish these goals.

   This document lays out the background and specific requirements of
   potential routing protocols to be considered for use in this design.
   In particular, this document defines what is needed to accomodate
   this design using IS-IS (or OSPF) as a basis for RBridge protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-routing-reqs-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-trill-routing-reqs-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-routing-reqs-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trill-routing-reqs-02.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart--