Subject: [rbridge] Donald Eastlake as TRILL Co-Chair

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 30 Jan 2006 23:50:37 -0500

You're welcome...

Donald 

 =========================================================
 Donald E. Eastlake III       Donald.Eastlake at Motorola.com
 Motorola Laboratories              +1-508-786-7554 (work)
 111 Locke Drive                    +1-508-634-2066 (home)
 Marlboro, MA 01752 USA

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Margaret Wasserman
Sent: Monday, January 30, 2006 8:58 PM
To: 'Developing a hybrid router/bridge.'
Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair

Thank you, Donald!  And please accept my condolences on your appointment.
;-)

Margaret 

> -----Original Message-----
> From: rbridge-bounces at postel.org
> [mailto:rbridge-bounces at postel.org] On Behalf Of Mark Townsley
> Sent: Monday, January 30, 2006 8:38 PM
> To: rbridge at postel.org
> Subject: [rbridge] Donald Eastlake as TRILL Co-Chair
> 
> 
> Donald will be helping Erik with the task of co-chair for the group.
> 
> Thanks,
> 
> - Mark

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge

From: Eastlake III Donald-LDE008 <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Mon, 30 Jan 2006 23:50:37 -0500
Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1134

You're welcome...

Donald 

 =========================================================
 Donald E. Eastlake III       [email-masked]
 Motorola Laboratories              +1-508-786-7554 (work)
 111 Locke Drive                    +1-508-634-2066 (home)
 Marlboro, MA 01752 USA

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Margaret Wasserman
Sent: Monday, January 30, 2006 8:58 PM
To: 'Developing a hybrid router/bridge.'
Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair

Thank you, Donald!  And please accept my condolences on your appointment.
;-)

Margaret 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mark Townsley
> Sent: Monday, January 30, 2006 8:38 PM
> To: [email-masked]
> Subject: [rbridge] Donald Eastlake as TRILL Co-Chair
> 
> 
> Donald will be helping Erik with the task of co-chair for the group.
> 
> Thanks,
> 
> - Mark

_______________________________________________
rbridge mailing list
[email-masked]
http://www.postel.org/mailman/listinfo/rbridge

From: "Margaret Wasserman" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 30 Jan 2006 20:58:26 -0500
Subject: Re: [rbridge] Donald Eastlake as TRILL Co-Chair
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 591

Thank you, Donald!  And please accept my condolences on your appointment.
;-)

Margaret 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Townsley
> Sent: Monday, January 30, 2006 8:38 PM
> To: [email-masked]
> Subject: [rbridge] Donald Eastlake as TRILL Co-Chair
> 
> 
> Donald will be helping Erik with the task of co-chair for the group.
> 
> Thanks,
> 
> - Mark
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge
> 

Date: Mon, 30 Jan 2006 17:37:41 -0800
From: Mark Townsley <[email-masked]>
To: [email-masked]
Subject: [rbridge] Donald Eastlake as TRILL Co-Chair
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 87

Donald will be helping Erik with the task of co-chair for the group.

Thanks,

- Mark

Date: Sun, 08 Jan 2006 22:00:35 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] it's time to summarize things
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3427

Erik Nordmark wrote:

>Guillermo Ib??ez wrote:
>
>  
>
>>Well, it seems then that we can have loops for all that time.  If
>>subsecond intervals are needed, Hello Time must be
>>lower than 1 second. I find this mechanism more costly than using RSTP,
>>(already used by the bridges in the hub) to detect the double DR
>>situation.  By using the Root bridge election mechanism of
>>RSTP (via colocated bridge), the process uses the standard RSTP BPDUs
>>and selects in a reliable form a unique Root bridge and DR, assuming the
>>default bridge priority of bridges for election is worse than the
>>default priority of Rbridges (this can be defined at will).  Although it
>>means a small dependency on the 802.1D standard, it seems more advisable
>>to rely in a standard mechanism to act in a consistent way than
>>duplicate the mechanism and ignore RSTP protocol to obtain full
>>independency.
>>Rbridges ignoring fully RSTP BPDUs means all that means for knowing
>>"link" and tree status are dropped, the risk for malfunction is
>>increased as  long as Rbridges ignore BPDU information as useless.
>>One difference is that if DR Hello messages are not received, or
>>messages from new bridges appear, Rbridges might use received RSTP BPDU
>>information to confirm the cause and motivation of messages, so
>>decisions more consistent with RSTP can be taken.
>>Perhaps the main argument is that Root bridge election stops inmediatly
>>the frame forwarding in link (hub) blocking the loop, while via DR, the
>>stopping is done by Rbridges election. That is not the case if spanning
>>tree remains active while two DRs coexist on the link reinjecting the
>>traffic in the link through the Rbridge campus. The process requires
>>full communication between Rbridges through the link while there is a
>>loop on it.  Root bridge election does not.
>>    
>>
>
>Guillermo,
>There is one thing I don't understand.
>
>Are you or are you not assuming that an RBridge (via the collocated 
>bridge) will always be elected as a root for the above to work?
>Even if the RBridges (well, their co-located bridges) have the highest 
>root bridge priority, there could another legacy bridge in the network 
>that has the same priority, in which case the root bridge election would 
>use the MAC address as the tie-breaker. This means that there is the 
>possibility that some other bridge will be elected the root. Then what 
>happens?
>
>    Erik
>
>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>
Erik,
       You are right, although I think it is not a realistic situation.
