[rbridge] Global MAC Addresses

[eric.gray at ericsson.com (Eric Gray (LO/EUS))]

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:caitlinb at broadcom.com] 
> Sent: Thursday, January 25, 2007 3:51 PM
> To: Eric Gray (LO/EUS)
> Cc: rbridge at postel.org
> 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.
> 
> 
> 
> 



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 l0Q0fdIl012935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 25 Jan 2007 16:41:40 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l0Q14FIO027576; Thu, 25 Jan 2007 19:04:15 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 25 Jan 2007 18:41:38 -0600
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, 25 Jan 2007 18:41:34 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQAAODW0AAAWoMEABf4qaQAAKgrFAABEcc0A==
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>
X-OriginalArrivalTime: 26 Jan 2007 00:41:38.0741 (UTC) FILETIME=[BD615E50:01C740E2]
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 l0Q0fdIl012935
Cc: [e-mail]
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: Fri, 26 Jan 2007 00:42:07 -0000
Status: RO
Content-Length: 4821

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.
> 
> 
> 
> 



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 l0Q0fZQx012926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 25 Jan 2007 16:41:36 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l0Q14AkV027571; Thu, 25 Jan 2007 19:04:11 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 25 Jan 2007 18:41:34 -0600
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, 25 Jan 2007 18:41:30 -0600
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQAAODW0AAAWoMEABf4qaQAAKgrFAABEcc0AABw8tg
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>
X-OriginalArrivalTime: 26 Jan 2007 00:41:34.0460 (UTC) FILETIME=[BAD423C0:01C740E2]
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 l0Q0fZQx012926
Cc: [e-mail]
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: Fri, 26 Jan 2007 00:42:02 -0000
Status: RO
Content-Length: 1432

Caitlin,

	I think we should probably take this discussion off-line
as the answer I am working on is probably too much information
for most of the people on this list.  In summary for the list:

1) It is actually the concatentation of FID + MAC DA that is
   usually used in making a VLAN bridge forwarding decision -
   anywhere where it looks like VLAN + MAC DA is implied (or
   stated), it may be a simplification - and probably is not
   confusing for many implementers.

2) There are two types of VLAN learning involved in what we
   are talking about - individual/independent VLAN learning
   and shared VLAN learning (both are allowed, neither has 
   anything in particular to do with us).

3) There are trade-offs associated with choosing which mode 
   of VLAN learning makes the most sense for different VLAN
   ID subsets in a VLAN bridging deployment - hence this is
   typically a configuration option (if there is a global
   default, it should be individual/independent learning).

4) Using the VLAN ID (or FID) as part of forwarding decisions
   is not so much about the possibility that a MAC address 
   may not be unique as about the fact that forwarding has to
   be scoped in order to properly support VLANs.

5) I fail to see - even if MAC addresses are not unique -
   either how it is this should result in non-globally 
   unique IPv6 addresses, or how it would be TRILL's problem
   if it did.

--
Eric



Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0PKpUJw015904 for <[e-mail]>; Thu, 25 Jan 2007 12:51:30 -0800 (PST)
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Thu, 25 Jan 2007 12:51:12 -0800
X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 070A52B0; Thu, 25 Jan 2007 12:51:12 -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 D82232AE; Thu, 25 Jan 2007 12:51:11 -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 EVE56501; Thu, 25 Jan 2007 12:51:09 -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 DC1D520501; Thu, 25 Jan 2007 12:51:08 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 25 Jan 2007 12:51:07 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQAAODW0AAAWoMEABf4qaQAAKgrFA=
From: "Caitlin Bestler" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-WSS-ID: 69A7C7CA3Y810874126-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 l0PKpUJw015904
Cc: [e-mail]
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: Thu, 25 Jan 2007 20:52:26 -0000
Status: RO
Content-Length: 1431

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.






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 l0PK6SXu002806 for <[e-mail]>; Thu, 25 Jan 2007 12:06:29 -0800 (PST)
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 l0PKT28x000605; Thu, 25 Jan 2007 14:29:03 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 25 Jan 2007 14:06:27 -0600
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, 25 Jan 2007 14:06:23 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQAAODW0AAAWoMEABf4qaQ
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>
X-OriginalArrivalTime: 25 Jan 2007 20:06:27.0262 (UTC) FILETIME=[4BC59DE0:01C740BC]
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 l0PK6SXu002806
Cc: [e-mail]
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: Thu, 25 Jan 2007 20:08:15 -0000
Status: RO
Content-Length: 6991

Caitlin,

	As a general observation, my previous reply was intended
only to address the questions in your third paragraph.  I did
not see that there was anything to address in you comments on
concatenating VLAN + MAC or derivation of globally unique IPv6
addresses from potentially locally unique L2 addresses.

	Please see additional comments below...

--
Eric

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]] 
> Sent: Wednesday, January 24, 2007 11:40 AM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]
> Subject: RE: [rbridge] Global MAC Addresses
> 
> Eric Gray (LO/EUS) wrote:
> > Caitlin,
> > 
> > 	Please see one comment in-line below...
> > 
> > 
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Caitlin Bestler
> >> Sent: Tuesday, January 23, 2007 2:23 PM
> >> To: [e-mail]
> >> Subject: [rbridge] Global MAC Addresses
> >> 
> >> Reading through draft-ietf-trill-rbridge-protocol-02 I can spot
> >> many places where it is assumed that a globally unique L2
> >> identifier can only be formed by concatenating the VLAN ID and
> >> the MAC Address. 
> >> 
> >> This may be a very realistic assessment, but it raises issues
> >> concerning global scope IPv6 addresses derived from the MAC
Address.
> >> 
> >> Has the IETF addressed the issues of "global" MAC Addresses that
are
> >> not global? In particular that IP routing should not be performed
> >> between two subnets that have different concepts of what a "global"
> >> MAC address is? 
> >> 
> > 
> > This is not an issue.  IP Routers are L2 endstations at each
> > LAN attachment point and can have locally unique MAC
> > addresses in each LAN to which they are attached.  IP Routers
> > (at least, when acting as routers) don't transparently
> > forward MAC frames either.  Consequently, the MAC address (of
> > an IP router) that is visible on any LAN is a MAC address
> > that is appropriate for that LAN.
> > 
> > Consequently, there is no reason why "IP routing should not
> > be performed between subnets that have different concepts of
> > what a 'global' MAC adress is"...
> > 
> 
> RFC3513 (IPV6 Addressing Architecture) states:
> 
>    Modified EUI-64 format based Interface identifiers may have global
>    scope when derived from a global token (e.g., IEEE 802 
> 48-bit MAC or
>    IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
>    global token is not available (e.g., serial links, tunnel 
> end-points,
>    etc.) or where global tokens are undesirable (e.g., 
> temporary tokens
>    for privacy [PRIV]).

Note the liberal use of the word "may".  I believe that - if you
check with the IPv6 experts - you'll find that nobody assumes a
MAC address MUST be unique.

> 
> Effectively, the practice of treating each VLAN as being
> totally independent means that even when the Interface ID is derived
> from a global IEEE EUI-64 that in fact there is no "global token"
> available.
>

It's possibly misleading to refer to the treatment of VLANs 
as "being totally independent" as a "practice".

The behavior that distinguishes VLAN forwarding from bridge
forwarding is the use of concatenated VLAN + MAC.  It is 
also possible that other information may be used as well.

> 
> At the minimum this is counter-intuitive and worthy of warnings.
> 

I suspect that you agree that it is not necessary for TRILL to
include such warnings as they belong to the definition of VLAN
as defined in appropriate SDO(s).  TRILL is not redefining the
term VLAN, as far as I know, in any way that produces this as 
a new problem.

>
> My understanding of the relevant 802.1 definitions is that a global
> MAC address *is* global, but that bridges are explicitly allowed
> to keep per-VLAN data and not enforce global scoping. On the other
> hand, they are allowed to do so. Effectively, you can have an
> interoperable mix of bridges that do global MAC address learning
> (where the VLAN-ID is an *attribute*) and per-VLAN MAC address
> learning (where the VLAN-ID is a *key*).
>

You may be right, but I suspect that it is only previously existing 
bridges that are "allowed" to ignore per-VLAN forwarding information
and that so-called VLAN-aware bridges are in fact encouraged (if not
actually required) to derive and/or retain per-VLAN forwarding data
- explicitly assuming that MAC addresses are scoped by VLAN.

If they don't, then there are plenty of scenarios in which VLANs 
may not work correctly.

This is true - for example - where VLAN IDs are used explicitly to
distinguish forwarding paths on the basis of resource use.

At the same time, however, where people expect VLANs to work, they
are less likely to mix VLAN-aware and VLAN-unaware equipment in the
same network.

> 
> 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?

> 
> But to the best of my knowledge, no prior IETF document has
> actually crossed this line. Which raises the need to clarify
> the semantics of MAC-derived IPv6 addresses. Otherwise certain
> network services might rely on these global addresses being
> truly global and create problems.
>

This seems to be out of scope for us.  If you're saying that it
may be necessary for us to specify how to derive globally unique
IPv6 addresses when it is possible that MAC addresses may not be
globally unique, then it is DEFINITELY out of scope for us.

I personally don't see this as a problem, but - even if it is -
it isn't our problem.

> 
> For example, when I was working on CMTS (cable modem head
> end equipment) the MAC addresses of the cable modems actually
> were guaranteed to be unique. So if the same MAC address showed
> up on a new frequency, or in a new location, it was either a 
> clone or it indicated that the box had migrated (on frequency
> and/or location). There was a need to determine which report
> would be believed (generally the newer one) and to ignore or
> remove the other.
> 
> That scenario obviously does not apply here, but could there
> be others? Might a duplicate MAC address trigger a network
> intrusion alert? Might a host assume that Link Local MAC X
> for VLAN 3 and Link Local MAC X for VLAN 4 (where VLAN 3 and
> VLAN 4 are on the same physical link) represent the same
> device that has enabled itself for two VLANs?
> 

These may be general problems that either have been addressed
or will be addressed, generally - and elsewhere.

> 



Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0OLoApC023804 for <[e-mail]>; Wed, 24 Jan 2007 13:50:10 -0800 (PST)
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Wed, 24 Jan 2007 13:49:58 -0800
X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 2460A2AE; Wed, 24 Jan 2007 13:49:58 -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 9FE252AE; Wed, 24 Jan 2007 13:49:57 -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 EVA76520; Wed, 24 Jan 2007 13:49:56 -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 6498120509; Wed, 24 Jan 2007 13:49:56 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 24 Jan 2007 13:49:46 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc//nkvUhkpD49XSpG38fUAyi6abwAAEZRA
From: "Caitlin Bestler" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-WSS-ID: 69A90B0C3S410553059-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 l0OLoApC023804
Cc: [e-mail]
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, 24 Jan 2007 21:50:29 -0000
Status: RO
Content-Length: 2232

Radia Perlman wrote:
> I think I understand the issue Caitlin is raising. MAC
> addresses might not be globally unique, and therefore some
> applications that depend on it might fail in weird ways,
> (such as IP with addresses derived from MAC addresses).
> 
> I don't think this is really a problem within RBridges. I do
> not think RBridges should try to enforce uniqueness, or flag
> duplicates, by trying to compare endnode data on different VLANs.
> 
> I think this problem (potential nonuniqueness of MAC
> addresses) should be addressed within the context in which it
> actually causes a problem, and RBridges should just ignore
> the issue. Within a VLAN if a MAC address appears twice, an RBridge
> could 
> 
> a) assume the endnode is multiply connected, and not worry
> about it at all
> b) have Designated RBridge R1 "worry" if endnode E, which R1
> thinks is on R1's own link, gets announced by R2 as being
> connected to R2, and have R1 ping E in some way, and
> periodically, to reassure R1 that E is still connected.
> RBridges other than R1 or R2 will treat E as reachable via either R1
> or R2. c) and/or log the fact that E seems to be multiply connected.
> 
> Other than potentially doing b) or c), I don't see what else
> an RBridge should do in this case.
> 
> Radia
> 