In the case you mention (maximum possible priority in both bridges, 
collocated and legacy ) the bridge with lower MAC will be elected root. 
But a legacy bridge with  maximum priority configured requires somebody 
that has configured it to be the root. This is in contradiction with  an 
environment where we are assuming selfconfiguration (i.e default values 
for priorities). I see this situation more likely produced as an 
intentional fault than a real possibility.
        The situation is identical to an standard spanning tree protocol 
attack (a bridge issuing fake BPDUs with very low priority and MAC). The 
standard STP protocol is vulnerable to such attacks.     

Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid

Date: Sat, 07 Jan 2006 22:20:38 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] it's time to summarize things
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2375

Guillermo Ib??ez wrote:

> Well, it seems then that we can have loops for all that time.  If
> subsecond intervals are needed, Hello Time must be
> lower than 1 second. I find this mechanism more costly than using RSTP,
> (already used by the bridges in the hub) to detect the double DR
> situation.  By using the Root bridge election mechanism of
> RSTP (via colocated bridge), the process uses the standard RSTP BPDUs
> and selects in a reliable form a unique Root bridge and DR, assuming the
> default bridge priority of bridges for election is worse than the
> default priority of Rbridges (this can be defined at will).  Although it
> means a small dependency on the 802.1D standard, it seems more advisable
> to rely in a standard mechanism to act in a consistent way than
> duplicate the mechanism and ignore RSTP protocol to obtain full
> independency.
> Rbridges ignoring fully RSTP BPDUs means all that means for knowing
> "link" and tree status are dropped, the risk for malfunction is
> increased as  long as Rbridges ignore BPDU information as useless.
> One difference is that if DR Hello messages are not received, or
> messages from new bridges appear, Rbridges might use received RSTP BPDU
> information to confirm the cause and motivation of messages, so
> decisions more consistent with RSTP can be taken.
> Perhaps the main argument is that Root bridge election stops inmediatly
> the frame forwarding in link (hub) blocking the loop, while via DR, the
> stopping is done by Rbridges election. That is not the case if spanning
> tree remains active while two DRs coexist on the link reinjecting the
> traffic in the link through the Rbridge campus. The process requires
> full communication between Rbridges through the link while there is a
> loop on it.  Root bridge election does not.

Guillermo,
There is one thing I don't understand.

Are you or are you not assuming that an RBridge (via the collocated 
bridge) will always be elected as a root for the above to work?
Even if the RBridges (well, their co-located bridges) have the highest 
root bridge priority, there could another legacy bridge in the network 
that has the same priority, in which case the root bridge election would 
use the MAC address as the tie-breaker. This means that there is the 
possibility that some other bridge will be elected the root. Then what 
happens?

    Erik

From: "Gray, Eric" <[email-masked]>
To: "'Radia Perlman'" <[email-masked]>
Date: Thu, 5 Jan 2006 20:03:26 -0500 
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] ARP proxying
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3478

Radia,

	I think it is the case that whatever optimization might
be proposed should work well with implementations that don't
support it.

	This is likely to be the case in optimization versions
I understand have been proposed to date.

	The set of topologies of optimized and non-optimized 
RBridges that are possible is arbitrarily large.  But it can
be shown that the "replay" version (with periodic deliberate
cache miss behavior) works well with one optimized RBridge
among any number of non-optimized RBridges (that one RBridge
will reduce ARP request/reply traffic on ports facing any
specific destination for which it holds a cache, and this 
behavior will have no direct effect, and a neglible indirect 
effect, on non-optimized RBridges in the same LAN).  That 
will hold for any topology of RBridges.  It also is true 
that replacing one or more additional RBridges, or insering 
new RBridges, with the ARP/ND Optimization consistently 
improves the behavior of the ARP/ND Optimization over-all 
without introducing strange corner cases - again in any 
topology.

	One way to look at the interactions between optimized
and non-optimized RBridges in such a scheme is to treat the
non-optimized RBridges as if they were optimized versions
that consistently see cache misses.  Consequently, proper 
behavior will occur in a mixed deployment as long as the 
specified behavior for the ARP/ND Optimization does not 
include deliberate behavior that makes excessive cache-miss 
behavior pathological.  An example of a pathological mis-
behavior of this sort would be anything that optimized 
RBridges do that assumes that everybody has a similar ARP 
(replay) cache (for instance, assuming that neighboring
RBridges already have cache entries and not forwarding ARP
replies).

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Thursday, January 05, 2006 7:08 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] ARP proxying
--> 
--> You're right. What I meant is that whatever mechanism there is for 
--> distributed ARP/ND queries,
--> all the RBridges have to support it. But it can be the 
--> choice of the 
--> first RBridge when each
--> mechanism is performed.
--> 
--> Radia
--> 
--> 
--> 
--> Erik Nordmark wrote:
--> 
--> >Radia Perlman wrote:
--> >  
--> >
--> >>I believe the ARP/ND optimization does need to be in the 
--> draft, because the
--> >>solutions we've talked about need to be done by all RBridges.
--> >>    
--> >>
--> >
--> >I don't understand why all RBridges would need to do the 
--> optimizations.
--> >
--> >At least for ARP replays, and for "ARP unicasts" (RBridges unicast 
--> >request to the last known egress RBridge for the MAC 
--> address) I can see 
--> >that some RBridges can do this based on the ARP 
--> information they have 
--> >cached, while other RBridges just forward the ARP request 
--> packets as any 
--> >other broadcast packets.
--> >
--> >It certainly would be nice if we could have this as an 
--> optimization, but 
--> >not require it.
--> >
--> >    Erik
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Thu, 05 Jan 2006 16:07:56 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ARP proxying
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1071

You're right. What I meant is that whatever mechanism there is for 
distributed ARP/ND queries,
all the RBridges have to support it. But it can be the choice of the 
first RBridge when each
mechanism is performed.

Radia

Erik Nordmark wrote:

>Radia Perlman wrote:
>  
>
>>I believe the ARP/ND optimization does need to be in the draft, because the
>>solutions we've talked about need to be done by all RBridges.
>>    
>>
>
>I don't understand why all RBridges would need to do the optimizations.
>
>At least for ARP replays, and for "ARP unicasts" (RBridges unicast 
>request to the last known egress RBridge for the MAC address) I can see 
>that some RBridges can do this based on the ARP information they have 
>cached, while other RBridges just forward the ARP request packets as any 
>other broadcast packets.
>
>It certainly would be nice if we could have this as an optimization, but 
>not require it.
>
>    Erik
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Date: Thu, 05 Jan 2006 15:39:16 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] PS Issue #11 -> now ARCH issue #6
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2702

Joe Touch wrote:

> The term 'inside' in the PS doc refers to components and protocols local
> to the solution, rather than those that are visible to the rest of the
> L2 network.
> 
> The terms 'internal interface' and 'external interface' in the ARCH doc
> is consistent with the terms 'inside' and 'outside' in the PS, but is
> specific to a component of the described architecture.
> 
> We can try to pick mutually exclusive adjectives throughout, but in this
> case the use is consistent, and the terms sufficiently qualified
> (interface) to be clear.

FWIW I'm confused each time I see an argument that uses "inside" and 
"outside" in the context of rbridges.

>>Do we even need any such terms? If not, then we can get rid of any 
>>confusion by just deleting the terms. Where are the terms actually used 
>>and useful?
> 
> 
> Grep for them in the docs; if there's a way to get rid of them without
> being too roundabout, fine. However, they've been used pervasively in
> discussions of the protocols and mechanisms.