I agree that there is no problems for RBridges themselves.
The RBridges collectively are implementing a distributed
location database and ARP/ND proxy system. Having inconsistent
semantics as to what constitutes a unique L2 address would be
just asking for problems. The current drafts avoid that trap.
And having stated those expectations, I do not believe that
we need to mandate or suggest any enforcement mechanisms.

But by specifying that RBridges will track end-nodes on a per
VLAN basis (rather than tracking what VLAN, if any, each end
node is attached to) the RBridge drafts would acknowledge
and therefore implicitly bless the practice of having "global"
MAC Addresses with less than global scope.

Whether this practice should be merely noted or more formally
recognized/endorsed, is an issue that should probably be
considered by some other group with the IETF. I'm not sure if
it would be tsvwg, tsvarea or an IPV6 group. 




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 l0OLRWqR014811 for <[e-mail]>; Wed, 24 Jan 2007 13:27:32 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.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, 24 Jan 2007 13:27:19 -0800 (PST)
Received: from sun.com ([129.150.24.43]) 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, 24 Jan 2007 13:27:19 -0800 (PST)
Date: Wed, 24 Jan 2007 13:27:17 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Caitlin Bestler <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
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, 24 Jan 2007 21:28:24 -0000
Status: RO
Content-Length: 5613

I think I understand the issue Caitlin is raising. MAC addresses might 
not be globally unique, and
therefore some applications that depend on it might
fail in weird ways, (such as IP with addresses derived from MAC addresses).

I don't think this is really a problem within RBridges. I do not think 
RBridges should try to enforce uniqueness, or
flag duplicates, by trying to compare endnode data on different VLANs.

I think this problem (potential nonuniqueness of MAC addresses) should 
be addressed within the context in
which it actually causes a problem, and RBridges should just ignore the 
issue. Within a VLAN if a MAC
address appears twice, an RBridge could

a) assume the endnode is multiply connected, and not worry about it at all
b) have Designated RBridge R1 "worry" if endnode E, which R1 thinks is 
on R1's own link, gets announced
by R2 as being connected to R2, and have R1 ping E in some way, and 
periodically, to reassure R1 that
E is still connected. RBridges other than R1 or R2 will treat E as 
reachable via either R1 or R2.
c) and/or log the fact that E seems to be multiply connected.

Other than potentially doing b) or c), I don't see what else an RBridge 
should do in this case.

Radia



Caitlin Bestler wrote:

>Eric Gray (LO/EUS) wrote:
>  
>
>>Caitlin,
>>
>>	Please see one comment in-line below...
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of Caitlin Bestler
>>>Sent: Tuesday, January 23, 2007 2:23 PM
>>>To: [e-mail]
>>>Subject: [rbridge] Global MAC Addresses
>>>
>>>Reading through draft-ietf-trill-rbridge-protocol-02 I can spot many
>>>places where it is assumed that a globally unique
>>>L2 identifier can only be formed by concatenating the VLAN ID and
>>>the MAC Address. 
>>>
>>>This may be a very realistic assessment, but it raises issues
>>>concerning global scope IPv6 addresses derived from the MAC Address.
>>>
>>>Has the IETF addressed the issues of "global" MAC Addresses that are
>>>not global? In particular that IP routing should not be performed
>>>between two subnets that have different concepts of what a "global"
>>>MAC address is? 
>>>
>>>      
>>>
>>This is not an issue.  IP Routers are L2 endstations at each
>>LAN attachment point and can have locally unique MAC
>>addresses in each LAN to which they are attached.  IP Routers
>>(at least, when acting as routers) don't transparently
>>forward MAC frames either.  Consequently, the MAC address (of
>>an IP router) that is visible on any LAN is a MAC address
>>that is appropriate for that LAN.
>>
>>Consequently, there is no reason why "IP routing should not
>>be performed between subnets that have different concepts of
>>what a 'global' MAC adress is"...
>>
>>    
>>
>
>RFC3513 (IPV6 Addressing Architecture) states:
>
>   Modified EUI-64 format based Interface identifiers may have global
>   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
>   IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
>   global token is not available (e.g., serial links, tunnel end-points,
>   etc.) or where global tokens are undesirable (e.g., temporary tokens
>   for privacy [PRIV]).
>
>Effectively, the practice of treating each VLAN as being
>totally independent means that even when the Interface ID is derived
>from a global IEEE EUI-64 that in fact there is no "global token"
>available.
>
>At the minimum this is counter-intuitive and worthy of warnings.
>
>My understanding of the relevant 802.1 definitions is that a global
>MAC address *is* global, but that bridges are explicitly allowed
>to keep per-VLAN data and not enforce global scoping. On the other
>hand, they are allowed to do so. Effectively, you can have an
>interoperable mix of bridges that do global MAC address learning
>(where the VLAN-ID is an *attribute*) and per-VLAN MAC address
>learning (where the VLAN-ID is a *key*).
>
>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.
>
>But to the best of my knowledge, no prior IETF document has
>actually crossed this line. Which raises the need to clarify
>the semantics of MAC-derived IPv6 addresses. Otherwise certain
>network services might rely on these global addresses being
>truly global and create problems.
>
>For example, when I was working on CMTS (cable modem head
>end equipment) the MAC addresses of the cable modems actually
>were guaranteed to be unique. So if the same MAC address showed
>up on a new frequency, or in a new location, it was either a 
>clone or it indicated that the box had migrated (on frequency
>and/or location). There was a need to determine which report
>would be believed (generally the newer one) and to ignore or
>remove the other.
>
>That scenario obviously does not apply here, but could there
>be others? Might a duplicate MAC address trigger a network
>intrusion alert? Might a host assume that Link Local MAC X
>for VLAN 3 and Link Local MAC X for VLAN 4 (where VLAN 3 and
>VLAN 4 are on the same physical link) represent the same
>device that has enabled itself for two VLANs?
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0OGeR3s019461 for <[e-mail]>; Wed, 24 Jan 2007 08:40:27 -0800 (PST)
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Wed, 24 Jan 2007 08:40:21 -0800
X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E53A02AF; Wed, 24 Jan 2007 08:40:20 -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 C22D72AE; Wed, 24 Jan 2007 08:40:20 -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 EUZ98650; Wed, 24 Jan 2007 08:40:18 -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 4EFEE20502; Wed, 24 Jan 2007 08:40:18 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 24 Jan 2007 08:40:17 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQAAODW0AAAWoMEA==
From: "Caitlin Bestler" <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>
X-WSS-ID: 69A9547F3S410453292-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 l0OGeR3s019461
Cc: [e-mail]
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, 24 Jan 2007 16:40:46 -0000
Status: RO
Content-Length: 4123

Eric Gray (LO/EUS) wrote:
> Caitlin,
> 
> 	Please see one comment in-line below...
> 
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Caitlin Bestler
>> Sent: Tuesday, January 23, 2007 2:23 PM
>> To: [e-mail]
>> Subject: [rbridge] Global MAC Addresses
>> 
>> Reading through draft-ietf-trill-rbridge-protocol-02 I can spot many
>> places where it is assumed that a globally unique
>> L2 identifier can only be formed by concatenating the VLAN ID and
>> the MAC Address. 
>> 
>> This may be a very realistic assessment, but it raises issues
>> concerning global scope IPv6 addresses derived from the MAC Address.
>> 
>> Has the IETF addressed the issues of "global" MAC Addresses that are
>> not global? In particular that IP routing should not be performed
>> between two subnets that have different concepts of what a "global"
>> MAC address is? 
>> 
> 
> This is not an issue.  IP Routers are L2 endstations at each
> LAN attachment point and can have locally unique MAC
> addresses in each LAN to which they are attached.  IP Routers
> (at least, when acting as routers) don't transparently
> forward MAC frames either.  Consequently, the MAC address (of
> an IP router) that is visible on any LAN is a MAC address
> that is appropriate for that LAN.
> 
> Consequently, there is no reason why "IP routing should not
> be performed between subnets that have different concepts of
> what a 'global' MAC adress is"...
> 

RFC3513 (IPV6 Addressing Architecture) states:

   Modified EUI-64 format based Interface identifiers may have global
   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
   IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
   global token is not available (e.g., serial links, tunnel end-points,
   etc.) or where global tokens are undesirable (e.g., temporary tokens
   for privacy [PRIV]).

Effectively, the practice of treating each VLAN as being
totally independent means that even when the Interface ID is derived
from a global IEEE EUI-64 that in fact there is no "global token"
available.

At the minimum this is counter-intuitive and worthy of warnings.

My understanding of the relevant 802.1 definitions is that a global
MAC address *is* global, but that bridges are explicitly allowed
to keep per-VLAN data and not enforce global scoping. On the other
hand, they are allowed to do so. Effectively, you can have an
interoperable mix of bridges that do global MAC address learning
(where the VLAN-ID is an *attribute*) and per-VLAN MAC address
learning (where the VLAN-ID is a *key*).

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.

But to the best of my knowledge, no prior IETF document has
actually crossed this line. Which raises the need to clarify
the semantics of MAC-derived IPv6 addresses. Otherwise certain
network services might rely on these global addresses being
truly global and create problems.

For example, when I was working on CMTS (cable modem head
end equipment) the MAC addresses of the cable modems actually
were guaranteed to be unique. So if the same MAC address showed
up on a new frequency, or in a new location, it was either a 
clone or it indicated that the box had migrated (on frequency
and/or location). There was a need to determine which report
would be believed (generally the newer one) and to ignore or
remove the other.

That scenario obviously does not apply here, but could there
be others? Might a duplicate MAC address trigger a network
intrusion alert? Might a host assume that Link Local MAC X
for VLAN 3 and Link Local MAC X for VLAN 4 (where VLAN 3 and
VLAN 4 are on the same physical link) represent the same
device that has enabled itself for two VLANs?




Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0NLNZXX009054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 23 Jan 2007 13:23:35 -0800 (PST)
Received: from [127.0.0.1] (52.sub-75-214-95.myvzw.com [75.214.95.52]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l0NLFpXF020393; Tue, 23 Jan 2007 13:15:54 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 23 Jan 2007 13:15:50 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0D5CCC0E83A5306C133CD099"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-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: Tue, 23 Jan 2007 21:23:45 -0000
Status: RO
Content-Length: 2587

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0D5CCC0E83A5306C133CD099
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Caitlin Bestler wrote:
> A general comment, there are many paragraphs that appear
> to be written in English rather than IETF.
>=20
> Example:
>=20
>    Designated RBridge R1 can ensure freshness of its endnode informatio=
n
>    by doing ARP/ND queries periodically to ensure that the endnodes are=

>    actually there. This can be a problem if the endnodes are in power-
>    saver mode, and this should be a configuration parameter on R1 as to=

>    whether R1 should "ping" the endnodes by doing ARP/ND queries.
>=20
> My presumed translation:
>=20
> 	A Designate RBridge MUST be capable of ensuring freshness of its

I don't know if this needs to be a MUST or even a SHOULD. It seems more
like a MAY. Otherwise we're trying to make something that's much more
strict than a basic bridge box, which can similarly fail for silent nodes=
=2E

> 	endnode information using periodic ARP/ND queries. Because this
> 	can be a problem if the endnodes are in power-saver mode, there
> 	MUST be a configuration option to disable or control the

I'd say 'If available, there MUST be a configuration option..."

> frequency
> 	of these queries. These queries SHOULD be enabled by default.

Again, "Where available, this query capability SHOULD be enable by
default.".

> But I could see someone else reading it as:
>=20
> 	Designated RBridge R1 MAY esnure freshess of its endnode
> information
> 	by doing ARP/ND queries periodically to ensure that the endnodes
> 	are actually there. Because this can be a problem if the
> endnodes
> 	are in power-saver mode, there SHOULD be a configuration
> parameter
> 	on R1 to enable or disable these pings.

As I noted above, I would think that the first MAY would go with a
subsequent conditional MUST, which is not the same as a SHOULD.

Joe

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


--------------enig0D5CCC0E83A5306C133CD099
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFFtnsGE5f5cImnZrsRAlORAJ97Be/n27fODvZO6AZFESXtkpql3ACgkQPP
7AUK/GvTohiEKunQMAhGf3A=
=w3yI
-----END PGP SIGNATURE-----

--------------enig0D5CCC0E83A5306C133CD099--



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 l0NLCAob005692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 23 Jan 2007 13:12:10 -0800 (PST)
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 l0NLC3Zf020245; Tue, 23 Jan 2007 15:12:03 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 23 Jan 2007 15:12:03 -0600
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, 23 Jan 2007 15:12:01 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQAAODW0A=
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>
X-OriginalArrivalTime: 23 Jan 2007 21:12:03.0257 (UTC) FILETIME=[20FB4A90:01C73F33]
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 l0NLCAob005692
Cc: [e-mail]
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: Tue, 23 Jan 2007 21:12:15 -0000
Status: RO
Content-Length: 1589

Caitlin,

	Please see one comment in-line below...

--
Eric

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Caitlin Bestler
> Sent: Tuesday, January 23, 2007 2:23 PM
> To: [e-mail]
> Subject: [rbridge] Global MAC Addresses
> 
> Reading through draft-ietf-trill-rbridge-protocol-02 I can
> spot many places where it is assumed that a globally unique
> L2 identifier can only be formed by concatenating the VLAN ID
> and the MAC Address.
> 
> This may be a very realistic assessment, but it raises issues
> concerning global scope IPv6 addresses derived from the MAC
> Address.
> 
> Has the IETF addressed the issues of "global" MAC Addresses
> that are not global? In particular that IP routing should
> not be performed between two subnets that have different
> concepts of what a "global" MAC address is?
> 

This is not an issue.  IP Routers are L2 endstations at each
LAN attachment point and can have locally unique MAC addresses
in each LAN to which they are attached.  IP Routers (at least,
when acting as routers) don't transparently forward MAC frames
either.  Consequently, the MAC address (of an IP router) that
is visible on any LAN is a MAC address that is appropriate for 
that LAN.

Consequently, there is no reason why "IP routing should not be
performed between subnets that have different concepts of what
a 'global' MAC adress is"...

> 
> 
> _______________________________________________
> 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 l0NKW6SP024348 for <[e-mail]>; Tue, 23 Jan 2007 12:32:06 -0800 (PST)
Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Tue, 23 Jan 2007 12:31:42 -0800
X-Server-Uuid: D7CB97D3-6392-476F-BE46-AB3D6F515C9A
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 1DBD92AF; Tue, 23 Jan 2007 12:31: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 C90662AE for <[e-mail]>; Tue, 23 Jan 2007 12:31: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 EUX21937; Tue, 23 Jan 2007 12:31:41 -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 3B39020501 for <[e-mail]>; Tue, 23 Jan 2007 12:31:41 -0800 ( PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 23 Jan 2007 12:31:40 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-02.txt
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEsNrZA
From: "Caitlin Bestler" <[e-mail]>
To: [e-mail]
X-WSS-ID: 69A8AF243EK29075317-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 l0NKW6SP024348
Subject: Re: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-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: Tue, 23 Jan 2007 20:32:20 -0000
Status: RO
Content-Length: 1182

A general comment, there are many paragraphs that appear
to be written in English rather than IETF.

Example:

   Designated RBridge R1 can ensure freshness of its endnode information
   by doing ARP/ND queries periodically to ensure that the endnodes are
   actually there. This can be a problem if the endnodes are in power-
   saver mode, and this should be a configuration parameter on R1 as to
   whether R1 should "ping" the endnodes by doing ARP/ND queries.

My presumed translation:

	A Designate RBridge MUST be capable of ensuring freshness of its
	endnode information using periodic ARP/ND queries. Because this
	can be a problem if the endnodes are in power-saver mode, there
	MUST be a configuration option to disable or control the
frequency
	of these queries. These queries SHOULD be enabled by default.

But I could see someone else reading it as:

	Designated RBridge R1 MAY esnure freshess of its endnode
information
	by doing ARP/ND queries periodically to ensure that the endnodes
	are actually there. Because this can be a problem if the
endnodes
	are in power-saver mode, there SHOULD be a configuration
parameter
	on R1 to enable or disable these pings.







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 l0NJNqkd005334 for <[e-mail]>; Tue, 23 Jan 2007 11:23:54 -0800 (PST)
Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Tue, 23 Jan 2007 11:23:37 -0800
X-Server-Uuid: D7CB97D3-6392-476F-BE46-AB3D6F515C9A
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D84DA2B9; Tue, 23 Jan 2007 11:23:36 -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 923662BF for <[e-mail]>; Tue, 23 Jan 2007 11:23:36 -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 EUX05920; Tue, 23 Jan 2007 11:23:30 -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 EC81020501 for <[e-mail]>; Tue, 23 Jan 2007 11:23:29 -0800 ( PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 23 Jan 2007 11:23:28 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: Global MAC Addresses
Thread-Index: Acc6e3Rdo9f6m5sWR2Opx8QUaMKGyAEp+LfQ
From: "Caitlin Bestler" <[e-mail]>
To: [e-mail]
X-WSS-ID: 69A8BF333EK29049523-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 l0NJNqkd005334
Subject: [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: Tue, 23 Jan 2007 19:24:23 -0000
Status: RO
Content-Length: 557

Reading through draft-ietf-trill-rbridge-protocol-02 I can
spot many places where it is assumed that a globally unique
L2 identifier can only be formed by concatenating the VLAN ID
and the MAC Address.

This may be a very realistic assessment, but it raises issues
concerning global scope IPv6 addresses derived from the MAC
Address.

Has the IETF addressed the issues of "global" MAC Addresses
that are not global? In particular that IP routing should
not be performed between two subnets that have different
concepts of what a "global" MAC address is?





Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0HKo2JD022111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 17 Jan 2007 12:50:02 -0800 (PST)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 144A732A0E; Wed, 17 Jan 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7HjN-0004GY-Sp; Wed, 17 Jan 2007 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Wed, 17 Jan 2007 15:50:01 -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-rbridge-protocol-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: Wed, 17 Jan 2007 20:50:50 -0000
Status: RO
Content-Length: 3161

--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		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman, et al.
	Filename	: draft-ietf-trill-rbridge-protocol-02.txt
	Pages		: 25
	Date		: 2007-1-17
	
RBridges provide the ability to have an entire campus, with multiple
   physical links, look to IP like a single subnet. The design allows
   for zero configuration of switches within a campus, optimal pair-wise
   routing, safe forwarding even during periods of temporary loops, and
   the ability to cut down on ARP/ND traffic. The design also supports
   VLANs, and allows forwarding tables to be based on RBridge
   destinations (rather than endnode destinations), which allows
   internal routing tables to be substantially smaller than in
   conventional bridge systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-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-rbridge-protocol-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-rbridge-protocol-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-rbridge-protocol-02.txt

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

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


--OtherAccess--

--NextPart--


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 l0CFJUr0013378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 12 Jan 2007 07:19:30 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l0CFJTlw031529 for <[e-mail]>; Fri, 12 Jan 2007 09:19:29 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 12 Jan 2007 09:19:29 -0600
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, 12 Jan 2007 09:19:28 -0600
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Brief summary of feedback from the IEEE meeting
Thread-Index: Acc2XQzy628lQNosTySh8YT7zOLRng==
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 12 Jan 2007 15:19:29.0476 (UTC) FILETIME=[0DCD3840:01C7365D]
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 l0CFJUr0013378
Subject: [rbridge] Brief summary of feedback from the IEEE meeting
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, 12 Jan 2007 15:19:44 -0000
Status: RO
Content-Length: 3504

SUMMARY of IEEE Feedback on TRILL Architecture
==============================================

This is a brief summary of the verbal feedback we received from 
members of the IEEE 802.1 at the November meeting in Dallas.  I
am merely passing these on.  They are not representative of any 
formal feedback, there was no vote taken or call for objections
made, and they do not necessarily reflect my own opinion on any
particular aspect of the work in IEEE, or in the TRILL WG.

o	One point was to address all of the documents: the statement
 	that spanning tree protocol converges slowly, is inefficient
 	or otherwise defective requires more clarification.
 	o 	802.1s (MSTP) has been around since 2000 - and is now
 		part of 802.1Q.
 	o 	RSTP has a convergence time much quicker than appears
 		to have been considered in the problem statement draft.
		RSTP is now part of 802.1D (2004).
 	o 	The TRILL document set should be specific as to which
 		aspects of spanning tree "deficiencies" it will address
 		and how it will address them.

o 	Current bridging deployments take advantage of the STP root
 	election process to optimize the use of certain links in the
 	bridging topology.
 	o 	The specific scenario described is the "wiring closet"
 		problem outlined in the Architecture draft.
 	o 	The 802.1 group would like to point out that they feel
 		the TRILL solution will be dead on arrival if it does
 		not address this issue.
 	o 	The group does not consider replacing all wiring closet
 		equipment with RBridges as a valid approach to address
 		this issue.

o 	Several members of the group said that currently developing 
	802.1 protocols and enhancements must be considered in working 
	through the process of TRILL protocol definition.
 	o 	For example, there are issues with supporting BCN in the
 		use of tunneling technologies (specifically, how will an
	 	ingress RBridge ensure that a congestion notification is
 		delivered to the actual source).
 	o 	There was some discussion of BCN details (see below),
but
 		it will be important to have continuing dialogue (or
some
 		other form of interaction) going forward.
 	o 	There are several other issues with 802.1 enhancements
 		and/or extensions and issues with address transparency
 		that should be considered as well.

o 	Members of the group considers the intention of developing an 
	SPF-based approach (using a link-state routing protocol) - 
	particularly with intended plug-and-play capabilities - 
	commendable, but would prefer:
 	o 	the IETF consider sending routing experts to help the
 		IEEE with shortest path bridging using a link-state
 		routing protocol (replacing the current DVRP), or
 	o 	focus strictly on defining control plane mechanisms to
 		establish forwarding information for already existing -
 		and yet to be defined 802 encapsulation and data-plane
 		technologies.

In the brief discussion on the topic of BCN, one thing that came out
was that there is a need - and considerations in progress - to include
some part of an original data-frame as part of congestion notification
messages.  This could potentially address issues with "tunneled" MAC
frames - provided that the portion included is of sufficient length to
include at least the MAC DA/SA of the triggering frame.

There are no guarantees that this will happen, and it would be a very
good idea to track the development of BCN in IEEE 802.1 - assuming we
might want to support data-center applications using RBridges.

--
Eric Gray



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0A5m6mu005229 for <[e-mail]>; Tue, 9 Jan 2007 21:48:06 -0800 (PST)
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_01C7347A.E6755D16"
Date: Tue, 9 Jan 2007 21:48:00 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Trivial (I hope) 802 VLAN encoding question
Thread-Index: Accy0v3t943aIRRmQGmgYhWCTNkuSQBP2akgABVSjuAABMcNQA==
From: "Silvano Gai" <[e-mail]>
To: "Eastlake III Donald-LDE008" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question
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, 10 Jan 2007 05:48:34 -0000
Status: RO
Content-Length: 24759

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7347A.E6755D16
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I haven't seen a large use of Priority tagged frames,=20

But anyhow they are easy to deal with

=20

-- Silvano

=20

________________________________

From: Eastlake III Donald-LDE008 [mailto:[e-mail]]=20
Sent: Tuesday, January 09, 2007 7:36 PM
To: Silvano Gai; [e-mail]
Subject: RE: [rbridge] Trivial (I hope) 802 VLAN encoding question

=20

So presumably a "priority tagged frame" would normally be from an end
station that was trying to assert some priority but not claim a
particular VLAN. (Presumably you don't want to have to configure VLAN
IDs into end devices most of the time.)

=20

Donald

=20

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Tuesday, January 09, 2007 4:57 PM
To: Radia Perlman; [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question

=20

Radia,

=20

Inside a bridge ALL frames are VLAN tagged. The cases of NULL VLAN, VLAN
0 or no VLAN do not exist once the frame enters the bridge. These are
only link concepts.

=20

Each port has a Port_VLAN parameter that is assigned by management. On
many switches its default value is 1.

=20

When a port receives the frame it does the following:

=20

if (1Q tag exists)

{=20

   if (1Q.VID =3D=3D 0)

   {

      VLAN =3D Port_VLAN';  // Priority tagged frame

   }

   else

   {

      VLAN =3D 1Q.VID; // 1Q tagged frame

   }

}

else

{

   VLAN =3D Port_VLAN; // Untagged frame

}

=20

Therefore you can assume that any frame inside an RBridge has an inner
VLAN Tag.

=20

This is consistent with IEEE 802.1Q that states:

=20

VLAN technology introduces the following three basic types of frame:

a) Untagged frames;

b) Priority-tagged frames; and

c) VLAN-tagged frames.

=20

An untagged frame or a priority-tagged frame does not carry any

identification of the VLAN to which it belongs. Such frames are

classified as belonging to a particular VLAN based on parameters

associated with

the receiving Port, or, through proprietary extensions to IEEE 802.1Q

standard, based on the data content of the frame (e.g., MAC Address,

layer 3 protocol ID, etc.).

=20

A VLAN-tagged frame carries an explicit identification of the VLAN to

which it belongs; i.e., it carries a tag header that carries a non-null

VID. Such a frame is classified as belonging to a particular VLAN based

on the value of the VID that is included in the tag header. The presence

of the tag header carrying a non-null VID means that some other device,

either the originator of the frame or a VLAN-aware Bridge, has mapped

this frame into a VLAN and has inserted the appropriate VID.

=20

-- Silvano

=20

=20

> -----Original Message-----

> From: [e-mail] [mailto:[e-mail]]
On

> Behalf Of Radia Perlman

> Sent: Sunday, January 07, 2007 6:53 PM

> To: [e-mail]

> Subject: [rbridge] Trivial (I hope) 802 VLAN encoding question

>=20

> Is there a distinction between VLAN 0 and null VLAN? In other words,
if

> there is

> no VLAN tag, is that the same as being in VLAN 0?

>=20

> I'm trying to specify how to distinguish the per-VLAN instance of
IS-IS

> from the core instance.

> I was assuming it would be done based on an inner VLAN tag. But
suppose

> there were no VLANs,

> but you still wanted different instances for the endnode information
and

> the core information (so that

> truly inner guys wouldn't have to store all the endnode membership
link

> state information).

> You couldn't do that with a VLAN tag, unless you used VLAN tag with

> VLAN=3D0 for the endnoe

> membership instance.

>=20

> Not a really horrible problem -- we can certainly find a way of
encoding

> this, but just wondering if

> VLAN tag will work (where we use VLAN tag explicitly with VLAN =3D 0 =
to

> indicate the endnode

> membership inforamtion for the null VLAN?)

>=20

> Radia

>=20

> _______________________________________________

> rbridge mailing list

> [e-mail]

> http://mailman.postel.org/mailman/listinfo/rbridge


------_=_NextPart_001_01C7347A.E6755D16
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 77.95pt 72.0pt 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I haven&#8217;t seen a large use of
Priority tagged frames, <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>But anyhow they are easy to deal =
with<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>-- =
Silvano<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Eastlake III
Donald-LDE008 [mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, January =
09, 2007 7:36
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Silvano Gai;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [rbridge] =
Trivial (I
hope) 802 VLAN encoding question</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>So presumably a &quot;priority =
tagged
frame&quot; would normally be from an end station that was trying to =
assert
some priority but not claim a particular VLAN. (Presumably you don't =
want to
have to configure VLAN IDs into end devices most of the =
time.)</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Donald</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Silvano Gai<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, January =
09, 2007
4:57 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Radia Perlman;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] =
Trivial (I
hope) 802 VLAN encoding question</span></font><o:p></o:p></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Radia,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Inside a bridge ALL frames are VLAN tagged. The cases of NULL =
VLAN,
VLAN 0 or no VLAN do not exist once the frame enters the bridge. These =
are only
link concepts.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Each port has a Port_VLAN parameter that is assigned by =
management. On
many switches its default value is 1.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>When a port receives the frame it does the =
following:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>if (1Q tag exists)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>{ <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; if (1Q.VID =3D=3D 0)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; {<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VLAN =3D Port_VLAN';&nbsp; // =
Priority
tagged frame<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; }<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; else<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; {<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VLAN =3D 1Q.VID; // 1Q tagged =
frame<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; }<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>}<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>else<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>{<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; VLAN =3D Port_VLAN; // Untagged =
frame<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>}<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Therefore you can assume that any frame inside an RBridge has an =
inner
VLAN Tag.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>This is consistent with IEEE 802.1Q that =
states:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>VLAN technology introduces the following three basic types of =
frame:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a) Untagged frames;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>b) Priority-tagged frames; and<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>c) VLAN-tagged frames.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>An untagged frame or a priority-tagged frame does not carry =
any<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>identification of the VLAN to which it belongs. Such frames =
are<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>classified as belonging to a particular VLAN based on =
parameters<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>associated with<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>the receiving Port, or, through proprietary extensions to IEEE =
802.1Q<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>standard, based on the data content of the frame (e.g., MAC =
Address,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>layer 3 protocol ID, etc.).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>A VLAN-tagged frame carries an explicit identification of the =
VLAN to<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>which it belongs; i.e., it carries a tag header that carries a =
non-null<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>VID. Such a frame is classified as belonging to a particular =
VLAN based<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>on the value of the VID that is included in the tag header. The
presence<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>of the tag header carrying a non-null VID means that some other =
device,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>either the originator of the frame or a <st1:place =
w:st=3D"on"><st1:PlaceName
 w:st=3D"on">VLAN-aware</st1:PlaceName> <st1:PlaceType =