I took a look, and it looks quite easy to remove them (and the use of 
"internal" and "external" in arch). For instance, "internal traffic" 
should just be replaced with "encapsulated traffic".

If we do this, we can also remove the (in my mind) confusing statements like
  this communication may traverse external devices, but is
       still considered internal.
and avoid the artificial splitting in figure 3 in arch of the r7-b8-r9
path into an external and an internal path; this is merely a path which 
carries both encapsulated and non-encapsulated frames. (And in fact, all 
paths will carry non-encapsulated frames during flooding to find an 
unknown destination.)

>>This is the distinction between encapsulated and non-encapsulated 
>>frames, right?
> 
> 
> If we're talking about frames, yes. But what about the protocol to
> manage the paths of encapsulated frames? That's unnecessarily awkward,
> compared to 'internal routing protocol'.

I don't think "internal routing protocol" or "external to the solution" 
is per-see problematic, but the former can be replaced by "the rbridge 
link-state routing protocol", which can be shortened to "the rbridge 
routing protocol" or even "the routing protocol" when the rest is clear 
from the context.

What I do find confusing are the notions of inside/internal and 
outside/external:
  - ports/links/topology
  - traffic
  - campus (FWIW I view the campus as the thing which includes the 
hosts, bridges, etc; but the arch document presents the campus as 
something which is just the rbridges and some subset of the connectivity 
between the rbridges - I can't tell for sure what's viewed as part of it)

    Erik

Date: Thu, 05 Jan 2006 15:38:26 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ARP proxying
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 649

Radia Perlman wrote:
> I believe the ARP/ND optimization does need to be in the draft, because the
> solutions we've talked about need to be done by all RBridges.

I don't understand why all RBridges would need to do the optimizations.

At least for ARP replays, and for "ARP unicasts" (RBridges unicast 
request to the last known egress RBridge for the MAC address) I can see 
that some RBridges can do this based on the ARP information they have 
cached, while other RBridges just forward the ARP request packets as any 
other broadcast packets.

It certainly would be nice if we could have this as an optimization, but 
not require it.

    Erik

Date: Thu, 05 Jan 2006 15:34:23 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] ARP proxying
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 943

It seems like we've more or less settled on the use of terminology as 
Guillermo summarizes it below.

FWIW Using a new term like "ARP replay" makes sense to me to describe 
the actual mechanism that has been discussed, since it is more likely to 
avoid confusion compared to using existing terms like "proxying" and 
"caching".

    Erik

-------- Original Message --------
Subject: Re: [rbridge] ARP proxying
Date: Wed, 21 Dec 2005 11:57:01 +0100
From: Guillermo Ib??ez <[email-masked]>
Reply-To: Developing a hybrid router/bridge. <[email-masked]>
To: Developing a hybrid router/bridge. <[email-masked]>
References: 
<[email-masked]> 
<[email-masked]> <[email-masked]>

I agree with Radia term "ARP optimization" where no specificity is
desired or required, and with Joe's term "ARP replay" when an accurate
description is needed.
Guillermo

Date: Thu, 05 Jan 2006 13:20:38 -0800
From: Radia Perlman <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Frequency of LSP information flooding
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1473

For the inter-RBridge connectivity information this would only be 
flooded when
it changes (when a link goes up or comes down). Preferably to prevent a 
yo-yo link
from causing too many updates, there would be some hold-down, after a 
link has
been down, so that a router won't keep announcing a link has come up 
until it's
likely to be stable. I don't think the IS-IS spec actually specifies a 
hold-down, since
each router can have its own strategy and things will interwork. I'd 
assume that inter-RBridge
links would not change more quickly than, say, on the average once per 
hour. So I'd
think that in practice this information would average one announcement 
per RBridge
per hour. But this is just a guess. It would be good to hear from people 
who are
actually running link state networks.

For the endnode information, however, this is likely to be much more 
volatile.
Which is another reason to distribute the endnode information in a 
different instance
of IS-IS (the first reason being to limit the overhead of VLAN-specific 
knowledge
only to RBridges connected to that VLAN).

Radia

Saikat Ray wrote:

>A quick question: how often an RBridge would flood its link-state
>information to the rest of the network? An order would do (e.g., once every
>few seconds, or few minutes, or few hours, etc.).
>
>Thanks.
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

From: "Gray, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Thu, 5 Jan 2006 15:33:37 -0500 
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] Frequency of LSP information flooding
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 972

We should pick a default value to recommend.  What would
you suggest?

In any case, however, this would a configurable quantity
with a default value so that configuration would not be
absolutely required.

The optimal value would depend at least somewhat on the
deployment scenario...

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Saikat Ray
--> Sent: Thursday, January 05, 2006 2:57 PM
--> To: 'Developing a hybrid router/bridge.'
--> Subject: [rbridge] Frequency of LSP information flooding
--> 
--> A quick question: how often an RBridge would flood its link-state
--> information to the rest of the network? An order would do 
--> (e.g., once every
--> few seconds, or few minutes, or few hours, etc.).
--> 
--> Thanks.
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Thu, 5 Jan 2006 14:56:42 -0500
Organization: University of Pennsylvania
Subject: [rbridge] Frequency of LSP information flooding
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 202

A quick question: how often an RBridge would flood its link-state
information to the rest of the network? An order would do (e.g., once every
few seconds, or few minutes, or few hours, etc.).

Thanks.

Content-class: urn:content-classes:message
Date: Wed, 4 Jan 2006 09:56:15 -0800
From: "Ghanwani, Anoop" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled in a	bridged network today?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2453

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Harald Tveit 
> Alvestrand
> Sent: Wednesday, January 04, 2006 2:36 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] How are packets/link without a VLAN 
> tag handled in a bridged network today?
> 
> 
> 
> --On torsdag, desember 29, 2005 20:03:10 -0800 "Ghanwani, Anoop" 
> <[email-masked]> wrote:
> 
> > As for (3), yes, a port can be a member of
> > multiple VLANs.  In that case, untagged traffic
> > arriving at the port gets assigned the PVID.
> > When you send traffic out, there is a parameter
> > to control whether or not a given VLAN should
> > be tagged/untagged before sending the frame
> > out.
> 
> Just to be sure I understand you correctly:
> 
> If an untagged frame arrives from the LAN to the switch, it 
> gets assigned 
> the PVID belonging to the port it arrives on (there can be only one).
> 
> The operator can configure the port to receive traffic for 
> multiple VLANs, 
> and can make the decision for each VLAN on the port whether 
> to send out the 
> frames on that port for that VLAN tagged or untagged.
> 
> Right?

Yes, that's right.