w:st=3D"on">Bridge</st1:PlaceType></st1:place>,
has mapped<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>this frame into a VLAN and has inserted the appropriate =
VID.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>-- Silvano<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; -----Original Message-----<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; From: [e-mail]
[mailto:[e-mail]] On<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Behalf Of Radia Perlman<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Sent: Sunday, January 07, 2007 6:53 =
PM<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; To: [e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Subject: [rbridge] Trivial (I hope) 802 VLAN encoding =
question<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Is there a distinction between VLAN 0 and null VLAN? In =
other
words, if<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; there is<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; no VLAN tag, is that the same as being in VLAN =
0?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; I'm trying to specify how to distinguish the per-VLAN =
instance of
IS-IS<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; from the core instance.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; I was assuming it would be done based on an inner VLAN tag. =
But
suppose<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; there were no VLANs,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; but you still wanted different instances for the endnode
information and<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; the core information (so that<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; truly inner guys wouldn't have to store all the endnode =
membership
link<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; state information).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; You couldn't do that with a VLAN tag, unless you used VLAN =
tag
with<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; VLAN=3D0 for the endnoe<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; membership instance.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Not a really horrible problem -- we can certainly find a =
way of
encoding<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; this, but just wondering if<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; VLAN tag will work (where we use VLAN tag explicitly with =
VLAN =3D 0
to<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; indicate the endnode<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; membership inforamtion for the null =
VLAN?)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Radia<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
_______________________________________________<o:p></o:p></span></font><=
/p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; rbridge mailing list<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; [e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
http://mailman.postel.org/mailman/listinfo/rbridge<o:p></o:p></span></fon=
t></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C7347A.E6755D16--


Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0A5Vxk5029151 for <[e-mail]>; Tue, 9 Jan 2007 21:31:59 -0800 (PST)
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga09.intel.com with ESMTP; 09 Jan 2007 21:31:54 -0800
Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga002.fm.intel.com with ESMTP; 09 Jan 2007 21:31:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.13,165,1167638400";  d="scan'208"; a="34673013:sNHT44495775"
Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 9 Jan 2007 21:31:05 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 9 Jan 2007 21:31:05 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Trivial (I hope) 802 VLAN encoding question
Thread-Index: Accy0v3t943aIRRmQGmgYhWCTNkuSQBP2akgABVSjuAABDXLtQ==
From: "Wadekar, Manoj K" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 10 Jan 2007 05:31:05.0811 (UTC) FILETIME=[8659F230:01C73478]
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 l0A5Vxk5029151
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question
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, 10 Jan 2007 05:32:37 -0000
Status: RO
Content-Length: 4213

Many of the NICs these days have capability to add VLAN tag. Especially for virtualized environmnts - end points may send packets with different VLAN ID (from guest OS's belonging to different VLANs)

Thanks,
Manoj

Sent from my GoodLink synchronized handheld (www.good.com)


 -----Original Message-----
From: 	Eastlake III Donald-LDE008 [mailto:[e-mail]]
Sent:	Tuesday, January 09, 2007 08:03 PM Pacific Standard Time
To:	Silvano Gai; [e-mail]
Subject:	Re: [rbridge] Trivial (I hope) 802 VLAN encoding question

So presumably a "priority tagged frame" would normally be from an end
station that was trying to assert some priority but not claim a
particular VLAN. (Presumably you don't want to have to configure VLAN
IDs into end devices most of the time.)
 
Donald

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Tuesday, January 09, 2007 4:57 PM
To: Radia Perlman; [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question



 

Radia,

 

Inside a bridge ALL frames are VLAN tagged. The cases of NULL VLAN, VLAN
0 or no VLAN do not exist once the frame enters the bridge. These are
only link concepts.

 

Each port has a Port_VLAN parameter that is assigned by management. On
many switches its default value is 1.

 

When a port receives the frame it does the following:

 

if (1Q tag exists)

{ 

   if (1Q.VID == 0)

   {

      VLAN = Port_VLAN';  // Priority tagged frame

   }

   else

   {

      VLAN = 1Q.VID; // 1Q tagged frame

   }

}

else

{

   VLAN = Port_VLAN; // Untagged frame

}

 

Therefore you can assume that any frame inside an RBridge has an inner
VLAN Tag.

 

This is consistent with IEEE 802.1Q that states:

 

VLAN technology introduces the following three basic types of frame:

a) Untagged frames;

b) Priority-tagged frames; and

c) VLAN-tagged frames.

 

An untagged frame or a priority-tagged frame does not carry any

identification of the VLAN to which it belongs. Such frames are

classified as belonging to a particular VLAN based on parameters

associated with

the receiving Port, or, through proprietary extensions to IEEE 802.1Q

standard, based on the data content of the frame (e.g., MAC Address,

layer 3 protocol ID, etc.).

 

A VLAN-tagged frame carries an explicit identification of the VLAN to

which it belongs; i.e., it carries a tag header that carries a non-null

VID. Such a frame is classified as belonging to a particular VLAN based

on the value of the VID that is included in the tag header. The presence

of the tag header carrying a non-null VID means that some other device,

either the originator of the frame or a VLAN-aware Bridge, has mapped

this frame into a VLAN and has inserted the appropriate VID.

 

-- Silvano

 

 

> -----Original Message-----

> From: [e-mail] [mailto:[e-mail]]
On

> Behalf Of Radia Perlman

> Sent: Sunday, January 07, 2007 6:53 PM

> To: [e-mail]

> Subject: [rbridge] Trivial (I hope) 802 VLAN encoding question

> 

> Is there a distinction between VLAN 0 and null VLAN? In other words,
if

> there is

> no VLAN tag, is that the same as being in VLAN 0?

> 

> I'm trying to specify how to distinguish the per-VLAN instance of
IS-IS

> from the core instance.

> I was assuming it would be done based on an inner VLAN tag. But
suppose

> there were no VLANs,

> but you still wanted different instances for the endnode information
and

> the core information (so that

> truly inner guys wouldn't have to store all the endnode membership
link

> state information).

> You couldn't do that with a VLAN tag, unless you used VLAN tag with

> VLAN=0 for the endnoe

> membership instance.

> 

> Not a really horrible problem -- we can certainly find a way of
encoding

> this, but just wondering if

> VLAN tag will work (where we use VLAN tag explicitly with VLAN = 0 to

> indicate the endnode

> membership inforamtion for the null VLAN?)

> 

> Radia

> 

> _______________________________________________

> rbridge mailing list

> [e-mail]

> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l0A3ZiNH004664 for <[e-mail]>; Tue, 9 Jan 2007 19:35:44 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-4.tower-119.messagelabs.com!1168400142!12018276!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 5383 invoked from network); 10 Jan 2007 03:35:42 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 10 Jan 2007 03:35:42 -0000
Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0A3ZfPU011130 for <[e-mail]>; Tue, 9 Jan 2007 20:35:42 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l0A3Zeba025066 for <[e-mail]>; Tue, 9 Jan 2007 21:35:41 -0600 (CST)
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_01C73468.665B6AA0"
Date: Tue, 9 Jan 2007 22:35:38 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Trivial (I hope) 802 VLAN encoding question
Thread-Index: Accy0v3t943aIRRmQGmgYhWCTNkuSQBP2akgABVSjuA=
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question
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, 10 Jan 2007 03:36:16 -0000
Status: RO
Content-Length: 21212

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73468.665B6AA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

So presumably a "priority tagged frame" would normally be from an end
station that was trying to assert some priority but not claim a
particular VLAN. (Presumably you don't want to have to configure VLAN
IDs into end devices most of the time.)
=20
Donald

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Silvano Gai
Sent: Tuesday, January 09, 2007 4:57 PM
To: Radia Perlman; [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question



=20

Radia,

=20

Inside a bridge ALL frames are VLAN tagged. The cases of NULL VLAN, VLAN
0 or no VLAN do not exist once the frame enters the bridge. These are
only link concepts.

=20

Each port has a Port_VLAN parameter that is assigned by management. On
many switches its default value is 1.

=20

When a port receives the frame it does the following:

=20

if (1Q tag exists)

{=20

   if (1Q.VID =3D=3D 0)

   {

      VLAN =3D Port_VLAN';  // Priority tagged frame

   }

   else

   {

      VLAN =3D 1Q.VID; // 1Q tagged frame

   }

}

else

{

   VLAN =3D Port_VLAN; // Untagged frame

}

=20

Therefore you can assume that any frame inside an RBridge has an inner
VLAN Tag.

=20

This is consistent with IEEE 802.1Q that states:

=20

VLAN technology introduces the following three basic types of frame:

a) Untagged frames;

b) Priority-tagged frames; and

c) VLAN-tagged frames.

=20

An untagged frame or a priority-tagged frame does not carry any

identification of the VLAN to which it belongs. Such frames are

classified as belonging to a particular VLAN based on parameters

associated with

the receiving Port, or, through proprietary extensions to IEEE 802.1Q

standard, based on the data content of the frame (e.g., MAC Address,

layer 3 protocol ID, etc.).

=20

A VLAN-tagged frame carries an explicit identification of the VLAN to

which it belongs; i.e., it carries a tag header that carries a non-null

VID. Such a frame is classified as belonging to a particular VLAN based

on the value of the VID that is included in the tag header. The presence

of the tag header carrying a non-null VID means that some other device,

either the originator of the frame or a VLAN-aware Bridge, has mapped

this frame into a VLAN and has inserted the appropriate VID.

=20

-- Silvano

=20

=20

> -----Original Message-----

> From: [e-mail] [mailto:[e-mail]]
On

> Behalf Of Radia Perlman

> Sent: Sunday, January 07, 2007 6:53 PM

> To: [e-mail]

> Subject: [rbridge] Trivial (I hope) 802 VLAN encoding question

>=20

> Is there a distinction between VLAN 0 and null VLAN? In other words,
if

> there is

> no VLAN tag, is that the same as being in VLAN 0?

>=20

> I'm trying to specify how to distinguish the per-VLAN instance of
IS-IS

> from the core instance.

> I was assuming it would be done based on an inner VLAN tag. But
suppose

> there were no VLANs,

> but you still wanted different instances for the endnode information
and

> the core information (so that

> truly inner guys wouldn't have to store all the endnode membership
link

> state information).

> You couldn't do that with a VLAN tag, unless you used VLAN tag with

> VLAN=3D0 for the endnoe

> membership instance.

>=20

> Not a really horrible problem -- we can certainly find a way of
encoding

> this, but just wondering if

> VLAN tag will work (where we use VLAN tag explicitly with VLAN =3D 0 =
to

> indicate the endnode

> membership inforamtion for the null VLAN?)

>=20

> Radia

>=20

> _______________________________________________

> rbridge mailing list

> [e-mail]

> http://mailman.postel.org/mailman/listinfo/rbridge


------_=_NextPart_001_01C73468.665B6AA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR><o:SmartTagType =

name=3D"PlaceType"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"PlaceName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 77.95pt =
72.0pt 77.95pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0pt; FONT-FAMILY: "Courier New"
}
LI.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0pt; FONT-FAMILY: "Courier New"
}
DIV.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0pt; FONT-FAMILY: "Courier New"
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D226323003-10012007>So presumably a "priority tagged frame" would =
normally=20
be from an end station that was trying to assert some priority but not =
claim a=20
particular VLAN. (Presumably you don't want to have to configure VLAN =
IDs into=20
end devices most of the time.)</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D226323003-10012007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D226323003-10012007>Donald</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>Silvano=20
Gai<BR><B>Sent:</B> Tuesday, January 09, 2007 4:57 PM<BR><B>To:</B> =
Radia=20
Perlman; [e-mail]<BR><B>Subject:</B> Re: [rbridge] Trivial (I =
hope)=20
802 VLAN encoding question<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Radia,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Inside a bridge ALL frames are VLAN tagged. =
The cases of=20
NULL VLAN, VLAN 0 or no VLAN do not exist once the frame enters the =
bridge.=20
These are only link concepts.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Each port has a Port_VLAN parameter that is =
assigned by=20
management. On many switches its default value is=20
1.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">When a port receives the frame it does the=20
following:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">if (1Q tag =
exists)<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">{ <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; if (1Q.VID =3D=3D=20
0)<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; {<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VLAN =3D =
Port_VLAN';&nbsp;=20
// Priority tagged frame<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; }<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; else<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; {<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VLAN =3D =
1Q.VID; // 1Q=20
tagged frame<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; }<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">}<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">else<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">{<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; VLAN =3D Port_VLAN; // Untagged=20
frame<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">}<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Therefore you can assume that any frame inside =
an=20
RBridge has an inner VLAN Tag.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">This is consistent with IEEE 802.1Q that=20
states:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">VLAN technology introduces the following three =
basic=20
types of frame:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">a) Untagged =
frames;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">b) Priority-tagged frames;=20
and<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">c) VLAN-tagged =
frames.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">An untagged frame or a priority-tagged frame =
does not=20
carry any<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">identification of the VLAN to which it =
belongs. Such=20
frames are<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">classified as belonging to a particular VLAN =
based on=20
parameters<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">associated with<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">the receiving Port, or, through proprietary =
extensions=20
to IEEE 802.1Q<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">standard, based on the data content of the =
frame (e.g.,=20
MAC Address,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">layer 3 protocol ID, =
etc.).<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">A VLAN-tagged frame carries an explicit =
identification=20
of the VLAN to<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">which it belongs; i.e., it carries a tag =
header that=20
carries a non-null<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">VID. Such a frame is classified as belonging =
to a=20
particular VLAN based<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">on the value of the VID that is included in =
the tag=20
header. The presence<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">of the tag header carrying a non-null VID =
means that=20
some other device,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">either the originator of the frame or a =
<st1:place=20
w:st=3D"on"><st1:PlaceName w:st=3D"on">VLAN-aware</st1:PlaceName> =
<st1:PlaceType=20
w:st=3D"on">Bridge</st1:PlaceType></st1:place>, has=20
mapped<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">this frame into a VLAN and has inserted the =
appropriate=20
VID.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">-- Silvano<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; -----Original =
Message-----</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; From: [e-mail]=20
[mailto:[e-mail]] On</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Behalf Of Radia Perlman</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Sent: Sunday, January 07, 2007 6:53=20
PM</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; To: [e-mail]</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Subject: [rbridge] Trivial (I hope) 802 =
VLAN=20
encoding question</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Is there a distinction between VLAN 0 and =
null=20
VLAN? In other words, if</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; there is</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; no VLAN tag, is that the same as being in =
VLAN=20
0?</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; I'm trying to specify how to distinguish =
the=20
per-VLAN instance of IS-IS</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; from the core instance.</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; I was assuming it would be done based on =
an inner=20
VLAN tag. But suppose</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; there were no VLANs,</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; but you still wanted different instances =
for the=20
endnode information and</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; the core information (so =
that</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; truly inner guys wouldn't have to store =
all the=20
endnode membership link</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; state information).</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; You couldn't do that with a VLAN tag, =
unless you=20
used VLAN tag with</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; VLAN=3D0 for the endnoe</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; membership instance.</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Not a really horrible problem -- we can =
certainly=20
find a way of encoding</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; this, but just wondering =
if</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; VLAN tag will work (where we use VLAN tag =

explicitly with VLAN =3D 0 to</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; indicate the endnode</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; membership inforamtion for the null=20
VLAN?)</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Radia</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt;=20
_______________________________________________</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; rbridge mailing list</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; [e-mail]</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt;=20
http://mailman.postel.org/mailman/listinfo/rbridge</SPAN></FONT></P></DIV=
></BODY></HTML>