> 
> (I can imagine some cases where it would be useful to send 
> traffic from 
> more than one VLAN untagged (if one VLAN is used to distribute 
> unidirectional multicast traffic "broadcast-like" into all 
> segments, for 
> instance), but I agree that this could easily be confusing if 
> the operator 
> doesn't keeep things very straight in his head.... mixing tagged and 
> untagged traffic would chiefly be useful (I think) if a link 
> is used both 
> to connect end-stations to bridges and to connect bridges, much as we 
> imagine "internal" (in Joe's terms) traffic between RBridges 
> flowing over 
> the same physical LAN segments as "external" traffic.)
> 
> BTW... I couldn't find a place in 802.1Q that talks about 
> *changing* VLAN 
> IDs; is this a standard function or a "vendor extension"?

This is a vendor extension for 802.1Q.  For the provider
tag (or s-tag) in IEEE 802.1ad, this is an optional function
specified.  You basically have a VID translation table
that maps the VID in the frame to an "internal" VID,
and for outbound frames, you map the "internal" VID to
a VID in the frame.  The VID translation table is 
specifically disallowed for the customer tag (or C-tag)
which is the normal 802.1Q tag.

Anoop

From: "Gray, Eric" <[email-masked]>
To: "'Harald Tveit Alvestrand'" <[email-masked]>
Date: Wed, 4 Jan 2006 12:04:45 -0500 
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled in a	bridged network today?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3542

Harald,

	It is not necessary to specify "changing" VLAN IDs, nor
is it precisely a vendor extension.

	It is simply something that can happen inside a box if 
a specific VLAN has one ID on one port and another ID on another
port.

	About the only thing that would need to be said is that 
the VLAN ID and actual VLAN identified by it must be common to
all ports attached to the same shared LAN segment.  In order 
to keep things simple, it would not make sense to have different
VLAN IDs used to identify the same VLAN in a highly connected
set of LAN segments.  But this makes sense for other reasons as 
well, since the most likely motivation for needing to change 
VLAN IDs is because of scoping issues with VLAN IDs assigned by 
multiple authorities and - in such cases - it is unlikely that
this will occur among highly interconnected LAN segments.

	It is probably worth noting that the only time a VLAN 
aware bridge/switch would otherwise typically need to look at 
VLAN IDs is when it needs it to disambiguate filtering database
entries (when the same MAC address appears on multiple VLANs).
This is essentially what makes VLAN aware and non VLAN aware
bridges/switches compatible.

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Harald 
--> Tveit Alvestrand
--> Sent: Wednesday, January 04, 2006 5:36 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] How are packets/link without a VLAN 
--> tag handled in a bridged network today?
--> 
--> 
--> 
--> --On torsdag, desember 29, 2005 20:03:10 -0800 "Ghanwani, Anoop" 
--> <[email-masked]> wrote:
--> 
--> > As for (3), yes, a port can be a member of
--> > multiple VLANs.  In that case, untagged traffic
--> > arriving at the port gets assigned the PVID.
--> > When you send traffic out, there is a parameter
--> > to control whether or not a given VLAN should
--> > be tagged/untagged before sending the frame
--> > out.
--> 
--> Just to be sure I understand you correctly:
--> 
--> If an untagged frame arrives from the LAN to the switch, it 
--> gets assigned 
--> the PVID belonging to the port it arrives on (there can be 
--> only one).
--> 
--> The operator can configure the port to receive traffic for 
--> multiple VLANs, 
--> and can make the decision for each VLAN on the port whether 
--> to send out the 
--> frames on that port for that VLAN tagged or untagged.
--> 
--> Right?
--> 
--> (I can imagine some cases where it would be useful to send 
--> traffic from 
--> more than one VLAN untagged (if one VLAN is used to distribute 
--> unidirectional multicast traffic "broadcast-like" into all 
--> segments, for 
--> instance), but I agree that this could easily be confusing 
--> if the operator 
--> doesn't keeep things very straight in his head.... mixing 
--> tagged and 
--> untagged traffic would chiefly be useful (I think) if a 
--> link is used both 
--> to connect end-stations to bridges and to connect bridges, 
--> much as we 
--> imagine "internal" (in Joe's terms) traffic between 
--> RBridges flowing over 
--> the same physical LAN segments as "external" traffic.)
--> 
--> BTW... I couldn't find a place in 802.1Q that talks about 
--> *changing* VLAN 
--> IDs; is this a standard function or a "vendor extension"?
--> 
-->                       Harald
--> 
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Wed, 4 Jan 2006 09:04:08 -0800
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled in a	bridged network today?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2266

> -----Original Message-----
> From: [email-masked] 
> 
> --On torsdag, desember 29, 2005 20:03:10 -0800 "Ghanwani, Anoop" 
> <[email-masked]> wrote:
> 
> > As for (3), yes, a port can be a member of multiple VLANs.  In that 
> > case, untagged traffic arriving at the port gets assigned the PVID.
> > When you send traffic out, there is a parameter to control 
> whether or 
> > not a given VLAN should be tagged/untagged before sending the frame 
> > out.
> 
> Just to be sure I understand you correctly:
> 
> If an untagged frame arrives from the LAN to the switch, it 
> gets assigned the PVID belonging to the port it arrives on 
> (there can be only one).
> 
> The operator can configure the port to receive traffic for 
> multiple VLANs, and can make the decision for each VLAN on 
> the port whether to send out the frames on that port for that 
> VLAN tagged or untagged.
> 
> Right?
> 
> (I can imagine some cases where it would be useful to send 
> traffic from more than one VLAN untagged (if one VLAN is used 
> to distribute unidirectional multicast traffic 
> "broadcast-like" into all segments, for instance), but I 
> agree that this could easily be confusing if the operator 
> doesn't keeep things very straight in his head.... mixing 
> tagged and untagged traffic would chiefly be useful (I think) 
> if a link is used both to connect end-stations to bridges and 
> to connect bridges, much as we imagine "internal" (in Joe's 
> terms) traffic between RBridges flowing over the same 
> physical LAN segments as "external" traffic.)

Agreed, normally only 1 VLAN can be sent untagged on a given link.
There are some interesting loop scenarios that occur with 802.1s if you
were to transmit multiple untagged VLANs.  However, there are a few
cases where this is done with your multicast example being one.

> 
> BTW... I couldn't find a place in 802.1Q that talks about 
> *changing* VLAN IDs; is this a standard function or a "vendor 
> extension"?

It was introduced as part of the provider bridging standard, 802.1ad.  

Michael

> 
>                       Harald
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge
> 

Date: Wed, 04 Jan 2006 11:36:09 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled in a	bridged network today?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1602

--On torsdag, desember 29, 2005 20:03:10 -0800 "Ghanwani, Anoop" 
<[email-masked]> wrote:

> As for (3), yes, a port can be a member of
> multiple VLANs.  In that case, untagged traffic
> arriving at the port gets assigned the PVID.
> When you send traffic out, there is a parameter
> to control whether or not a given VLAN should
> be tagged/untagged before sending the frame
> out.

Just to be sure I understand you correctly:

If an untagged frame arrives from the LAN to the switch, it gets assigned 
the PVID belonging to the port it arrives on (there can be only one).

The operator can configure the port to receive traffic for multiple VLANs, 
and can make the decision for each VLAN on the port whether to send out the 
frames on that port for that VLAN tagged or untagged.

Right?

(I can imagine some cases where it would be useful to send traffic from 
more than one VLAN untagged (if one VLAN is used to distribute 
unidirectional multicast traffic "broadcast-like" into all segments, for 
instance), but I agree that this could easily be confusing if the operator 
doesn't keeep things very straight in his head.... mixing tagged and 
untagged traffic would chiefly be useful (I think) if a link is used both 
to connect end-stations to bridges and to connect bridges, much as we 
imagine "internal" (in Joe's terms) traffic between RBridges flowing over 
the same physical LAN segments as "external" traffic.)

BTW... I couldn't find a place in 802.1Q that talks about *changing* VLAN 
IDs; is this a standard function or a "vendor extension"?

                      Harald

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 3 Jan 2006 14:00:35 -0500 
Subject: Re: [rbridge] How are packets/link without a VLAN tag handled ina		bridged network today?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7782

Somewhat subtly implied in this discussion is the idea that VLAN
IDs are typically used between VLAN aware switches and not on a
LAN segment where non VLAN aware end stations are likely to be
connected.

I imagine problems can arise if an end station (such as a network
management station) is connected to a port of a VLAN aware switch
and that port is not configured (somehow) to recognize that the
end station is not VLAN aware.

Technically, stripping VLAN IDs is one way of changing them (and
this might normally be the function of a router).  However, it is
usually the case that stripping VLAN IDs at a port simply makes
the conversion between a port-based VLAN context and contextually
identical VLAN-ID-based context.  In other words, a VLAN aware
switch (or bridge) can switch between port A/VLAN 1, port b/VLAN 2
and port c as long as {port A/VLAN 1}, {port B/VLAN 2} and {port c}
are configured at that switch as a contextually identical VLAN.

As a result, a VLAN aware switch switches frames within the same
VLAN context - on a port by port basis - even if the VLAN ID is
added, removed or changed. 

However...

If an end station is attached (perhaps inadvertently) at a point 
where VLAN IDs are used, it should discard frames identified as 
"tagged" while still accepting those that are not - presumably 
including frames addressed to it.  Consequently, using multiple
VLAN IDs on a LAN segment containing end stations is sub-optimal,
not non-functional.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Holland, 
--> David (David)
--> Sent: Friday, December 30, 2005 6:48 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] How are packets/link without a VLAN 
--> tag handled ina bridged network today?
--> 
--> Radia,
--> 
--> As Anoop observed the specifics are documented in 802.1Q, the switch
--> implementation I referrred to is compliant (so I described 
--> the switch
--> behavior).
--> 
--> Again, as Anoop pointed out the switch may be configured to 
--> preserve or
--> strip tags before forwarding. Typically users configure the 
--> links to end
--> nodes as clear (no tag) to support older implementations 
--> that are not
--> VLAN aware. The only VLAN aware "end" nodes I know of are 
--> IP phones, and
--> these usually have embedded L2 switch chips (Zultys etc.)
--> 
--> David
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On
--> Behalf Of Radia Perlman
--> Sent: Thursday, December 29, 2005 10:52 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] How are packets/link without a VLAN 
--> tag handled
--> ina bridged network today?
--> 
--> Thanks!
--> 
--> So, there is a specific special "untagged" VLAN, which is 
--> "marked" by
--> the absence of a VLAN tag. As opposed to a meaning that this packet
--> should go to everyone, which I could also imagine.
--> 
--> Another question then...if bridges add the VLAN tag (and therefore
--> endnodes are unaware of VLAN tags), then how is it possible 
--> to support a
--> link with multiple VLANs? Wouldn't endnodes get confused 
--> because they
--> will see packets from other VLANs? I'd assume that unless 
--> endnodes are
--> VLAN-aware, and put in their own tags, that it would be 
--> illegal for a
--> link to support multiple VLANs. Is this true?
--> 
--> And...are you saying that this is not written down 
--> anywhere, but just
--> observed based on how some particular vendor implemented it?
--> 
--> Thanks again!
--> 
--> Radia
--> 
--> 
--> 
--> Holland, David (David) wrote:
--> 
--> >Radia,
--> >
--> >My experience from working on switch/router "brand z", is that the 
--> >behavior for "a" (below) is correct.
--> >
--> >In the "b" case the packet is NOT flooded to the other 
--> vlans UNLESS 
--> >those ports are also participating in the (default) 
--> untagged vlan by 
--> >configuration.
--> >
--> >For item "c": Yes the link can support all VLANS or only selected
--> VLANS.
--> >The configuration options allow for the bridge to 
--> automatically bind 
--> >the link to all VLANs for which tag values are observed 
--> (or only those 
--> >received on the link or only those manually administered). This 
--> >provides for trunking links.
--> >
--> >David
--> >
--> >-----Original Message-----
--> >From: [email-masked] 
--> [mailto:[email-masked]] On
--> 
--> >Behalf Of Radia Perlman
--> >Sent: Thursday, December 29, 2005 8:21 PM
--> >To: Developing a hybrid router/bridge.
--> >Subject: [rbridge] How are packets/link without a VLAN tag 
--> handled in a
--> 
--> >bridged network today?
--> >
--> >I guessed at the behavior once, to someone who was following 802.1 
--> >better than I have been, and he verified that I was correct at the 
--> >time, but I've forgotten what my conjecture was. Does 
--> anyone know how 
--> >the following cases are handled?
--> >
--> >Suppose a bridged network has some links configured as VLAN A, and 
--> >others configured as VLAN B, and some links that are not 
--> configured as 
--> >either VLAN A or VLAN B. Let's say that links La1 and La2 are 
--> >configured as VLAN A, links Lb1 and Lb2 are configured as 
--> Lb, and links
--> 
--> >Lc1 and Lc2 are not configured to reside in either VLAN A 
--> or VLAN B.
--> >
--> >Let's further assume that it is the bridges that put on 
--> the VLAN tags.
--> >
--> >What happens in the following cases?
--> >
--> >a) A layer 2 multicast packet originates at La1. Certainly 
--> the first 
--> >bridge adds a VLAN A tag to the packet, and delivers the 
--> packet to La2.
--> >However, does it also deliver it to Lc1 and Lc2? (I'd be 
--> very surprised
--> 
--> >if the answer to this was yes...I assume the packet will ONLY get 
--> >delivered to links that are specifically marked as 
--> supporting VLAN A).
--> >
--> >b) A layer 2 multicast packet originates at Lc1. I assume 
--> the behavior 
--> >in this case is that the first bridge does NOT add a VLAN 
--> tag to the 
--> >packet. I can imagine either in this case that the packet is ONLY 
--> >delivered to Lc2 (i.e., other links that are not configured as 
--> >belonging to any VLAN), but I suspect the packet is 
--> delivered to ALL 
--> >links, i.e., in this case, La1, La2, Lb1, Lb2, and Lc2, 
--> and without a
--> VLAN tag.
--> >This would mean that endnodes in VLAN A and endnodes in 
--> VLAN B will see
--> 
--> >this packet, so perhaps it's the other behavior (that it's only 
--> >delivered to links that are not configured as being in any VLAN).
--> >
--> >c) If it is the bridge, rather than endnodes that put on 
--> the VLAN tag, 
--> >is it legal for a link to support multiple VLANs? It would 
--> make sense 
--> >for the answer to this to be no, in which case I suspect 
--> the answer to
--> >b) above would be more likely to be "don't deliver to any 
--> links that 
--> >have been configured to be in any VLAN", since I suspect "unmarked
--> VLAN"
--> >is treated as a special case VLAN.
--> >
--> >Radia
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
-->