------_=_NextPart_001_01C73468.665B6AA0--


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l09Lv5oq005331 for <[e-mail]>; Tue, 9 Jan 2007 13:57:05 -0800 (PST)
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_01C73439.19EC871A"
Date: Tue, 9 Jan 2007 13:57:05 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Trivial (I hope) 802 VLAN encoding question
Thread-Index: Accy0v3t943aIRRmQGmgYhWCTNkuSQBP2akg
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question
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, 09 Jan 2007 21:57:59 -0000
Status: RO
Content-Length: 19231

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73439.19EC871A
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20

Radia,

=20

Inside a bridge ALL frames are VLAN tagged. The cases of NULL VLAN, VLAN
0 or no VLAN do not exist once the frame enters the bridge. These are
only link concepts.

=20

Each port has a Port_VLAN parameter that is assigned by management. On
many switches its default value is 1.

=20

When a port receives the frame it does the following:

=20

if (1Q tag exists)

{=20

   if (1Q.VID =3D=3D 0)

   {

      VLAN =3D Port_VLAN';  // Priority tagged frame

   }

   else

   {

      VLAN =3D 1Q.VID; // 1Q tagged frame

   }

}

else

{

   VLAN =3D Port_VLAN; // Untagged frame

}

=20

Therefore you can assume that any frame inside an RBridge has an inner
VLAN Tag.

=20

This is consistent with IEEE 802.1Q that states:

=20

VLAN technology introduces the following three basic types of frame:

a) Untagged frames;

b) Priority-tagged frames; and

c) VLAN-tagged frames.

=20

An untagged frame or a priority-tagged frame does not carry any

identification of the VLAN to which it belongs. Such frames are

classified as belonging to a particular VLAN based on parameters

associated with

the receiving Port, or, through proprietary extensions to IEEE 802.1Q

standard, based on the data content of the frame (e.g., MAC Address,

layer 3 protocol ID, etc.).

=20

A VLAN-tagged frame carries an explicit identification of the VLAN to

which it belongs; i.e., it carries a tag header that carries a non-null

VID. Such a frame is classified as belonging to a particular VLAN based

on the value of the VID that is included in the tag header. The presence

of the tag header carrying a non-null VID means that some other device,

either the originator of the frame or a VLAN-aware Bridge, has mapped

this frame into a VLAN and has inserted the appropriate VID.

=20

-- Silvano

=20

=20

> -----Original Message-----

> From: [e-mail] [mailto:[e-mail]]
On

> Behalf Of Radia Perlman

> Sent: Sunday, January 07, 2007 6:53 PM

> To: [e-mail]

> Subject: [rbridge] Trivial (I hope) 802 VLAN encoding question

>=20

> Is there a distinction between VLAN 0 and null VLAN? In other words,
if

> there is

> no VLAN tag, is that the same as being in VLAN 0?

>=20

> I'm trying to specify how to distinguish the per-VLAN instance of
IS-IS

> from the core instance.

> I was assuming it would be done based on an inner VLAN tag. But
suppose

> there were no VLANs,

> but you still wanted different instances for the endnode information
and

> the core information (so that

> truly inner guys wouldn't have to store all the endnode membership
link

> state information).

> You couldn't do that with a VLAN tag, unless you used VLAN tag with

> VLAN=3D0 for the endnoe

> membership instance.

>=20

> Not a really horrible problem -- we can certainly find a way of
encoding

> this, but just wondering if

> VLAN tag will work (where we use VLAN tag explicitly with VLAN =3D 0 =
to

> indicate the endnode

> membership inforamtion for the null VLAN?)

>=20

> Radia

>=20

> _______________________________________________

> rbridge mailing list

> [e-mail]

> http://mailman.postel.org/mailman/listinfo/rbridge


------_=_NextPart_001_01C73439.19EC871A
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 77.95pt 72.0pt 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Radia,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Inside a bridge ALL frames are VLAN tagged. The cases of NULL =
VLAN,
VLAN 0 or no VLAN do not exist once the frame enters the bridge. These =
are only
link concepts.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Each port has a Port_VLAN parameter that is assigned by =
management. On
many switches its default value is 1.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>When a port receives the frame it does the =
following:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>if (1Q tag exists)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>{ <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; if (1Q.VID =3D=3D 0)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; {<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VLAN =3D Port_VLAN';&nbsp; // =
Priority
tagged frame<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; }<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; else<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; {<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VLAN =3D 1Q.VID; // 1Q tagged =
frame<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; }<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>}<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>else<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>{<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; VLAN =3D Port_VLAN; // Untagged =
frame<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>}<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Therefore you can assume that any frame inside an RBridge has an =
inner
VLAN Tag.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>This is consistent with IEEE 802.1Q that =
states:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>VLAN technology introduces the following three basic types of =
frame:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a) Untagged frames;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>b) Priority-tagged frames; and<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>c) VLAN-tagged frames.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>An untagged frame or a priority-tagged frame does not carry =
any<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>identification of the VLAN to which it belongs. Such frames =
are<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>classified as belonging to a particular VLAN based on =
parameters<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>associated with<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>the receiving Port, or, through proprietary extensions to IEEE =
802.1Q<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>standard, based on the data content of the frame (e.g., MAC =
Address,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>layer 3 protocol ID, etc.).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>A VLAN-tagged frame carries an explicit identification of the =
VLAN to<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>which it belongs; i.e., it carries a tag header that carries a =
non-null<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>VID. Such a frame is classified as belonging to a particular =
VLAN based<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>on the value of the VID that is included in the tag header. The
presence<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>of the tag header carrying a non-null VID means that some other =
device,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>either the originator of the frame or a <st1:place =
w:st=3D"on"><st1:PlaceName
 w:st=3D"on">VLAN-aware</st1:PlaceName> <st1:PlaceType =
w:st=3D"on">Bridge</st1:PlaceType></st1:place>,
has mapped<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>this frame into a VLAN and has inserted the appropriate =
VID.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>-- Silvano<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; -----Original Message-----</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; From: [e-mail]
[mailto:[e-mail]] On</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Behalf Of Radia Perlman</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Sent: Sunday, January 07, 2007 6:53 PM</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; To: [e-mail]</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Subject: [rbridge] Trivial (I hope) 802 VLAN encoding =
question</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Is there a distinction between VLAN 0 and null VLAN? In =
other
words, if</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; there is</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; no VLAN tag, is that the same as being in VLAN =
0?</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; I'm trying to specify how to distinguish the per-VLAN =
instance of
IS-IS</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; from the core instance.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; I was assuming it would be done based on an inner VLAN tag. =
But
suppose</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; there were no VLANs,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; but you still wanted different instances for the endnode
information and</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; the core information (so that</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; truly inner guys wouldn't have to store all the endnode =
membership
link</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; state information).</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; You couldn't do that with a VLAN tag, unless you used VLAN =
tag
with</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; VLAN=3D0 for the endnoe</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; membership instance.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Not a really horrible problem -- we can certainly find a =
way of
encoding</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; this, but just wondering if</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; VLAN tag will work (where we use VLAN tag explicitly with =
VLAN =3D 0
to</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; indicate the endnode</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; membership inforamtion for the null =
VLAN?)</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Radia</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
_______________________________________________</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; rbridge mailing list</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; [e-mail]</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
http://mailman.postel.org/mailman/listinfo/rbridge</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C73439.19EC871A--


Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l09HZ6Mp017464 for <[e-mail]>; Tue, 9 Jan 2007 09:35:06 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-119.messagelabs.com!1168364105!8262655!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 6547 invoked from network); 9 Jan 2007 17:35:05 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 9 Jan 2007 17:35:05 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l09HZ054008697 for <[e-mail]>; Tue, 9 Jan 2007 10:35:04 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l09HZ0H0012815 for <[e-mail]>; Tue, 9 Jan 2007 11:35:00 -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: Tue, 9 Jan 2007 12:34:59 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-trill-routing-reqs-01.txt
Thread-Index: Acc0FHyLswv3rNsqRZuzX7IBn4f74w==
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 l09HZ6Mp017464
Subject: [rbridge] draft-ietf-trill-routing-reqs-01.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: Tue, 09 Jan 2007 17:35:21 -0000
Status: RO
Content-Length: 154

A new version of the Routing Requirements draft is available at

ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-01.txt

Thanks,
Donald



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l09FUbQQ009170 for <[e-mail]>; Tue, 9 Jan 2007 07:30:38 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-119.messagelabs.com!1168356636!6503029!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 29888 invoked from network); 9 Jan 2007 15:30:36 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 9 Jan 2007 15:30:36 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l09FUa1L028807 for <[e-mail]>; Tue, 9 Jan 2007 08:30:36 -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 l09FUaLF027938 for <[e-mail]>; Tue, 9 Jan 2007 09:30:36 -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: Tue, 9 Jan 2007 10:30:34 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Trivial (I hope) 802 VLAN encoding question
Thread-Index: Acczh/YqnIM3GlirTUKXekLBnb2LtgAed2LA
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: "Radia Perlman" <[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 l09FUbQQ009170
Cc: [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question
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, 09 Jan 2007 15:31:24 -0000
Status: RO
Content-Length: 1681

Well, I may be confused and don't claim to thoroughly understand all
this, but it seems to me there are three cases:

(1) You can have a frame with no Q/VLAN tag at all. Obviously, in some
sense, this has the "null" VLAN.

(2) You can have a frame with a Q/VLAN tag that, in some sense, only
specifies priority. This is indicated by setting the VLAN tag to zero.
According to the table on page 76 of IEEE 802.1Q-2005, there are three
"special" VLAN tag values. That table states that zero is "The null VLAN
ID." and indicates that the tag has only priority information. The other
special values are one, which is the default VLAN ID if not configured
otherwise, and 0xFFF which is "reserved for implementation use".

(3) You can have a frame with a Q/VLAN tag that provides both priority
and VLAN ID. Such a tag would have a VLAN tag in the inclusive range of
0x001 to 0xFFE.

[(4) You can not have a Q/VLAN tag the provides only a VLAN ID. If such
a tag is present, then whatever the value in the three bit priority
field is always specifies a priority for the frame.]

Donald

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Joe Touch
Sent: Monday, January 08, 2007 7:12 PM
To: Radia Perlman
Cc: [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question



Radia Perlman wrote:
> Is there a distinction between VLAN 0 and null VLAN? In other words, 
> if there is no VLAN tag, is that the same as being in VLAN 0?

VLAN 0 is special; it means "priority-tagged".

Null VLAN is different.

--
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment




Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l09EjU5Z026170 for <[e-mail]>; Tue, 9 Jan 2007 06:45:30 -0800 (PST)
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Jan 2007 06:45:31 -0800
X-IronPort-AV: i="4.13,163,1167638400";  d="scan'208"; a="50288220:sNHT43534228"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l09EjUiR007475;  Tue, 9 Jan 2007 09:45:30 -0500
Received: from [64.102.48.214] (dhcp-64-102-48-214.cisco.com [64.102.48.214]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l09EjT2k014851; Tue, 9 Jan 2007 09:45:29 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 09 Jan 2007 09:45:28 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1124; t=1168353930; x=1169217930; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20IP=20Multicast=20groups/=20layer=202=20or =20layer=203? |Sender:=20 |To:=20Radia=20Perlman=20<[e-mail]>; bh=1+8DdGPAaxfv4AyK20xib7bUfn39WPQeO6yL2WUAPQs=; b=CajEB0jiBxRSYuZsyFXkOo5Ru6aTKXwCZyLlE328uq2UNvOWTxo48OIYAa3jqGwQPWO/awVt lO87BX72ATQAnhtdR5xvF9ZTUiU0h2mcM95BUrTLNHkFBIEBNK8UZFo7;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IP Multicast groups/ layer 2 or layer 3?
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, 09 Jan 2007 14:45:57 -0000
Status: RO
Content-Length: 1113

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


It seems like since we're really focusing on l2, we should just
advertise l2 addresses.

:-)

Russ

Radia Perlman wrote:
> When an RBridge  R announces via IS-IS which IP multicast groups are  
> reachable on R's directly
> attached links, should the groups be layer 3 or layer 2 addresses?
> 
> If it's layer 3, then there will have to be separate announcements for 
> IPv4 and IPv6 groups.
> If it's layer 2, then 32 IPv4 groups would map to the same layer 2 
> multicast address (and I'm
> not sure what it is for IPv6).
> 
> I don't care. The spec currently says layer 2, but there is a question 
> in the spec asking if that's what
> we really want.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFo6qIER27sUhU9OQRAiZQAKCLi6suQ+vXvIyfn/vvWqK1ujzTkgCg6kz/
Avd7K0OdHDCb2/XIMfDcxMM=
=7y5a
-----END PGP SIGNATURE-----


Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l09EgIYZ025389 for <[e-mail]>; Tue, 9 Jan 2007 06:42:18 -0800 (PST)
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Jan 2007 06:42:18 -0800
X-IronPort-AV: i="4.13,163,1167638400";  d="scan'208"; a="50287895:sNHT52448392"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l09EgHJX005997;  Tue, 9 Jan 2007 09:42:17 -0500
Received: from [64.102.48.214] (dhcp-64-102-48-214.cisco.com [64.102.48.214]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l09EgH7f007382; Tue, 9 Jan 2007 09:42:17 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 09 Jan 2007 09:42:15 -0500
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1670; t=1168353737; x=1169217737; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20IS-IS=20pseudonodes, =20nicknames, =20and=2 0rooted=20trees |Sender:=20 |To:=20Radia=20Perlman=20<[e-mail]>; bh=CyQdUect14T5g6wloA+wmMMJzOmhp4uxEV2xy+d36a0=; b=xsYW6/ihM6vXw61pzdhHZqqb259YEZwKty4uYvvtm+ZRWX9hImhqH2woKh6g0RPqglBG7jox ZKW2zxkQ0gUmaysu4ViqPNG27lpKbZyGeJwInJWT6nEwh3ODrgYjfvUl;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IS-IS pseudonodes, nicknames, and rooted trees
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, 09 Jan 2007 14:42:49 -0000
Status: RO
Content-Length: 1651

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


> For RBridges, I think the answer to my question is that it does not 
> matter -- I *think* the same
> tree would be calculated whether you chose as root the pseudonode or the 
> DR. So it's probably better
> to say that pseudonodes do not request nicknames, and cannot be 
> specified as the root of trees,
> and would never appear as the ingress or egress RBridge. I don't think 
> it matters whether the
> endnode information appears to be advertised by the DR or the 
> pseudonode. I think we can let the IS-IS
> people decide that detail.

I would agree with this. The main issue we might have is how to handle
the pnode advertisement by the DIS. I think this is okay, the
connections are all still there:

A---A'---B---C

If A' is the pnode, and A is the DIS, then A will be advertising:

o An LSP with it's own information, including its nickname and ID
o An LSP with the information form A', which would not include
 a nickname

When C calculates its SPT, I assume that it will build the the link from
B--A', and A'--A, but without A' having a nickname, will this work? I
think it will, just wanted to think it through to make certain. The next
hop towards some destination, for B, could be A, but the local tree
shows this as through A', which should resolve in the forwarding table
down to the next hop A, just as it works today.

:-)

Russ


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

iD8DBQFFo6nHER27sUhU9OQRAk4xAJ9eIma4KEKc2lCuSqoV7hJotwsfDACg7WX1
6Gp2uiB/usRhMjZsdcIQxOE=
=roMg
-----END PGP SIGNATURE-----


Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l09Bn6V3010847 for <[e-mail]>; Tue, 9 Jan 2007 03:49:06 -0800 (PST)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jan 2007 12:49:06 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l09Bn5Bn001997 for <[e-mail]>; Tue, 9 Jan 2007 12:49:05 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l09Bn5dB013704 for <[e-mail]>; Tue, 9 Jan 2007 12:49:05 +0100 (MET)
Received: from mshand-wxp.cisco.com (dhcp-gpk02-vlan300-64-103-64-225.cisco.com [64.103.64.225]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA08254; Tue, 9 Jan 2007 11:37:10 GMT
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Tue, 09 Jan 2007 11:36:47 +0000
To: Radia Perlman <[e-mail]>
From: mike shand <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1019; t=1168343345; x=1169207345; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20mike=20shand=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20IS-IS=20pseudonodes, =20nicknames, =20and=2 0rooted=20trees |Sender:=20; bh=KicZ3n9NioT/YG67liovzgWnuxb3radbw0WmS7Ed1w0=; b=f+D6AIaOy/DgzZ1d2o6YdLePG7hivylmKY5orEnFJple1Az1UoViOUVnZZraQtUhoJgyLCYA m8LACx8A1zGxGKjvIG2K6rEYI2r9OnA2DJBXY8Zf6jrRw+bM8LnVCz4Y;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] IS-IS pseudonodes, nicknames, and rooted trees
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, 09 Jan 2007 11:49:11 -0000
Status: RO
Content-Length: 992

At 05:26 09/01/2007, Radia Perlman wrote:
>For RBridges, I think the answer to my question is that it does not
>matter -- I *think* the same
>tree would be calculated whether you chose as root the pseudonode or the
>DR.

I don't think that is true. Since the cost from the DR to the 
pseudonode is non-zero (although the cost from the pseudonode to the 
DR is zero), I think you could end up with a different tree depending 
on which is root. Of course in normal IS-IS you would never make the 
pseudonode the root, so the issue doesn't arise.

But I don't think it matters, since I agree with what you say below.

         Mike


>So it's probably better
>to say that pseudonodes do not request nicknames, and cannot be
>specified as the root of trees,
>and would never appear as the ingress or egress RBridge. I don't think
>it matters whether the
>endnode information appears to be advertised by the DR or the
>pseudonode. I think we can let the IS-IS
>people decide that detail.
>
>Radia


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 l095QMhn005771 for <[e-mail]>; Mon, 8 Jan 2007 21:26:22 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.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]; Mon, 08 Jan 2007 21:26:21 -0800 (PST)
Received: from sun.com ([129.150.29.110]) 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]; Mon, 08 Jan 2007 21:26:21 -0800 (PST)
Date: Mon, 08 Jan 2007 21:26:25 -0800
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=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] IS-IS pseudonodes, nicknames, and rooted trees
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, 09 Jan 2007 05:26:38 -0000
Status: RO
Content-Length: 3637

Pseudonodes aren't quite avatars for the DR,
but I think in the case of RBridges, it might as well be.
IS-IS does treat the LAN as if it is a node distinct from the DR, and 
the DR issues an
LSP on behalf of the pseudonode, as well as one on behalf of itself, and 
there is a zero cost
link between the pseudonode and each of the routers on the link (with 
nonzero cost from a node
to the pseudonode, and zero cost the other way, or vice versa). 
Traditionally, endnode information for the link
would go into the pseudonode's LSP rather than the DR's.

For RBridges, I think the answer to my question is that it does not 
matter -- I *think* the same
tree would be calculated whether you chose as root the pseudonode or the 
DR. So it's probably better
to say that pseudonodes do not request nicknames, and cannot be 
specified as the root of trees,
and would never appear as the ingress or egress RBridge. I don't think 
it matters whether the
endnode information appears to be advertised by the DR or the 
pseudonode. I think we can let the IS-IS
people decide that detail.

Radia



Eric Gray (LO/EUS) wrote:

>Radia,
>
>	As I understand it, IS-IS creates a pseudo-node as an
>avatar of the designated router.  You probably would not see
>a local forwarding entry from the pseudo-node to the DR, and
>then from there onto whatever link the DR will forward the
>packet.
>
>	Is there any reason in L2 forwarding why we cannot use
>the same identifier for the DR(Bridge) in lieu of any sort of
>distinguished pseudo-node identifier?
>
>	If we can't use the DR(Bridge) identifier/nickname as
>a "pseduo-node identifier", I don't think we can say that a 
>"pseudo-node" would not be either an ingress.  An important 
>reason why we need to determine a DR(Bridge) is to handle the 
>potential for ingress/egress on a shared link.
>
>	Unless you're saying that the pseudo-node would be the
>first next-hop for an ingress or last hop before an egress...
>
>--
>Eric
>
>  
>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Radia Perlman
>>Sent: Sunday, January 07, 2007 8:01 PM
>>To: [e-mail]
>>Subject: [rbridge] IS-IS pseudonodes, nicknames, and rooted trees
>>
>>In IS-IS, a shared link is treated as a "pseudonode" -- as if it were 
>>another router. The purpose of
>>this is because the routing algorithm scales as the number of 
>>links, so 
>>a link with n router neighbors
>>becomes n+1 nodes with n links rather than fully connected, 
>>order of n^2 
>>links.
>>
>>The Designated Router gives the pseudonode a name (in IS-IS, 
>>a 7-byte ID 
>>consisting of
>>a 6-byte EUI owned by the DR, plus an extra byte to 
>>differentiate among 
>>links that that router
>>is DR for), and generates an LSP on behalf of the pseudonode.
>>
>>Anyway, the question is -- should we allow/require pseudonodes to be 
>>assigned RBridge nicknames?
>>There are two reasons for obtaining an RBridge nickname
>>
>>1) to be specified as the egress RBridge of a data packet -- I don't 
>>think this will ever be relevant
>>to pseudonodes
>>2) to be specified as the root of a tree
>>
>>My inclination is to say pseudonodes cannot be egress RBridges, or 
>>specified as tree roots, and
>>therefore pseudonodes will not be given nicknames.
>>
>>Comments?
>>
>>Radia
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l090C7gd018580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 8 Jan 2007 16:12:07 -0800 (PST)
Received: from [127.0.0.1] ([128.9.176.73]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l090Bu6x003163; Mon, 8 Jan 2007 16:12:02 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 08 Jan 2007 16:11:54 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBF2B093DA9F93E007791B618"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Trivial (I hope) 802 VLAN encoding question
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, 09 Jan 2007 00:13:19 -0000
Status: RO
Content-Length: 1044

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBF2B093DA9F93E007791B618
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Radia Perlman wrote:
> Is there a distinction between VLAN 0 and null VLAN? In other words, if=
=20
> there is
> no VLAN tag, is that the same as being in VLAN 0?

VLAN 0 is special; it means "priority-tagged".

Null VLAN is different.

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


--------------enigBF2B093DA9F93E007791B618
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFFot3KE5f5cImnZrsRAuWIAKDmYHaXw04xrtYPeFC47+eCKXwz/QCgoFKQ
VY9vFi7RUzWkOcr2O0aV34k=
=EjZT
-----END PGP SIGNATURE-----

--------------enigBF2B093DA9F93E007791B618--



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 l08LFDl7021789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 8 Jan 2007 13:15:13 -0800 (PST)
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 l08LFCoi023398; Mon, 8 Jan 2007 15:15:13 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 8 Jan 2007 15:15:12 -0600
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, 8 Jan 2007 15:15:11 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IP Multicast groups/ layer 2 or layer 3?
Thread-Index: AccyxZTVQYfxmaF+SWmyA5VErk78yQApGpKQ
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 08 Jan 2007 21:15:12.0517 (UTC) FILETIME=[1597D350:01C7336A]
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 l08LFDl7021789
Cc: [e-mail]
Subject: Re: [rbridge] IP Multicast groups/ layer 2 or layer 3?
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, 08 Jan 2007 21:15:43 -0000
Status: RO
Content-Length: 1032

Radia,

	In my opinion, it should be a Layer 2 address.

--
Eric

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Sunday, January 07, 2007 8:21 PM
> To: [e-mail]
> Subject: [rbridge] IP Multicast groups/ layer 2 or layer 3?
> 
> When an RBridge  R announces via IS-IS which IP multicast groups are  
> reachable on R's directly
> attached links, should the groups be layer 3 or layer 2 addresses?
> 
> If it's layer 3, then there will have to be separate 
> announcements for 
> IPv4 and IPv6 groups.
> If it's layer 2, then 32 IPv4 groups would map to the same layer 2 
> multicast address (and I'm
> not sure what it is for IPv6).
> 
> I don't care. The spec currently says layer 2, but there is a 
> question 
> in the spec asking if that's what
> we really want.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



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 l08LEIwn021640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 8 Jan 2007 13:14:19 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l08La7pj006231; Mon, 8 Jan 2007 15:36:07 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 8 Jan 2007 15:14:17 -0600
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, 8 Jan 2007 15:14:16 -0600
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] IS-IS pseudonodes, nicknames, and rooted trees
Thread-Index: Accywxiyan/isHXuT9Wg7bEi12DBcAAo+llA
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-OriginalArrivalTime: 08 Jan 2007 21:14:17.0841 (UTC) FILETIME=[F500EE10:01C73369]
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 l08LEIwn021640
Cc: [e-mail]
Subject: Re: [rbridge] IS-IS pseudonodes, nicknames, and rooted trees
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, 08 Jan 2007 21:14:54 -0000
Status: RO
Content-Length: 2333

Radia,

	As I understand it, IS-IS creates a pseudo-node as an
avatar of the designated router.  You probably would not see
a local forwarding entry from the pseudo-node to the DR, and
then from there onto whatever link the DR will forward the
packet.

	Is there any reason in L2 forwarding why we cannot use
the same identifier for the DR(Bridge) in lieu of any sort of
distinguished pseudo-node identifier?

	If we can't use the DR(Bridge) identifier/nickname as
a "pseduo-node identifier", I don't think we can say that a 
"pseudo-node" would not be either an ingress.  An important 
reason why we need to determine a DR(Bridge) is to handle the 
potential for ingress/egress on a shared link.

	Unless you're saying that the pseudo-node would be the
first next-hop for an ingress or last hop before an egress...

--
Eric

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Sunday, January 07, 2007 8:01 PM
> To: [e-mail]
> Subject: [rbridge] IS-IS pseudonodes, nicknames, and rooted trees
> 
> In IS-IS, a shared link is treated as a "pseudonode" -- as if it were 
> another router. The purpose of
> this is because the routing algorithm scales as the number of 
> links, so 
> a link with n router neighbors
> becomes n+1 nodes with n links rather than fully connected, 
> order of n^2 
> links.
> 
> The Designated Router gives the pseudonode a name (in IS-IS, 
> a 7-byte ID 
> consisting of
> a 6-byte EUI owned by the DR, plus an extra byte to 
> differentiate among 
> links that that router
> is DR for), and generates an LSP on behalf of the pseudonode.
> 
> Anyway, the question is -- should we allow/require pseudonodes to be 
> assigned RBridge nicknames?
> There are two reasons for obtaining an RBridge nickname
> 
> 1) to be specified as the egress RBridge of a data packet -- I don't 
> think this will ever be relevant
> to pseudonodes
> 2) to be specified as the root of a tree
> 
> My inclination is to say pseudonodes cannot be egress RBridges, or 
> specified as tree roots, and
> therefore pseudonodes will not be given nicknames.
> 
> Comments?
> 
> Radia
> 
> _______________________________________________
> 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 l082qmr3024955 for <[e-mail]>; Sun, 7 Jan 2007 18:52:48 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.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]; Sun, 07 Jan 2007 18:52:46 -0800 (PST)
Received: from sun.com ([129.150.29.110]) 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]; Sun, 07 Jan 2007 18:52:46 -0800 (PST)
Date: Sun, 07 Jan 2007 18:52:50 -0800
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Trivial (I hope) 802 VLAN encoding question
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, 08 Jan 2007 02:53:07 -0000
Status: RO
Content-Length: 879

Is there a distinction between VLAN 0 and null VLAN? In other words, if 
there is
no VLAN tag, is that the same as being in VLAN 0?

I'm trying to specify how to distinguish the per-VLAN instance of IS-IS 
from the core instance.
I was assuming it would be done based on an inner VLAN tag. But suppose 
there were no VLANs,
but you still wanted different instances for the endnode information and 
the core information (so that
truly inner guys wouldn't have to store all the endnode membership link 
state information).
You couldn't do that with a VLAN tag, unless you used VLAN tag with 
VLAN=0 for the endnoe
membership instance.

Not a really horrible problem -- we can certainly find a way of encoding 
this, but just wondering if
VLAN tag will work (where we use VLAN tag explicitly with VLAN = 0 to 
indicate the endnode
membership inforamtion for the null VLAN?)

Radia



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 l081KXtr002696 for <[e-mail]>; Sun, 7 Jan 2007 17:20:33 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.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]; Sun, 07 Jan 2007 17:20:32 -0800 (PST)
Received: from sun.com ([129.150.29.110]) 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]; Sun, 07 Jan 2007 17:20:31 -0800 (PST)
Date: Sun, 07 Jan 2007 17:20:35 -0800
From: Radia Perlman <[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
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] IP Multicast groups/ layer 2 or layer 3?
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, 08 Jan 2007 01:21:05 -0000
Status: RO
Content-Length: 516

When an RBridge  R announces via IS-IS which IP multicast groups are  
reachable on R's directly
attached links, should the groups be layer 3 or layer 2 addresses?

If it's layer 3, then there will have to be separate announcements for 
IPv4 and IPv6 groups.
If it's layer 2, then 32 IPv4 groups would map to the same layer 2 
multicast address (and I'm
not sure what it is for IPv6).

I don't care. The spec currently says layer 2, but there is a question 
in the spec asking if that's what
we really want.

Radia



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 l0811Oob028458 for <[e-mail]>; Sun, 7 Jan 2007 17:01:24 -0800 (PST)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.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]; Sun, 07 Jan 2007 17:01:14 -0800 (PST)
Received: from sun.com ([129.150.29.110]) 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]; Sun, 07 Jan 2007 17:01:14 -0800 (PST)
Date: Sun, 07 Jan 2007 17:01:19 -0800
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] IS-IS pseudonodes, nicknames, and rooted trees
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, 08 Jan 2007 01:01:40 -0000
Status: RO
Content-Length: 1017

In IS-IS, a shared link is treated as a "pseudonode" -- as if it were 
another router. The purpose of
this is because the routing algorithm scales as the number of links, so 
a link with n router neighbors
becomes n+1 nodes with n links rather than fully connected, order of n^2 
links.

The Designated Router gives the pseudonode a name (in IS-IS, a 7-byte ID 
consisting of
a 6-byte EUI owned by the DR, plus an extra byte to differentiate among 
links that that router
is DR for), and generates an LSP on behalf of the pseudonode.

Anyway, the question is -- should we allow/require pseudonodes to be 
assigned RBridge nicknames?
There are two reasons for obtaining an RBridge nickname

1) to be specified as the egress RBridge of a data packet -- I don't 
think this will ever be relevant
to pseudonodes
2) to be specified as the root of a tree

My inclination is to say pseudonodes cannot be egress RBridges, or 
specified as tree roots, and
therefore pseudonodes will not be given nicknames.

Comments?

Radia