Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Wed, 01 Aug 2007 10:43:47 -0700

OK, based on emails from James Carlson and Radia, I went back and 
thought about my reasons for objecting to the suggested proposal. I also 
spoke to some field engineers to validate my understanding of what I 
thought the issues were.

There are two issues that we're dealing with here:
- Simplifying DRB election to conduct it only on VLAN 1
- Merging partitioned VLANs.

I'd like to separate the two issues. Let me discuss only the first 
issue, the simplified DRB election in this email. I'll send out a 
separate email on the other issue.

Assuming VLAN 1 exists everywhere is an acceptable alternative. I was 
informed that even with STP, customers enable VLAN 1 and allow only 
control traffic on it and not data traffic. If we have VLAN 1 present as 
a common configuration, then running DRB only on VLAN 1 and following 
Radia's proposal (or fixing it to work) seems acceptable, except for one 
caveat.

However, in the event of a misconfiguration and VLAN 1 not being 
present, while the scheme proposed partitions the network and prevents 
loops, it seems to me that there is a period during which temporary 
loops can happen and duplicate frames are delivered by two DRBs. This 
seems unacceptable to me from a customer point of view. If we can fix 
this temporary loop (or someone can explain to me why there are no 
temporary loops), I'd be willing to support this proposal.

BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% of 
customer networks and so we cannot assume or mandate their being there.

Dinesh
Radia Perlman wrote:
> I had a conversation with Anoop, and he is (quite understandably)
> uneasy about sending IS-IS Hellos tagged with every VLAN. So he
> made the following suggestion, which I think makes sense.
>
> a) declare that bridges must be configured
> so that VLAN 1 (default VLAN) must not be
> partitioned on a layer 2 cloud. We will detect the misconfiguration
> if it occurs (see d)) so that we at least do not have loops, but TRILL 
> will not
> stand on its head to support what will be declared a gross misconfiguration.
>
> b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
> the following information in its IS-IS Hello:
>
> . I am R1
> . I hear Hellos from {R2, R3, R7, R11}
> . If I am DRB, the pseudonode name will be R1.59
> . My priority for the set of VLANs {A, D, W} is 7
> . My priority for the set of VLANs {B, C, F, G, H} is 3
>
> c) If R1 becomes DRB for at least one of the VLANs on the cloud,
> then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
> the ID of the root bridge on the primary spanning tree
> instance for that layer 2 cloud, along with the set of VLANs for which
> R1 is DRB on that cloud.
>
> Note: The current draft spec isn't clear what information R1 reports in 
> the pseudonode
> LSP and what it reports in its own LSP.
> I'm suggesting reporting the bridge ID and
> set of VLANs in the pseudonode LSP.
>
> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11,
> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
> listed as one of the VLANs, this indicates that VLAN 1 on that layer
> 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
> data to/from that cloud for VLAN A. Use ID as a tie breaker, so
> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding VLAN A
> traffic to and from the port that has root bridge r11.
> This is the behavior that will occur if VLAN 1 on that port is
> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2 would
> have seen each other's Hellos and not both think they are DRB for VLAN A (or
> any other VLAN).
>
> e) This proposal supports multiple DRBs on a cloud for load splitting
> based on VLANs, since the RBridges can have different priorities
> for different VLANs. It still requires only sending one Hello, tagged
> with VLAN 1. R2 should
> not panic if R2 notices that R1.59 has the same root bridge as on
> a port on which R2 is DRB, if R1.59's listed set of VLANs does not
> include any VLANs for which R2 is DRB on the link with
> that root bridge. If there is only partial overlap
> of VLAN IDs, say the overlap is VLANs {D, F, and H},
> then (the loser based on ID tie-breaker) will stop forwarding traffic
> to/from that link that is tagged with VLANs D, F, or H.
>
> f) If some VLAN, say VLAN C, is actually partitioned, then the
> result of this is that some VLAN C endnodes on that layer 2 cloud
> will be orphaned. We will choose NOT to solve that.
>
>
> The result of this proposal is that
> RBridges will only need to send IS-IS Hellos tagged
> with VLAN 1, and the only thing it does NOT solve (over
> the current proposal of sending Hellos with every possible VLAN tag on
> each port) is that sometimes endnodes might get orphaned if you have
> a partitioned VLAN.
>
>
> We *could* in that case, if someone *actually wanted* to have VLAN A
> partitioned on that cloud, configure the RBridges on that layer 2
> cloud to explicitly run a different election
> for VLAN A (and note in the pseudonode LSP that VLAN A had
> an explicit election tagged with VLAN A so that if there were
> two DRBs they wouldn't panic). But I'd prefer not solving this case and
> keeping it simpler (and safer).
>
> Radia
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 01 Aug 2007 14:37:38 -0700

Dinesh,

I think you are right that there can be a temporary loop due to a 
partitioned VLAN 1.
And I think we can make it sufficiently unlikely to occur with a 
suggestion I'll make
after I explain the problem.

The temporary loop would be if R1 and R2, on the same layer 2 cloud, have
connectivity through VLAN A but not VLAN 1. So there would be two DRBs, on
both VLAN A and VLAN 1. There would be two pseudonodes, say R1.79 and R2.62,
and both would claim to be connected to both VLAN A and VLAN 1, and both
would claim the same root bridge, say 5134.

A multicast tagged with VLAN 1 would not be too much of a problem 
because anything
R1 decapsulates onto that VLAN-1-partitioned cloud would not make it through
the partitioned cloud to R2. But since we are not running the DRB 
election tagged
with VLAN A, R1 and R2 do not realize that they can talk via VLAN A.

Therefore, a VLAN A-tagged packet would get picked up by both R1 and R2,
and both would assume they are DRB.
Also, if R1 receives a (inner header) VLAN-A tagged frame
from the campus, R1 will decapsulate it onto the layer 2 cloud as a VLAN-A
tagged packet, and R2 will see it
and re-encapsulate it onto the campus, and R1 would see it again and 
decapsulate it, etc.

This loop will eventually be fixed when R1 sees the LSP from pseudonode  
R2.62 indicating
that the root bridge is 5134, since R1 will also think that the cloud 
that R1 is DRB for has
root bridge 5134.

So here's a possible fix:

R1 does not decapsulate a multidestination packet with ingress RBridge 
R2 unless R1
has an LSP from R2, and has LSPs from all pseudonodes that R2 claims (in 
R2's
LSP) to be DRB for. Note that I'm suggesting adding another flag in the 
neighbor
list in R2's LSP saying "not only am I attached to this pseudonode, but I am
DRB for it".

If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if the 
root bridge
listed is the same as the one for the link on which R2 would like to 
decapsulate, and if it is,
then don't decapsulate.

We were already saying that if R1 notices that R2.79 has the same root 
bridge as
a link R1 wants to be DRB for that one of R1 or R2 would lose, based on 
a tie-breaker
based on ID, and stop forwarding traffic to/from the link. What I'm 
suggesting is that
you also don't forward multidestination traffic to/from a link if you 
don't yet have all
the associated LSP information from the ingress RBridge that can assure 
you there
isn't a common root bridge.

Radia

Dinesh G Dutt wrote:
> thought about my reasons for objecting to the suggested proposal. I 
> also spoke to some field engineers to validate my understanding of 
> what I thought the issues were.
>
> control traffic on it and not data traffic. If we have VLAN 1 present 
> as a common configuration, then running DRB only on VLAN 1 and 
> following Radia's proposal (or fixing it to work) seems acceptable, 
> except for one caveat.
>
>> if it occurs (see d)) so that we at least do not have loops, but 
>> TRILL will not
>> Note: The current draft spec isn't clear what information R1 reports 
>> in the pseudonode

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 2 Aug 2007 14:59:42 -0700

Anoop,

Inline, 

> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop at brocade.com]
> Sent: Tuesday, July 31, 2007 4:06 PM
> To: Silvano Gai; Radia Perlman; Dinesh G Dutt
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
> withallthe VLAN tags
> 
> 
> Hi Silvano,
> 
> Believe it or not there are customers out there that
> use GVRP.  They might not be a majority, but they
> do exist.
> 

You are making my point: "we cannot rely on GVRP to have a solution"

-- Silvano

> As far as I'm aware, it is _not_ very common
> for customers to be reusing VLAN IDs within the
> enterprise.  If they do reuse them, they are in
> physically separate portions of the network that
> are interconnected by routers.  That's the normal
> tiered architecture that one tends to see in
> enterprises.
> 
> I have never come across a customer that uses
> partitioned VLANs the way you mention, so I find
> it hard to believe they are common.  There's always
> the oddball, strange architecture out there.
> Do we really need to force everyone to send per-VLAN
> hellos to deal with that?  We can always design to
> make that type of configuration work, but we should
> optimize for the common case.
> 
> Anoop
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org
> > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> > Sent: Tuesday, July 31, 2007 2:40 PM
> > To: Radia Perlman; Dinesh G Dutt
> > Cc: rbridge at postel.org
> > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
> > tagged withallthe VLAN tags
> >
> >
> > Radia,
> >
> > We are describing to you how VLANs are deployed today in
> > Enterprise networks. You may say that "you don't like it", we
> > may agree with you, but this does not change how they are deployed.
> >
> > For RBridges to be successful they need to be able to replace
> > core bridges without messing up the existing network configurations.
> >
> > Today most customers do not deploy VLANs end-to-end and they
> > do reuse VLANs number in different part of the enterprise. If
> > RBridges are not capable of supporting this, they are not
attractive.
> >
> > Remember that the #1 customer requirement we have for TRILL
> > is: "replace core bridges with RBridges to enable Equal Cost
> > Multi Path, all the rest MUST remain the same".
> >
> > GVRP is not deployed; I am not sure which customers Anoop is
> > referring to.
> >
> > -- Silvano
> >
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> > > Sent: Tuesday, July 31, 2007 11:19 AM
> > > To: Dinesh G Dutt
> > > Cc: Silvano Gai; rbridge at postel.org
> > > Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos
tagged
> > with
> > > allthe VLAN tags
> > >
> > > I don't understand that problem. What you're describing might
argue
> > for
> > > bridges using a unique
> > > spanning tree per VLAN in order to optimize traffic flow for that
> > VLAN,
> > > but I don't
> > > see what it has to do with wanting to partition VLANs.
> > >
> > > Radia
> > >
> > >
> > > Dinesh G Dutt wrote:
> > > > Radia Perlman wrote:
> > > >> I'd like to understand what problem customers are attempting to
> > solve
> > > >> with
> > > >> partitioned VLANs, and what hardship it would present to
> > require at
> > > >> least one of the
> > > >>
> > > > The primary problem with having a VLAN everywhere is that the
root
> > of
> > > > the spanning tree moves around leading to non-optimal
> > forwarding in
> > > > enterprise networks. Enterprise networks are carefully
engineered
> > > > networks and in the event of failure, they want to localize the
> > > > effects as much as possible. So, they want each VLAN to
> > be localized
> > > > and roots where they want it to be. Having a common VLAN
> > messes up
> > > > that arrangement. Also, VLAN 1 is the default VLAN when a switch
> > comes
> > > > up and there is typically lots of customer data on it.
> > > >> VLANs to *not* be partitioned. With TRILL, if a customer
> > eventually
> > > >> replaces all bridges, the customer will not be able to
partition
> > > >> VLANs
> > anymore.
> > > > As I raised it in the meeting, this is a side-effect that has
not
> > been
> > > > considered before and needs to be carefully thought
> > through. I don't
> > > > think many people are aware of this issue with TRILL that
doesn't
> > > > exist with 802.1Q bridges today.
> > > >> Also, from
> > > >> what Anoop was explaining to me, the GVRP protocol would
> > automatically
> > > >> configure the switch-to-switch links to join all the islands of
> > > >> VLANs. So it would seem as though it can't be that fatal
> > to solving
> > > >> customer problems
> > to
> > > >> require
> > > >> *one* VLAN on a layer 2 cloud to not be partitioned.
> > > >>
> > > > GVRP is not deployed by a significant majority of customers.
> > > >
> > > > Dinesh
> > > >
> >
> >

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 2 Aug 2007 15:02:36 -0700

Silvano,

I don't think I ever suggested using GVRP to solve
our problem.  All I was saying is that the fact 
that something like GVRP exists, means that 
802.1Q wasn't designed to handle partitioned
VLANs as the norm.

Anoop 

> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Thursday, August 02, 2007 3:00 PM
> To: Anoop Ghanwani; Radia Perlman; Dinesh G Dutt
> Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos 
> > Believe it or not there are customers out there that use 
> GVRP.  They 
> > might not be a majority, but they do exist.
> > 
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 2 Aug 2007 15:09:09 -0700

Radia,

One of the goal of TRILL is plug and play.

To most people this means "no configuration", to me it means that I
should be able to replace a bridge with an RBridge in an existing
network, configure the RBridge like the replaced bridge and continue to
work.

I DON'T want to ask the network manager to change its VLAN management
scheme and as a result its IP subnet management scheme to be able to
deploy RBridges.

If I ask a network manager to do so, he/she will probably choose to use
an IP routed backbone, defeating the original goal of TRILL.

WE MUST be able to drop RBridges in existing networks without asking for
global reconfigurations.

I say all this because we shouldn't  care "what problem customers are
trying to solve with partitioned VLANs", we know they exists and we
don't want to ask customers to design from scratch to be able to use
RBridges.

-- Silvano

> Sent: Tuesday, July 31, 2007 6:32 PM
> To: Silvano Gai
> Cc: Dinesh G Dutt; rbridge at postel.org
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with
> allthe VLAN tags
> 
> Silvano....I still don't know what problem customers are trying to
solve
> with partitioned VLANs.
> If it's that they want more than 4000 VLANs, then the design we had
> (before
> Anoop's suggestion) also won't help them with that.
> If it is an important problem to use more than 4000 VLANs,
> we could (by extending the size of the VLAN tag within a TRILL campus)
> solve that
> problem in a much more robust, easily understandable way than
> configuring interswitch
> ports to block some VLANs. And I absolutely do not understand any
other
> problems
> that might be solved with intentionally partitioning VLANs, and it's
> impossible to design
> something without understand the problem that needs to be solved.
> 
> We do have to carefully consider what "breaks"  (in the
> proposal we are currently considering) if a customer does actually
> configure
> bridges in some layer 2 cloud so that VLAN 1 is partitioned.
> I believe the only consequence of a customer configuring
> bridges so that VLAN 1 is partitioned in some layer 2 cloud  is that
core
> RBridges that might have connectivity to each
> other through some VLAN other than
> VLAN 1 will not realize they are adjacent, and will therefore not form
> IS-IS adjacencies, which
> means fewer RBridge-RBridge links in the core than there might
actually
> be. This might
> actually cause the campus to get partitioned (since the only
> connectivity between RBridges
> will be using VLAN 1, and if all the links in the cut set require an
> outer tag of other
> than 1 in order for RBridges to talk, these links won't be found or
> used). It might cause less good paths. However, it will *not* cause
> loops, because if
> there is no connectivity for flooding of LSPs, data also won't flow in
> the core.
> 
> The advantage of this proposal is simplicity and scalability -- only
one
> Hello per port.
> 
> As I said, I cannot understand what functionality is lost if all
switch
> ports within a layer 2
> cloud must be configured to pass VLAN 1, and until we do understand
some
> important hardship that this rule imposes, I'd say this (Anoop's
proposal)
> is obviously the right thing to do.
> 
> Radia
> 
> 
> Silvano Gai wrote:
> > Radia,
> >
> > We are describing to you how VLANs are deployed today in Enterprise
> > networks. You may say that "you don't like it", we may agree with
you,
> > but this does not change how they are deployed.
> >
> > For RBridges to be successful they need to be able to replace core
> > bridges without messing up the existing network configurations.
> >
> > Today most customers do not deploy VLANs end-to-end and they do
reuse
> > VLANs number in different part of the enterprise. If RBridges are
not
> > capable of supporting this, they are not attractive.
> >
> > Remember that the #1 customer requirement we have for TRILL is:
"replace
> > core bridges with RBridges to enable Equal Cost Multi Path, all the
rest
> > MUST remain the same".
referring
> > to.
tagged
> >>
> > with
> >
> >> allthe VLAN tags
> >>
> >> I don't understand that problem. What you're describing might argue
> >>
> > for
> >
> >> bridges using a unique
> >>>> partitioned VLANs, and what hardship it would present to require
at
> >>>> least one of the
> >>>>
> >>>>
> >>> The primary problem with having a VLAN everywhere is that the root
> >>>
> > of
> >
> >>> the spanning tree moves around leading to non-optimal forwarding
in
> >>> enterprise networks. Enterprise networks are carefully engineered
> >>> effects as much as possible. So, they want each VLAN to be
localized
> >>> and roots where they want it to be. Having a common VLAN messes up
eventually
> >>>> replaces
> >>>> all bridges, the customer will not be able to partition VLANs
> >>>>
> > anymore.
> >
> >>> As I raised it in the meeting, this is a side-effect that has not
> >>>
> > been
> >
> >>> considered before and needs to be carefully thought through. I
don't
> >>> think many people are aware of this issue with TRILL that doesn't
> >>>> VLANs. So it would
> >>>> seem as though it can't be that fatal to solving customer
problems

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 02 Aug 2007 17:23:26 -0700

Silvano,

I strongly believe that one can't design something reasonable without 
understanding the problem
you're trying to solve. But at this point, whether or not it is useful 
to understand the problem
being solved is not useful to debate (though the last chapter of my book 
has a great
anecdote about why it is desirable to know what problem you're solving 
:-) ).

But at this point let's close this issue, which is basically to adopt 
Anoop's
proposal of only sending IS-IS Hellos tagged with VLAN 1,
plus my addendum to avoid temporary loops when VLAN 1 is partitioned by
having RB2 refuse to decapsulate packets onto a port from ingress 
RBridge RB1 unless
RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB for.

*************
To review it:

a) declare that bridges must be configured
so that VLAN 1 (default VLAN) must not be
partitioned on a layer 2 cloud. We will detect the misconfiguration
if it occurs (see d)) so that we do not have loops, but if VLAN 1
is partitioned parts of the layer 2 cloud might wind up orphaned
from the rest of the campus.

b) Send IS-IS Hellos tagged with VLAN 1, containing the following:

. I am R1

c) If R1 becomes DRB for at least one of the VLANs on the cloud,
then R1 announces (in R1's LSP)
connectivity to pseudonode R1.59, together with
a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on behalf of pseudonode R1.59, R1 announces
the ID of the root bridge on the primary spanning tree
instance for that layer 2 cloud, along with the set of VLANs for which
R1 is DRB on that cloud.

g) To avoid temporary loops when VLAN 1 is partitioned, for each
other RBridge RB1, RB2 sets an (internal) flag "OK to decapsulate
from", provided that RB2 has an LSP from RB1 and all pseudonodes
RB1 claims to be attached to. If RB2 receives a frame from ingress
RB1 and this flag is NOT true, then RB2 will refuse to decapsulate
the packet onto any ports. (regardless of VLAN and regardless of whether
the frame is multidestination or unicast).

Radia

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Thu, 02 Aug 2007 18:07:06 -0700

Radia,

I thought about this solution but think that it still doesn't fix the 
problem of duplicates. If both R1 and R2 think that they're DRB for VLAN 
A, when they both receive a frame on VLAN A from  the 802.1D cloud 
(unknown unicast for example), they both think that they can forward it 
onto the TRILL network. The destination host will now receive duplicate 
frames till one of them stops being DRB.

Am I mistaken ?

Dinesh
Radia Perlman wrote:
> This loop will eventually be fixed when R1 sees the LSP from 
> pseudonode  R2.62 indicating
> has an LSP from R2, and has LSPs from all pseudonodes that R2 claims 
> (in R2's
> LSP) to be DRB for. Note that I'm suggesting adding another flag in 
> the neighbor
> If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see if 
> the root bridge
> a link R1 wants to be DRB for that one of R1 or R2 would lose, based 
> on a tie-breaker
> the associated LSP information from the ingress RBridge that can 
> assure you there
>> present, while the scheme proposed partitions the network and 
>> prevents loops, it seems to me that there is a period during which 
>> temporary loops can happen and duplicate frames are delivered by two 
>> DRBs. This seems unacceptable to me from a customer point of view. If 
>> we can fix this temporary loop (or someone can explain to me why 
>> there are no temporary loops), I'd be willing to support this proposal.
>>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 2 Aug 2007 18:18:48 -0700

Silvano,

There are typically a lot of VLANs at the edge
and only a few in the core.  Today, a typically
enterprise could have 100's (may be a couple of
1000) VLANs configured on a typical bridge.  
But, we don't enable routing protocols on those 
VLANs because that's just the edge.  Once in the 
core, there are typically only a handful of VLANs
on which routing protocols are enabled.  We don't
have experience sending hellos on so many VLANs
and so many ports.  Unlike a router, an RBridge
has to start sending hellos on all its ports as soon
as it comes up.  I don't think things can be
made to work if we have to send these hellos
for every VLAN configured on a port.

I understand that in the ideal case we'd like to
work with any arbitrary configuration.

However, I don't understand how per-VLAN hellos would
keep things working correctly.  If I have a partitioned
VLAN and, as a result, have 2 RBridges that become DRBs
for that VLAN, and if there exists some other
path between these RBridges (via TRILL), then 
these two partitioned sections will now function
as a single partition for that VLAN (via the 
RBridges).  So how have I simplified the network
managers job?  He would still have to change
his/her VLAN configuration if he/she intends
to keep the two partitions disconnected even
after introducing the RBridges.

Anoop

> Sent: Thursday, August 02, 2007 3:09 PM
> To: Radia Perlman
> To most people this means "no configuration", to me it means 
> that I should be able to replace a bridge with an RBridge in 
> an existing network, configure the RBridge like the replaced 
> bridge and continue to work.
> 
> I DON'T want to ask the network manager to change its VLAN 
> management scheme and as a result its IP subnet management 
> scheme to be able to deploy RBridges.
> 
> If I ask a network manager to do so, he/she will probably 
> choose to use an IP routed backbone, defeating the original 
> goal of TRILL.
> 
> WE MUST be able to drop RBridges in existing networks without 
> asking for global reconfigurations.
> 
> I say all this because we shouldn't  care "what problem 
> customers are trying to solve with partitioned VLANs", we 
> know they exists and we don't want to ask customers to design 
> from scratch to be able to use RBridges.
> 
> -- Silvano
> 
> > (before Anoop's suggestion) also won't help them with that.
> > If it is an important problem to use more than 4000 VLANs, we could 
> > (by extending the size of the VLAN tag within a TRILL campus) solve 
> > that problem in a much more robust, easily understandable way than 
> > configuring interswitch ports to block some VLANs. And I 
> absolutely do 
> > not understand any
> other
> > problems
> > impossible to design something without understand the problem that 
> > needs to be solved.
> > 
> > We do have to carefully consider what "breaks"  (in the proposal we 
> > are currently considering) if a customer does actually configure 
> > I believe the only consequence of a customer configuring bridges so 
> > that VLAN 1 is partitioned in some layer 2 cloud  is that
> core
> > RBridges that might have connectivity to each other through 
> some VLAN 
> > other than VLAN 1 will not realize they are adjacent, and will 
> > therefore not form IS-IS adjacencies, which means fewer 
> > RBridge-RBridge links in the core than there might
> actually
> > be. This might
> > connectivity between RBridges will be using VLAN 1, and if all the 
> > links in the cut set require an outer tag of other than 1 
> in order for 
> > RBridges to talk, these links won't be found or used). It 
> might cause 
> > less good paths. However, it will *not* cause loops, 
> because if there 
> > is no connectivity for flooding of LSPs, data also won't 
> flow in the 
> > core.
> > 
> Enterprise 
> > >>>> VLANs. So it would seem as though it can't be that fatal to 
> > >>>> solving customer
> problems
> > >>>>
> > > to
> > >
> > >>>> require

---

From: dwcarder at doit.wisc.edu (Dale W. Carder)
Date: Thu, 02 Aug 2007 22:44:59 -0500

Comments inline:

> 1000) VLANs configured on a typical bridge.

The capabilities of typical small edge switches (the 48 port
kind) seem to max out at about 16-128 vlans total, and may have
other limitations if the switch is maintaining STP for each vlan.
This edge limitation is one of the reasons an enterprise partitions
vlans.

Larger, "core" switches have enough capability to run up to 4096
vlans at a time.

Another issue causing vlans to be partitioned is because some
bridges only support vlan numbers < 1024 and there simply is a need
for vlan number reuse throughout the enterprise.

Vlans are also partitioned is because flooding unknown unicast
frames takes up unnecessary bandwidth on 802.1q links, and can fill
up mac address tables on less-capable switches.  When there are
situations like arp storms (no network is ever loop free),
partitioning vlan usage is even more of an issue.

> on which routing protocols are enabled.
<chop>
>   We don't
> and so many ports.

I disagree with this argument.  Many enterprises and carriers
deploy multiple routers on each edge subnet for redundancy.  To
do this, VRRP or HSRP sends out hellos per vlan.  If they are
running multicast routing, PIM sends out hellos per vlan also.
Some places even tune these hellos to very aggressive settings
such as 1 per second or less.

Large core switches running rapid-STP can send a BPDU every 2
seconds across around 10,000 instances (m vlans * n ports) today.
These switches are also usually sending out (LLDP or CDP) and
UDLD frames on every port, too.

> Unlike a router, an RBridge

Again, big switches have been doing this for a while for rapid-STP.
Routers with large numbers of vlans (sub-interfaces) are also doing
this today.

The larger issue I see with Radia's proposal is simply the choice
of vlan #1.  It could be a poor choice in large enterprises because
of scalability concerns and also compatability with existing
implementations.  As a few others have brought up, many deployments
(including mine) have disabled vlan 1 altogether.

One of these issues is that vlan 1 is often untagged on 802.1q trunk
links.  As a security precaution, it is common to disable vlan 1
across switches to prevent malicious vlan-hopping.

Perhaps a compromise would be to use vlan 1 as the default, but a
TRILL implementation MAY allow this to be configurable by the
administrator.

Dale

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 02 Aug 2007 21:19:22 -0700

Yes, Dinesh, in your example if there are temporarily k RBridges on the 
same layer 2 cloud
that all think they are DRB, you might multiply by k, each packet going 
off the cloud.

However, this is not as disastrous as a loop.

We can avoid that though by saying that you shouldn't start 
encapsulating or decapsulating
data off the link until you've synchronized LSP datases with each of 
your RBridge neighbors.
IS-IS exchanges LSP database information (a "complete sequence numbers 
packet") when
a link comes up. I think we should throw that rule in as well.

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 02 Aug 2007 21:36:36 -0700

Dale,

I certainly don't care which VLAN we choose. There should be a default 
one, and
we should also allow an implementation to be configurable to set it to
a different VLAN tag, or even a set of VLAN tags (in which case the RBridge
would issue multiple IS-IS Hellos, one with each configured VLAN tag).

If RBa receives an IS-IS Hello, it should accept it regardless of what 
VLAN it is
tagged with. If RBa transmits IS-IS Hellos tagged with VLAN A, and RBb 
transmits
IS-IS Hellos tagged with VLAN B, and RBC, .... etc. Then RBa will assume it
has an adjacency with RBc if "RBa" appears in RBc's IS-IS Hello (as 
someone that
RBc has seen Hellos from). And RBa would use VLAN tag A when talking across
the link to any RBridge that RBa has an adjacency with. This may be a 
bit confusing
to understand but I don't think there's a problem with it.

So...what do you think the default VLAN tag should be for sending IS-IS 
Hellos?

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 02 Aug 2007 22:39:06 -0700

Rereading what I wrote, I'd be surprised if anyone actually understood 
what I was
saying from what I wrote, so let me explain again.

Let's say you have 5 RBridges, RBa, RBb, RBc, RBd, and RBe. RBa 
transmits Hellos
with tag VLAN A, RBb tags its hellos with VLAN B, and so forth.

If RBa *only* sends things on the link tagged with VLAN A, it can still 
tell if
it has an adjacency to, say, RBc, which only transmits Hellos tagged with
VLAN C, because the IS-IS Hello includes the list of
RBridges that the transmitting RBridge has heard Hellos from.

So even if RBc always talks to RBa using VLAN C, and RBa always talks to RBc
using VLAN A, things will work. RBa knows it will work because RBc indicates
in its Hello, that it heard a Hello from RBa.

Not sure if that's any clearer, but at least I get credit for trying. 
Maybe partial credit?

Radia

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 3 Aug 2007 10:07:24 -0700

> From: Dale W. Carder [mailto:dwcarder at doit.wisc.edu] 
> Sent: Thursday, August 02, 2007 8:45 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Radia Perlman; rbridge at postel.org

Just to make it clear, we're talking about VLAN reuse
within a single bridged LAN as opposed to VLAN reuse
LANs that are isolated by routers.  I don't see how that
can be common.  It would be a configuration nightmare
to administer and also to debug.

> such as 1 per second or less.

Most folks don't enable routing/VRRP on all VLANs.
Many switches that are capable of having 4K VLANs
configured are not capable of even having IP configured
on all 4K VLANs let alone turning on VRRP.

> UDLD frames on every port, too.

This is completely wrong!  RSTP is not VLAN aware.
MSTP is, but it is limited to 64 instances.  This 
is quite a different number than the 10000 that you
quote.

> TRILL implementation MAY allow this to be configurable by the

I agree.  As also pointed out by Arien Vijn, we could
select any VLAN as the "default RBridge VLAN", but we do
need one.

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 3 Aug 2007 16:36:45 -0400

So why should the default be to tag Hellos with any VLAN ID? It seems to
me that there are two cases.

If you know, via configuration or otherwise, that there are no
intervening legacy bridges (doesn't particularly matter if its
point-to-point between two Rbridges or a multiaccess link with several
Rbridges as long as there are no bridges in the way), then all TRILL
IS-IS and TRILL data frames should be untagged.

If there are or might be intervening bridges, then I would think the
default should be for Hellos to be priority tagged with priority 7. This
means the tag has the null VLAN ID zero, that is, it does not specify
any VLAN. If it turns out there actually aren't any bridges, this works
fine. If the link is actually a bridged LAN, the requirement is then
that the bridge ports that the Rbridges are connected to be configured
to be the same VLAN, whatever that is, and that that VLAN be connected
through that particular bridged LAN. If these bridge ports are default
configured, this means the TRILL IS-IS Hello frames will acquire VLAN 1
tagging on bridged LAN ingress and have that tag stripped on bridged LAN
egress and you would want VLAN 1 to be well connected through the
bridged LAN. If, for some reason, VLAN 1 is inconvenient for the network
operator to use in the particular bridged LAN in question, the network
operator would be free to configure the bridge ports so that the TRILL
frames get tagged with whatever VLAN is more convenient for them to use
to provide connectivity. It could still be possible to configure
Rbridges, on a per port basis, to tag outgoing TRILL frames with some
specific VLAN ID if that is more convenient.

I would like to point out that, while the proposal from Radia below is
much more detailed and better worked out and while the related
provisions in the current protocol draft are much more vague,
nevertheless, the current protocol draft approximately corresponds to
this proposal. In particular, due to previous concerns about multiple
Hellos, among other things the protocol draft (-05) says:

Section 2, Page 7:
   If a link is actually a bridged LAN configured for VLANs, it is
   possible that the link might be partitioned with respect to some
   VLANs.  The default is to run a single DRB election on a link, with
   the IS-IS Hellos either with no VLAN tag (the default), or with the
   VLAN tag specifying the default VLAN for the link. If the RBridge is
   configured to support a set of k VLANs on the link, then the RBridge
   runs the IS-IS DRB election up to k times, each instance tagged with
   one of the VLANs in that set of VLANs depending on its configuration.
   Therefore there might be multiple DRBs on the link, but at most one
   on that link per VLAN. By configuration, the DRB for some VLANs may
   be set by copying the DRB status in the relevant RBridges from a
   different VLAN rather than by election.

So, arguably, the single Hello proposal below is approximately like
using the current vague provisions in the protocol configured to only
Hello on VLAN 1 and applying the result to all VLANs. The main
difference is the proposal provides the per VLAN priorities in the Hello
so you don't need this stuff about copying DRB status but can
independently determine it for different VLANs without a per VLAN
Hello...

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Thursday, August 02, 2007 8:23 PM
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with allthe VLAN tags

...

*************
To review it:

. I am R1

c) If R1 becomes DRB for at least one of the VLANs on the cloud,
then R1 announces (in R1's LSP)
connectivity to pseudonode R1.59, together with
a flag saying "I am DRB for this pseudonode". Also, in R1's LSP on
behalf of pseudonode R1.59, R1 announces
the ID of the root bridge on the primary spanning tree
instance for that layer 2 cloud, along with the set of VLANs for which
R1 is DRB on that cloud.

d) If R2 thinks itself is DRB for VLAN A on a port with root bridge r11,
and R2 sees an LSP for R1.59 that has the same root bridge and VLAN A
listed as one of the VLANs, this indicates that VLAN 1 on that layer
2 cloud is partitioned. So one of R1 or R2 should stop forwarding
data to/from that cloud for VLAN A. Use ID as a tie breaker, so
if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
VLAN A
traffic to and from the port that has root bridge r11.
This is the behavior that will occur if VLAN 1 on that port is
actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
would
have seen each other's Hellos and not both think they are DRB for VLAN A
(or
any other VLAN).

Radia

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 3 Aug 2007 14:59:04 -0700

Donald,

I am OK with the text in -05, I thought that Radia wanted to change it.

As far as I am not prevented from running one DRB per VLAN, I don't care
too much which is the default.

I don't want TRILL to mandate implementing a single DRB election and
additional tests that don't cover all the cases.

Let's keep it simple. The current text is fine.

-- Silvano

> Behalf Of Eastlake III Donald-LDE008
> Sent: Friday, August 03, 2007 1:37 PM
> To: rbridge at postel.org
> withall the VLAN tags

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 4 Aug 2007 23:57:58 -0400

Silvano,

I think that the provisions in the draft should be changed. At a
minimum, it seems useful when someone is doing a DRB election on one
VLAN intending to produce results that apply to multiple VLANs that the
Hellos list the VLANs and be able to specify different priorities for
them so the elections are not all required to come out the same. And
some additional logic to handle partitions seems reasonable.

Donald

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Friday, August 03, 2007 5:59 PM
To: Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
withall the VLAN tags

Donald,

-- Silvano

---

From: dwcarder at doit.wisc.edu (Dale W. Carder)
Date: Mon, 06 Aug 2007 10:48:53 -0500

> is quite a different number than the 10000 that you

I was referring in this case to a proprietary implementation,
but my point is that it seems possible that it can be done.

I am not saying that sending hellos on every vlan is a great
idea, but I just wanted to show that I believe it is feasible
based on deployments I have seen that are running protocols
that do send hellos or similar on every vlan today.

> select any VLAN as the "default RBridge VLAN", but we do

I don't think there is any easy solution.

Could the default be to use vlan 1 *untagged*?  This would
allow an rbridge to be plugged in almost anywhere.  If a
network operator wanted to change the vlan number she could
do it on her existing bridged lan.

Is there a more formal name for the "default RBridge VLAN"?

Dale

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Mon, 06 Aug 2007 10:03:29 -0700

Radia,

I don't believe what you suggested below works including what you 
detailed later. The problem is that when Rb1 and Rb2 both think that 
they're DRBs on VLAN A but cannot communicate oN VLAN 1, they may have 
synchronized their LSP databases with their neighbors, but it doesn't 
fix the problem because the information of the other DRB hasn't yet 
reached the neighbor.

I think at this point, I'm leaning towards saying that the default 
SHOULD be to support per-VLAN DRB election, but provide the option to do 
DRB only on a single VLAN, VLAN 1. Allowing which VLAN to carry out the 
DRB on is another potential misconfiguration and so I'm worried about 
this knob, though I won't protest providing it.

Doing it this way solves Anoop's problem for the cases he's worried 
about, but makes the network robust by default.

Dinesh
Radia Perlman wrote:
> Yes, Dinesh, in your example if there are temporarily k RBridges on 
> the same layer 2 cloud
> that all think they are DRB, you might multiply by k, each packet 
> going off the cloud.
>
>> problem of duplicates. If both R1 and R2 think that they're DRB for 
>> VLAN A, when they both receive a frame on VLAN A from  the 802.1D 
>> cloud (unknown unicast for example), they both think that they can 
>> forward it onto the TRILL network. The destination host will now 
>> receive duplicate frames till one of them stops being DRB.
>>
>> Am I mistaken ?
>>
>> Dinesh
>> Radia Perlman wrote:
>>  
>>> Dinesh,
>>>
>>> that the root bridge is 5134, since R1 will also think that the 
>>> cloud that R1 is DRB for has
>>> root bridge 5134.
>>>
>>> R1 does not decapsulate a multidestination packet with ingress 
>>> RBridge R2 unless R1
>>> We were already saying that if R1 notices that R2.79 has the same 
>>> root bridge as
>>> you also don't forward multidestination traffic to/from a link if 
>>> you don't yet have all
>>>> Assuming VLAN 1 exists everywhere is an acceptable alternative. I 
>>>> was informed that even with STP, customers enable VLAN 1 and allow 
>>>> only control traffic on it and not data traffic. If we have VLAN 1 
>>>> present as a common configuration, then running DRB only on VLAN 1 
>>>> and following Radia's proposal (or fixing it to work) seems 
>>>> acceptable, except for one caveat.
>>>>
>>>> temporary loops can happen and duplicate frames are delivered by 
>>>> two DRBs. This seems unacceptable to me from a customer point of 
>>>> view. If we can fix this temporary loop (or someone can explain to 
>>>> me why there are no temporary loops), I'd be willing to support 
>>>> this proposal.
>>>>
>>>>> Note: The current draft spec isn't clear what information R1 
>>>>> reports in the pseudonode

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 6 Aug 2007 10:07:45 -0700

Donald,

I am OK with this change as long as the default is to run one DRB
election per VLAN, since this is the most robust scheme.

-- Silvano

> Sent: Saturday, August 04, 2007 8:58 PM
> > So why should the default be to tag Hellos with any VLAN ID? It
seems
> > configured, this means the TRILL IS-IS Hello frames will acquire
VLAN
> 1
> > have seen each other's Hellos and not both think they are DRB for
VLAN
> A

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 6 Aug 2007 13:34:39 -0400

That was exactly my suggestion. The right way to look at this is to say
that

(1) the Hello is, by default, send to "VLAN 1" with priority 7
(2) the default port VLAN ID for Rbridge ports is 1
(3) the egress processing in the general case is to suppress the VLAN ID
if it matches the port VLAN ID at the egress port

Thus, by default, the VLAN ID will be suppressed in the outer VLAN tag
on TRILL IS-IS frames and they are sent priority tagged with priority 7,
that is, sent with a VLAN tag that says priority 7 and has the VLAN ID
field set to zero. (It says "general case" above because, for example,
if you know it is a point-to-point link between Rbridges, there is no
reason to have any outer VLAN tag.)

A TRILL data frame being sent on VLAN 1 through an Rbridge port with
default port configuration would also have the same thing happen. So it
would end up being send priority tagged with whatever its priority was
except that if the priority was the default value zero, the VLAN tag
could be omitted entirely.

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Dale W. Carder
Sent: Monday, August 06, 2007 11:49 AM
To: Anoop Ghanwani
Cc: rbridge at postel.org; Radia Perlman
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
withallthe VLAN tags

Dale

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 06 Aug 2007 10:48:23 -0700

There was also the rule I threw in later about RB1 not decapsulating 
anything from
RBridge RB2 unless RB1 has an LSP from RB2, and all LSPs from all the 
pseudonodes
that RB2 claims (in RB2's LSP) to be DRB for.

That way RB1, when in doubt (i.e., doesn't yet have the relevant LSPs) 
will not
forward onto a port.

If RB1 *does* have RB2's LSP (which tells RB1 which pseudonodes RB2 is 
DRB for),
and has all those pseudonode LSPs (so it can check to see what the root 
RBridge is),
then RB1 can safely forward onto a port P if the root bridge for port P 
is *not* included
in any of the pseudonodes that RB2 is DRB for.

Radia

Dinesh G Dutt wrote:
> SHOULD be to support per-VLAN DRB election, but provide the option to 
> do DRB only on a single VLAN, VLAN 1. Allowing which VLAN to carry out 
> the DRB on is another potential misconfiguration and so I'm worried 
> about this knob, though I won't protest providing it.
>
>> IS-IS exchanges LSP database information (a "complete sequence 
>> numbers packet") when
>>> I thought about this solution but think that it still doesn't fix 
>>> the problem of duplicates. If both R1 and R2 think that they're DRB 
>>> for VLAN A, when they both receive a frame on VLAN A from  the 
>>> 802.1D cloud (unknown unicast for example), they both think that 
>>> they can forward it onto the TRILL network. The destination host 
>>> will now receive duplicate frames till one of them stops being DRB.
>>>
>>> Am I mistaken ?
>>>
>>> Dinesh
>>> Radia Perlman wrote:
>>>  
>>>> Dinesh,
>>>>
>>>> and re-encapsulate it onto the campus, and R1 would see it again 
>>>> and decapsulate it, etc.
>>>>
>>>> has an LSP from R2, and has LSPs from all pseudonodes that R2 
>>>> claims (in R2's
>>>> If R1 has all the pseudonode LSPs for which R2 is DRB, R1 can see 
>>>> if the root bridge
>>>> listed is the same as the one for the link on which R2 would like 
>>>> to decapsulate, and if it is,
>>>> then don't decapsulate.
>>>>
>>>> a link R1 wants to be DRB for that one of R1 or R2 would lose, 
>>>> based on a tie-breaker
>>>>> thought about my reasons for objecting to the suggested proposal. 
>>>>> I also spoke to some field engineers to validate my understanding 
>>>>> of what I thought the issues were.
>>>>>
>>>>> BTW, GVTP/MMRP or equivalent is very much not enabled in >80-90% 
>>>>> of customer networks and so we cannot assume or mandate their 
>>>>> being there.
>>>>>
>>>>> Dinesh
>>>>> Radia Perlman wrote:
>>>>>     
>>>>>> VLAN A (or

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 9 Aug 2007 15:52:12 -0400

Hi Silvano,

Defaulting to having to send 4094 Hellos on every port seems like an
excessive burden for low end and middle range Rbridges, for software
implementations, unmanaged Rbridges, etc. On the other hand, in high end
Rbridges, where this would not be much of a burden, you generally
already have a lot of configuration going on. In fact, you don't have a
problem that needs to be solved with these thousands of Hellos per port
unless you have complex legacy configured 802.1Q bridged LANs in the
picture, which I would think almost entirely occurs at the high end.

While I certainly don't think the interests of high end Rbridges should
be ignored, I also don't think other use scenarios should be ignored.

Low end and mid-range Rbridges, where sending large numbers of Hellos
would be the most burdensome, are the Rbridges most likely to be
unmanaged or minimally managed, and in these cases the networks are
likely to be fairly simple, without discontinuous legacy bridge VLANs.
High end Rbridges, where sending large number of Hellos would be less
burdensome, are the Rbridges very likely to be heavily managed and
configured, so it does not seem to me that it should be that much of a
problem for those network manages to configure them to do multiple
Hellos. Also these high end Rbridges are more likely to be connected to
complex discontinuous VLAN legacy bridged LANs where the multiple Hellos
might actually be needed.

Furthermore, the desired end state is that there aren't any legacy 802.1
Q bridges in the network and it seems very wasteful, in that end state,
to have to keep configuring Rbridges just to turn off multiple Hellos.

Based on the above, my conclusion is that the zero configuration default
should be to send a single Hello.

As I've described before, I tend to think this Hello should by default
be sent with maximum priority 7 but no VLAN ID (i.e., the VLAN ID field
should be zero) and thus the technically correct description of the zero
configuration default Rbridge Hello frames is that they are "priority
tagged" with priority 7.

Donald

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Monday, August 06, 2007 1:08 PM
To: Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
withallthe VLAN tags

Donald,

-- Silvano

seems
VLAN
VLAN

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Thu, 09 Aug 2007 15:14:01 -0700

That is not what Silvano and I (or at least I) have been advocating. We 
send as many Hellos as active VLANs i.e. configured VLANs on the port. 
In 802.1Q switches (or at least the ones that I'm aware of), by default 
only VLAN 1 is enabled. You must configure additional VLANs.

Low end switches typically support fewer active VLANs. Many high-end 
switches also certify less than 4K VLANs. So, the low cost switch 
argument doesn't make sense to me.

I want correct behavior by default, even with misconfiguration. If 
someone wants to turn off that, an additional supported option is fine 
with me.

Dinesh
Eastlake III Donald-LDE008 wrote:
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>     
> On
>   
>> VLAN intending to produce results that apply to multiple VLANs that
>>     
> the
>   
>> I am OK with the text in -05, I thought that Radia wanted to change
>>     
> it.
>   
>> As far as I am not prevented from running one DRB per VLAN, I don't
>>     
> care
>   
>>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>>       
>> On
>>     
>>> point-to-point between two Rbridges or a multiaccess link with
>>>       
> several
>   
>>> default should be for Hellos to be priority tagged with priority 7.
>>>       
>> This
>>     
>>> means the tag has the null VLAN ID zero, that is, it does not
>>>       
> specify
>   
>>> any VLAN. If it turns out there actually aren't any bridges, this
>>>       
>> works
>>     
>>> that the bridge ports that the Rbridges are connected to be
>>>       
> configured
>   
>>> to be the same VLAN, whatever that is, and that that VLAN be
>>>       
> connected
>   
>>> through that particular bridged LAN. If these bridge ports are
>>>       
> default
>   
>>> tagging on bridged LAN ingress and have that tag stripped on bridged
>>>       
>> LAN
>>     
>>> bridged LAN. If, for some reason, VLAN 1 is inconvenient for the
>>>       
>> network
>>     
>>> operator to use in the particular bridged LAN in question, the
>>>       
> network
>   
>>> operator would be free to configure the bridge ports so that the
>>>       
> TRILL
>   
>>> frames get tagged with whatever VLAN is more convenient for them to
>>>       
>> use
>>     
>>> Rbridges, on a per port basis, to tag outgoing TRILL frames with
>>>       
> some
>   
>>> I would like to point out that, while the proposal from Radia below
>>>       
> is
>   
>>> nevertheless, the current protocol draft approximately corresponds
>>>       
> to
>   
>>> this proposal. In particular, due to previous concerns about
>>>       
> multiple
>   
>>>    VLANs.  The default is to run a single DRB election on a link,
>>>       
> with
>   
>>>    the IS-IS Hellos either with no VLAN tag (the default), or with
>>>       
> the
>   
>>>    VLAN tag specifying the default VLAN for the link. If the RBridge
>>>       
>> is
>>     
>>>    configured to support a set of k VLANs on the link, then the
>>>       
>> RBridge
>>     
>>>    runs the IS-IS DRB election up to k times, each instance tagged
>>>       
>> with
>>     
>>>    one of the VLANs in that set of VLANs depending on its
>>>       
>> configuration.
>>     
>>>    Therefore there might be multiple DRBs on the link, but at most
>>>       
> one
>   
>>>    on that link per VLAN. By configuration, the DRB for some VLANs
>>>       
> may
>   
>>> using the current vague provisions in the protocol configured to
>>>       
> only
>   
>>> difference is the proposal provides the per VLAN priorities in the
>>>       
>> Hello
>>     
>>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>>       
>> On
>>     
>>> Behalf Of Radia Perlman
>>> But at this point let's close this issue, which is basically to
>>>       
> adopt
>   
>>> Anoop's
>>> plus my addendum to avoid temporary loops when VLAN 1 is partitioned
>>>       
>> by
>>     
>>> RB2 has received LSPs from RB1 and all pseudonodes that RB1 is DRB
>>>       
>> for.
>>     
>>> *************
>>> To review it:
>>>
>>> instance for that layer 2 cloud, along with the set of VLANs for
>>>       
> which
>   
>>> R1 is DRB on that cloud.
>>>
>>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
>>>       
>> r11,
>>     
>>> and R2 sees an LSP for R1.59 that has the same root bridge and VLAN
>>>       
> A
>   
>>> e) This proposal supports multiple DRBs on a cloud for load
>>>       
> splitting
>   
>>> for different VLANs. It still requires only sending one Hello,
>>>       
> tagged
>   
>>> with VLAN 1. R2 should
>>> then (the loser based on ID tie-breaker) will stop forwarding
>>>       
> traffic
>   
>>> the packet onto any ports. (regardless of VLAN and regardless of
>>>       
>> whether
>>

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Thu, 09 Aug 2007 15:28:23 -0700

I would like to add that as the "send only 1 Hello" proposal currently 
stands, it is possible that there can be duplicate frames for a 
transient period while the network quiesces. I believe there are many 
apps that work in existing L2 networks under the assumption that no 
duplicates will be seen and so can fail in mysterious ways when this 
happens. And detecting this as the cause will be incredibly hard. So 
saying "just enable per-active-VLAN Hellos when there is a problem" 
doesn't bite.

I'd like RBridges to be robust by default,

Dinesh

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 9 Aug 2007 15:59:02 -0700

Donald,

I never asked to send 4094 Hellos on every port.

If you read IEEE 802.1Q-2005, A.12 Implementation parameters, you will
see that you can specify the VLAN design parameters for a Bridge.

If you read 5.3 VLAN-aware Bridge requirements you see that only one
VLAN is required to be supported for compliance.

An RBridge should do exactly the same, specify these parameters and send
by default an Hello for each supported VLAN (see item IMP-4), since
per-VLAN is the only robust solution that works in any configuration.

I am OK with an option to enable the single-VLAN, and this may work well
in network that are appropriately designed, but I am pretty sure that
there are corner cases in which it does not work.

If in this second case you want to have different RBridge implementation
parameters (e.g. more VLANs supported) I am OK.

Cheers

-- Silvano

On
> Sent: Thursday, August 09, 2007 12:52 PM
> taggedwithallthe VLAN tags
> 
> Hi Silvano,
> 
[mailto:rbridge-bounces at postel.org]
tagged
> > > From: rbridge-bounces at postel.org
[mailto:rbridge-bounces at postel.org]
tagged

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 9 Aug 2007 17:00:21 -0700

Hi Silvano,

We're doing things to detect those corner cases where
things are misconfigured.  If I'm migrating a network
to using RBridges and bridge port that I'm about to
switch to the RBridge happens to be receiving traffic 
from 200 VLANs, I will need to start sending 200 hellos
on that port.  If the control plane runs into scaling
problems, the only way to solve this issue would
be to start splitting all the traffic that goes
into _one_ regular bridge across multiple RBridges.

Anoop

> Sent: Thursday, August 09, 2007 3:59 PM
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS 
> Hellostaggedwithallthe VLAN tags
> 
> 
> Donald,
> 
> If you read IEEE 802.1Q-2005, A.12 Implementation parameters, 
> you will see that you can specify the VLAN design parameters 
> for a Bridge.
> 
> If you read 5.3 VLAN-aware Bridge requirements you see that 
> only one VLAN is required to be supported for compliance.
> 
> An RBridge should do exactly the same, specify these 
> parameters and send by default an Hello for each supported 
> VLAN (see item IMP-4), since per-VLAN is the only robust 
> solution that works in any configuration.
> 
> I am OK with an option to enable the single-VLAN, and this 
> may work well in network that are appropriately designed, but 
> I am pretty sure that there are corner cases in which it does 
> not work.
> 
> If in this second case you want to have different RBridge 
> implementation parameters (e.g. more VLANs supported) I am OK.
> 
> Cheers
> 
> -- Silvano
> 
> > already have a lot of configuration going on. In fact, you 
> don't have
> a
> > > >    be set by copying the DRB status in the relevant 
> RBridges from
> a
> > > > proposal of only sending IS-IS Hellos tagged with VLAN 
> 1, plus my 
> > > > addendum to avoid temporary loops when VLAN 1 is
> partitioned
> > > by
> > > > a) declare that bridges must be configured so that VLAN 
> 1 (default 
> > > > VLAN) must not be partitioned on a layer 2 cloud. We 
> will detect 
> > > > the
> misconfiguration
> > > > . I hear Hellos from {R2, R3, R7, R11} . If I am DRB, the 
> > > > pseudonode name will be R1.59 . My priority for the set 
> of VLANs 
> > > > {A, D, W} is 7 . My priority for the set of VLANs {B, 
> C, F, G, H} 
> > > > is 3
> > > >
> > > > then R1 announces (in R1's LSP) connectivity to 
> pseudonode R1.59, 
> > > > together with a flag saying "I am DRB for this 
> pseudonode". Also, 
> > > > in R1's LSP on behalf of pseudonode R1.59, R1 announces 
> the ID of 
> > > > the root bridge on the primary spanning tree instance for that 
> > > > layer 2 cloud, along with the set of VLANs for
> > which
> > > > R1 is DRB on that cloud.
> > > >
> > > > data to/from that cloud for VLAN A. Use ID as a tie 
> breaker, so if 
> > > > R2's IS-IS system ID is lower than R1's, then R2 stops
> forwarding
> > > > VLAN A
> > > > actually partitioned. If VLAN 1 is *not* partitioned, 
> then R1 and
> R2
> > > > would
> that root 
> > > > bridge. If there is only partial overlap of VLAN IDs, say the 
> > > > overlap is VLANs {D, F, and H}, then (the loser based on ID 
> > > > tie-breaker) will stop forwarding
> > traffic

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 9 Aug 2007 18:41:42 -0700

Anoop,

> Sent: Thursday, August 09, 2007 5:00 PM
> To: Silvano Gai; Eastlake III Donald-LDE008; rbridge at postel.org
with
> all the VLAN tags
> things are misconfigured.  

But you have failed to prove that "these things" are robust.

Sending a Hello on each VLAN is robust and it should be the default
solution.

-- Silvano

If I'm migrating a network
> > > implementations, unmanaged Rbridges, etc. On the other hand, in
high
> > end
> > > Hellos. Also these high end Rbridges are more likely to be
connected
> > > should be zero) and thus the technically correct description of
the
> > zero
> > Hellos tagged
> > > > Hellos list the VLANs and be able to specify different
priorities
> > > > > If there are or might be intervening bridges, then I would
think
> > the
> > > > > default should be for Hellos to be priority tagged with
priority
> > 7.
> > > > > fine. If the link is actually a bridged LAN, the requirement
is
> > then
> > > > > frames get tagged with whatever VLAN is more convenient for
them

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 10 Aug 2007 10:30:39 -0700

anoop> We're doing things to detect those corner cases where things are 
anoop> misconfigured.
 
silvano> But you have failed to prove that "these things" are robust.
silvano> 
silvano> Sending a Hello on each VLAN is robust and it should be the 
silvano> default solution.

It's a question of what the robustness requirement is.
I believe the solution Radia has proposed is adequate.
There is one corner case pointed out by Dinesh where
one may get duplication of traffic for a short period
(probably a few seconds) until the misconfiguration is
detected.  I think this is adequate.  

Other than that I don't see any issues.
If there are any other scenarios you are concerned
about please post them.

If at all, the per-VLAN IS-IS instances should be
optional.  Those that are willing to bear the cost
for whatever benefit it gives them may choose to
implement it.

Anoop

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sat, 11 Aug 2007 13:21:38 -0700

Anoop,

> Sent: Friday, August 10, 2007 10:31 AM
with
> detected.  I think this is adequate.

I strongly disagree. 

1) Duplicated frames are bad and several applications cannot tolerate
them. I am pretty sure that one of your favorite applications is FCoE
(Fibre Channel over Ethernet). You don't want to have duplicated SCSI
frames.

2) There is also the issue pointed out by James Carlson: "if the user
has two RBridges (R1 and R2) attached to the same Ethernet subnetwork,
and R1 supports only VLANs {A,B} while R2 supports only VLANs {A,C},
then neither one can actually be the DRB for that whole network."

3) There are many other corner cases, but to point them out I need the
pseudo-code you intend to use. If you post it and give me some time,
I'll find the corner cases.

I remain opposed to use a technique different to per-VLAN Hello.
In general I think optimizations are better dealt with in the second
version of the protocol.

I also remain strongly in favor of doing a last call on the frame
format: if we continue to introduce optimization in the control plane,
it will be a while before the control plane is stable.

-- Silvano

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Sat, 11 Aug 2007 16:54:37 -0700

> Sent: Saturday, August 11, 2007 1:22 PM
> To: Anoop Ghanwani; Eastlake III Donald-LDE008; rbridge at postel.org
> tagged with all the VLAN tags
> 
> 
> Anoop,
> 
> > There is one corner case pointed out by Dinesh where one may get 
> > duplication of traffic for a short period (probably a few seconds) 
> > until the misconfiguration is detected.  I think this is adequate.
> > 
> 
> I strongly disagree. 
> 
> 1) Duplicated frames are bad and several applications cannot 
> tolerate them. I am pretty sure that one of your favorite 
> applications is FCoE (Fibre Channel over Ethernet). You don't 
> want to have duplicated SCSI frames.

That is true.  But it happens only when the network is
misconfigured and that too for a limited time (i.e. until
the misconfiguration is detected).

> 2) There is also the issue pointed out by James Carlson: "if 
> the user has two RBridges (R1 and R2) attached to the same 
> Ethernet subnetwork, and R1 supports only VLANs {A,B} while 
> R2 supports only VLANs {A,C}, then neither one can actually 
> be the DRB for that whole network."

This is not an issue because (and I think Radia has already
pointed this out) we can always run the DRB election per VLAN
or per group of VLANs over the base instance.

> 3) There are many other corner cases, but to point them out I 
> need the pseudo-code you intend to use. If you post it and 
> give me some time, I'll find the corner case.
>
> In general I think optimizations are better dealt with in the 
> second version of the protocol.

Let's take a hypothetical scenario and say we go with per VLAN
hellos.  Let's say someone deploys it in their network and
they have a clean edge-core-edge architecture - TRILL only
runs in the core; traffic from edge ports is encap'ed and
transported over the TRILL core.  There are 100's, perhaps
1000's of VLANs at the edges.  I start out with per-VLAN
IS-IS hellos going out all ports (core and edge), but
in the core I only have one VLAN.  I find that my CPU is
having trouble keeping up (because of many edge ports
and many VLANs on each of those ports).  
I figure IS-IS is not really
buying me much at the edges so I turn it off on all those
ports.  Things look and work great!  Next, I have a 
misconfiguration in my network (the kind that we've 
been talking about all along).  Now, with per-VLAN IS-IS
off, I have no way to detect it -- bad stuff happens
forever!!!  With the single instance running, I would at 
least have detected a problem and alerted the network operator.

The burden we would impose with per-VLAN IS-IS is
unrealistic.  I urge you to give it a second thought.

Routers have come a long way today with distributed
control plane architectures, but those push the cost
of equipment up.

If we have to allow per-VLAN IS-IS messages they
should be optional.
 
Anoop

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 12 Aug 2007 08:29:45 -0700

Anoop,

I am not asking to do per-VLAN hello only.
I am not prohibiting a shared Hello,
I am just saying that since we don't have implementation experience on
the shared hello it should not be the default solution.

You are unrealistic asking to have as a default solution something that
is not completely understood.

-- Silvano

> Sent: Saturday, August 11, 2007 4:55 PM
with
tagged
> > with
> > > all the VLAN tags
> > >
> > >
> > > anoop> We're doing things to detect those corner cases where
things
> > are

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 13 Aug 2007 10:48:57 -0700

Hi Silvano,

By making per-VLAN IS-IS hellos the default
we will pretty much be limiting RBridge 
technology to only high-end devices (or
low end devices will only be able to support
a handful of VLANs).  This bothers me a lot.

The correctness of the algorithm is also 
of concern which is why we're having these
discussions about the single IS-IS instance.
We have found one corner case where it is
possible for frame duplication to happen
for a short period of time.  I don't think 
this is a deal breaker. Why not?  Because 
it is possible to get small frame duplication
even in 802.1 networks running RSTP.  

(With STP it is possible to completely 
eliminate this, but convergence is a lot 
slower.  See Annex K of 802.1D-2004.)

Anoop 

> Sent: Sunday, August 12, 2007 8:30 AM
> I am just saying that since we don't have implementation 
> experience on the shared hello it should not be the default solution.
> 
> You are unrealistic asking to have as a default solution 
> something that is not completely understood.
> 
> -- Silvano
> 
> > > with all the VLAN tags
> one may get 
> > > applications is FCoE (Fibre Channel over Ethernet). You 
> don't want 
> > > to have duplicated SCSI frames.
> > 
> misconfigured 
> > and that too for a limited time (i.e. until the misconfiguration is 
> > detected).
> > 
> > > 2) There is also the issue pointed out by James Carlson: "if the 
> > > user has two RBridges (R1 and R2) attached to the same Ethernet 
> > > subnetwork, and R1 supports only VLANs {A,B} while
> > > R2 supports only VLANs {A,C}, then neither one can 
> actually be the 
> > > DRB for that whole network."
> > 
> > This is not an issue because (and I think Radia has already pointed 
> > this out) we can always run the DRB election per VLAN or 
> per group of 
> > VLANs over the base instance.
> > 
> > > 3) There are many other corner cases, but to point them 
> out I need 
> > > the pseudo-code you intend to use. If you post it and 
> give me some 
> > Let's take a hypothetical scenario and say we go with per 
> VLAN hellos.  
> > Let's say someone deploys it in their network and they have a clean 
> > edge-core-edge architecture - TRILL only runs in the core; traffic 
> > from edge ports is encap'ed and transported over the TRILL core.  
> > There are 100's, perhaps 1000's of VLANs at the edges.  I start out 
> > with per-VLAN IS-IS hellos going out all ports (core and 
> edge), but in 
> > the core I only have one VLAN.  I find that my CPU is 
> having trouble 
> > keeping up (because of many edge ports and many VLANs on 
> each of those 
> > ports).
> > buying me much at the edges so I turn it off on all those ports.  
> > Things look and work great!  Next, I have a misconfiguration in my 
> > network (the kind that we've been talking about all along). 
>  Now, with 
> > per-VLAN IS-IS off, I have no way to detect it -- bad stuff happens 
> > forever!!!  With the single instance running, I would at least have 
> > detected a problem and alerted the network operator.
> > 
> > Routers have come a long way today with distributed control plane 
> > architectures, but those push the cost of equipment up.
> > 
> > If we have to allow per-VLAN IS-IS messages they should be optional.
> > 
> > Anoop
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 13 Aug 2007 12:56:02 -0700

What is the zero configuration behavior of a bridge
with VLANs? Is it to support all VLANs?
Or just one? And if just one, which one?

We seem to only be arguing about what the default configuration should be.
Assuming the bridge zero configuration is to only support one VLAN, then
it seems like the only possible "zero configuration" case is to only support
one VLAN, and to only send IS-IS Hellos on that VLAN.

So since support for other VLANs requires configuration, it doesn't seem too
important which case ("add VLAN  *with* sending Hellos" or "add VLAN 
"without
sending extra Hellos") is the default.

I'm also not sure whether we've worked out the details of how it works 
if each of
the RBridges on a layer 2 cloud are sending Hellos on different subsets 
of the VLANs.

I wrote out all the details when all RBridges send on a single VLAN,
and I think we also know what all the details are when all RBridges send 
on all VLANs that they support. I'm not sure we understand what is 
supposed to happen if, say, each VLAN is sending Hellos on a different 
subset of the VLANs.

One thing I'm sure of in that case is that regardless of what VLAN tags 
you use when you transmit a Hello, you should accept a Hello on any 
VLAN. But I think we need to write it all out carefully if each RBridge 
is configured to send on different VLANs.

Radia

Anoop Ghanwani wrote:
>>>> Subject: RE: [rbridge] Avoiding sending multiple IS-IS 
>>>>         
>> Hellos tagged 
>>     
>>>> with all the VLAN tags
>>>>
>>>>
>>>> Anoop,
>>>>
>>>>         
>>>>> silvano> But you have failed to prove that "these things"
>>>>>           
>>>> are robust.
>>>>         
>>>>> silvano>
>>>>> silvano> Sending a Hello on each VLAN is robust and it
>>>>>           
>>>> should be the
>>>>         
>>>>> duplication of traffic for a short period (probably a 
>>>>>           
>> few seconds) 
>>     
>>>>> until the misconfiguration is detected.  I think this 
>>>>>           
>> is adequate.
>>     
>>>> I strongly disagree.
>>>>
>> give me some 
>>>> time, I'll find the corner case.
>>>>
>>>> In general I think optimizations are better dealt with in 
>>>>         
>> the second 
>>     
>>>> version of the protocol.
>>>>         
>> unrealistic.  I urge 
>>> you to give it a second thought.
>>>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 13 Aug 2007 13:50:20 -0700

Radia,

The default configuration of an 802.1Q bridge
would be all ports in VLAN 1 only.  With some
vendors the default is that the ports are
all disabled and you have to explicity assign
a port to a VLAN to actually get it to do
something.

It seems you're saying an RBridge would
support both mechanisms from the standpoint 
of receiving messages, but may support
only one mode for transmission.  The problem with
that is that the device that didn't implement
per-VLAN hello transmission would probably not
have the ability to sink that volume of per-VLAN
hellos either (although it is less burdensome
than having to do both the transmit and receive
function).

Anoop 

> Sent: Monday, August 13, 2007 12:56 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Eastlake III Donald-LDE008; rbridge at postel.org
> What is the zero configuration behavior of a bridge with 
> VLANs? Is it to support all VLANs?
> Assuming the bridge zero configuration is to only support one 
> VLAN, then it seems like the only possible "zero 
> configuration" case is to only support one VLAN, and to only 
> send IS-IS Hellos on that VLAN.
> 
> So since support for other VLANs requires configuration, it 
> doesn't seem too important which case ("add VLAN  *with* 
> sending Hellos" or "add VLAN "without sending extra Hellos") 
> is the default.
> 
> I'm also not sure whether we've worked out the details of how 
> it works if each of the RBridges on a layer 2 cloud are 
> sending Hellos on different subsets of the VLANs.
> 
> I wrote out all the details when all RBridges send on a 
> single VLAN, and I think we also know what all the details 
> are when all RBridges send on all VLANs that they support. 
> I'm not sure we understand what is supposed to happen if, 
> say, each VLAN is sending Hellos on a different subset of the VLANs.
> 
> One thing I'm sure of in that case is that regardless of what 
> VLAN tags you use when you transmit a Hello, you should 
> accept a Hello on any VLAN. But I think we need to write it 
> all out carefully if each RBridge is configured to send on 
> different VLANs.
> 
> Radia
> 
> 
> Anoop Ghanwani wrote:
> > Hi Silvano,
> >
> > By making per-VLAN IS-IS hellos the default we will pretty much be 
> > limiting RBridge technology to only high-end devices (or low end 
> > devices will only be able to support a handful of VLANs).  This 
> > bothers me a lot.
> >
> > The correctness of the algorithm is also of concern which 
> is why we're 
> > having these discussions about the single IS-IS instance.
> > We have found one corner case where it is possible for frame 
> > duplication to happen for a short period of time.  I don't 
> think this 
> > is a deal breaker. Why not?  Because it is possible to get 
> small frame 
> > duplication even in 802.1 networks running RSTP.
> >
> > (With STP it is possible to completely eliminate this, but 
> convergence 
> > is a lot slower.  See Annex K of 802.1D-2004.)
> >
> > Anoop
> >
> >   
> experience 
> >> on the shared hello it should not be the default solution.
> >>
> >> You are unrealistic asking to have as a default solution something 
> >> that is not completely understood.
> >>
> >> -- Silvano
> >>
> >>     
> least have

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 13 Aug 2007 23:52:20 -0400

Radia,

A zero configuration 802.1Q bridge will ingress frames tagged with any
VLAN ID. In addition, when it receives untagged or priority tagged
frames, it will accept them and associate them with VLAN 1. Egressing
frames, however, is a whole different matter. At an 802.1Q bridge, VLANs
have a member set of the ports that are considered to be in that VLAN.
The zero configuration situation is that all ports are in the member set
of VLAN 1 and only VLAN 1 and are set to send frames associated with
VLAN 1 as untagged. A port can be added to the member set for other
VLANs by configuration or by receipt of a GVRP (GARP VLAN Registration
Protocol) message. If you are doing things by dynamic configuration, the
idea is that an end station that was going to send frames tagged as in
VLAN X or a bridge with one or more ports configured to associate
untagged or priority tagged frames with VLAN X would send GVRP messages
along the spanning tree (or trees for MSTP) so that appropriate bridge
ports along the spanning tree are put in their bridge's member set for
VLAN X so as to establish full VLAN X connectivity. With GVRP
implemented and used as intended in 802.1Q, there wouldn't be isolated
islands of VLAN X stations and 802.1Q bridges would be able to prune
based on what VLANs have downstream stations. 802.1Q bridges are
prohibited from egressing a frame in VLAN X on a port which is not in
the member set for that VLAN.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Monday, August 13, 2007 4:50 PM
To: Radia Perlman
Cc: Silvano Gai; Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with all the VLAN tags

Radia,

all disabled and you have to explicitly assign

Anoop

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 14 Aug 2007 22:22:50 -0700

So...if I understand Donald's explanation, it seems like the zero
configuration case is to send untagged frames and receive packets
tagged with any VLAN.

That seems like there is no choice: the zero configuration case is
to only send Hellos untagged.

But then bridges and RBridges, through
configuration, can support other VLANs.
At that point
when we say "support VLAN 215", would we want that to mean that
you should *also* send Hellos tagged with VLAN 215? That seems like the
only point of disagreement. Proposal "A" is no matter how many VLANs we
might support, we'd only send Hellos with VLAN 1/untagged (and perhaps
with extra configuration, we can say "not only support VLAN 215, but
send Hellos on it"). Proposal
"B" is that once we say "support VLAN 215, it also means we send Hellos 
on 215,
with perhaps extra configuration to say "but don't send Hellos on 215".

Those two do not seem very different to me -- supporting anything other than
VLAN 1 requires configuration, so hopefully we can reach consensus on 
something soon.

Whatever we do, if we allow any configuration other than "always
send all IS-IS Hellos untagged (or VLAN 1), then we might wind up
with a case where different RBridges are sending with different VLAN tags.

So here's an attempt at writing how that would work.

a) accept Hellos tagged with any VLAN tag

b) in your Hello, in which you list the IS-IS neighbors you
have heard Hellos from, list at least one VLAN tag for each neighbor
with which you have heard a Hello.

!!!Question: should you list *all* VLAN
tags that you've heard from that neighbor? Or is it fine to just list one?
I'd suggest that you should list only one: the lowest numbered VLAN that 
you've heard
from that neighbor on?!!!

c) If the DRB reports that it
hears you on VLAN ni, and you were sending
Hellos on {n1, n2, n3, n4, n5, ..}, you can stop sending on all the
other VLANs, and just send on ni

d) Perhaps the goal would be to just send on VLAN 1, so if you were
sending on VLANs 1, 2, 3, 4, and 5, and the DRB reports it heard you
on 3, then you should continue sending on 3 and 1, hoping eventually
it will hear you on 1 so you can stop sending on 3. Our assumption
will be that the only reason VLAN 1 is partitioned is because of
misconfiguration, so we'd like to have it stabilize to only sending on
1 if possible.

e) For each other RBridge Ri, Rj keeps track of the lowest numbered VLAN
that Rj hear Hellos on from Ri. Way this is VLAN 17.
When forwarding encapsulated packets to Ri, Rj tags them with VLAN 17.

!!!Question: If Rj hears Hellos from Ri tagged with VLAN 17, does that
mean that Ri can hear Rj when Rj marks things with VLAN 17?!!!

f) As with the design we already have -- if Ri needs to send to Rj (with 
neither being DRB), and
Rj has not reported that it can hear Ri, then Ri sends to the DRB when 
it needs to
forward to Rj

g) As with the design we already have -- the DRB reports in the 
pseudonode LSP the VLANs
on which that DRB is designated for that LAN, and the root bridge for
that set of VLANs. (!!!Question:  With multiple spanning trees, is it 
possible to
get different root bridges for each of the spanning trees? In that case 
the pseudonode might
have to report {(root bridge {set of VLANs}, root bridge {set of VLANs})!!!
If you see an LSP for a pseudonode with the same root bridge and VLAN 
that you think
you are DRB for, then (depending on some tie-breaker based on IS-IS 
system ID), you
stop forwarding traffic marked with that VLAN tag to/from that link

h) As with the design we already have, to avoid loops, DRB R1 does not 
decapsulate
a packet with ingress R2 unless R1 has R2's LSP and LSPs for all 
pseudonodes for which R2 is
DRB

i) As with the design we already have, to avoid temporary duplication, 
when DRB R1 first
comes up, R1 does not
start forwarding packets off the LAN until R1 has synchronized LSP 
datases with each of
its neighbors

**************
So, the goal of the above is that even if everyone sends on lots of
VLANs, it converges to sending on just VLAN 1 if at all possible.

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 15 Aug 2007 11:39:31 -0700

a) on a port involving transporting frames between bridges, where the 
port is
allowed for forwarding any VLANs, would the bridges be configured to enable
all 4000 VLANs? If so...would that mean that most of the "core links" 
between
RBridges would be enabled for 4000 VLANs? (and for our purposes, if 
there are
*only* RBridges (as in, no bridges, no end stations) on a link, then 
there is no
need to support any VLANs on that link. And if there are just endnodes 
(no bridges), then I'd guess
most likely there would just be one or two VLANs enabled on the link. 
But the question
is what happens with bridge to bridge links that are allowed to carry 
any VLAN? That I think
would be a common case, and if it means that the bridges are configured 
to support all 4000 VLANs,
wouldn't that mean that the RBridges would have to be as well? I don't 
think we'd want to
send 4000 Hellos in that case.

b) Can we assume that connectivity with VLAN tag x is commutative on a 
link, as in,
if RB1 can hear RB2 when RB2 sends a Hello tagged with VLAN x, does that 
mean that RB2
can hear RB1 when RB1 sends a Hello tagged with VLAN x? (and I know that if
RB1's transmitter is broken, that would mean that regardless of VLAN 
tag, RB1 can hear
RB2, but not vice versa. But what I'm asking is, is it possible for RB1 
to hear RB2 when
RB2 transmits with VLAN x, but RB2 can only hear RB1 when RB1 transmits with
VLAN y?

Thanks,

Radia

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 15 Aug 2007 17:22:01 -0700

> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Wednesday, August 15, 2007 11:40 AM
> Subject: [rbridge] Questions about VLANs
> 
> 
> a) on a port involving transporting frames between bridges, 
> where the port is allowed for forwarding any VLANs, would the 
> bridges be configured to enable all 4000 VLANs? If so...would 
> that mean that most of the "core links" 
> between
> RBridges would be enabled for 4000 VLANs? (and for our 
> purposes, if there are
> *only* RBridges (as in, no bridges, no end stations) on a 
> link, then there is no need to support any VLANs on that 
> link. And if there are just endnodes (no bridges), then I'd 
> guess most likely there would just be one or two VLANs 
> enabled on the link. 
> But the question
> is what happens with bridge to bridge links that are allowed 
> to carry any VLAN? That I think would be a common case, and 
> if it means that the bridges are configured to support all 
> 4000 VLANs, wouldn't that mean that the RBridges would have 
> to be as well? I don't think we'd want to send 4000 Hellos in 
> that case.

Some vendors require you to explicitly configure all VLANs
that need to be supported on a port; others have a single
command that designates the port as a trunk and then
an optional "exclude" list can be provided.  And yes, it's
quite common to see bridge to bridge links with many
VLANs.  If the other end of that link is an RBridge then
the Rbridge would have to be configured with all of
those VLANs and would have to send hellos for all of them.
And that is precisely the scenario that I'm concerned
about.

> b) Can we assume that connectivity with VLAN tag x is 
> commutative on a link, as in, if RB1 can hear RB2 when RB2 
> sends a Hello tagged with VLAN x, does that mean that RB2 can 
> hear RB1 when RB1 sends a Hello tagged with VLAN x? (and I 
> know that if RB1's transmitter is broken, that would mean 
> that regardless of VLAN tag, RB1 can hear RB2, but not vice 
> versa. But what I'm asking is, is it possible for RB1 to hear RB2 when
> RB2 transmits with VLAN x, but RB2 can only hear RB1 when RB1 
> transmits with VLAN y?

Because ingress filtering is an optional function, it
_is_ possible to build one-way communication topologies
(a port by defaults accept traffic from all VLANs, but
only transmits on VLAN1).  If I have ingress filtering
off and I have port p1 with VLAN membership v1, and
port p2 with VLAN membership v1, v2, and ingress filtering
is off, a device on p1 will be able send a frame to
a device on p2 on VLAN v2, but the device on p2 wouldn't
be able to send traffic to the device on p2 on v2.

That said, I doubt there are any networks that deploy 
VLANs in this way.

Anoop

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 16 Aug 2007 10:56:25 -0700

Donald,

I think that what you are saying is equivalent to: "by default a bridge
forwards only VLAN 1, but it receives management frames on any other
VLAN". 

To emulate this behavior, there is the need to send ONLY one ISIS hello.

-- Silvano

> From: Eastlake III Donald-LDE008 [mailto:Donald.Eastlake at motorola.com]
> Sent: Monday, August 13, 2007 8:52 PM
> To: Anoop Ghanwani; Radia Perlman
with
> > >> You are unrealistic asking to have as a default solution
something
the

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 16 Aug 2007 16:42:22 -0400

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Wednesday, August 15, 2007 1:23 AM
To: rbridge at postel.org
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with all the VLAN tags

@@@ Yes, frames that are, while inside the bridge, associated with VLAN
1 are the only ones emitted and they are sent untagged. They could have
been received as untagged, priority tagged, or tagged as VLAN 1.

@@@ Untagged as far as VLAN goes. For the most rapid topology
convergence, I still think that if there might be intervening bridges,
Hellos should be sent priority tagged with the maximum priority, 7.

Those two do not seem very different to me -- supporting anything other
than
VLAN 1 requires configuration, so hopefully we can reach consensus on 
something soon.

Whatever we do, if we allow any configuration other than "always
send all IS-IS Hellos untagged (or VLAN 1), then we might wind up
with a case where different RBridges are sending with different VLAN
tags.

!!!Question: should you list *all* VLAN
tags that you've heard from that neighbor? Or is it fine to just list
one?
I'd suggest that you should list only one: the lowest numbered VLAN that

you've heard

@@@ I think it should be OK to list just one. For example, assume that
RB-a and RB-b are connected by a bridged LAN and are configured on their
ports to egress tagged native frames for VLAN 2 and 3 and to send Hellos
on those VLANs. (If they are also sending untagged frames, assume they
won't get through either way.) If the bridged LAN is providing full
connectivity, they should both see both Hellos, report VLAN 2, and
settle on using VLAN 2 tagged TRILL frames to communicate. Even if the
bridged LAN is acting like a pair of diodes and, for these ports, only
VLAN 2 gets from RB-a to RB-b but only VLAN 3 gets from RB-b to RB-a,
this is quite obvious and the Rbridges can communicate with appropriate
tagged frames. (It is left as an exercise for the reader to show that
other combinations of diodes, etc., work as long at least one tagging of
Hellos can get through in each direction.)

@@@ A few things occur to me thinking about this: If some Hellos are
getting through from RB-a to RB-b, and vice versa, then what RB-a wants
to know from RB-b is the "tagging" (or rather at least one of the
taggings) with which RB-a is sending Hellos that get through. It could
be that, if RB-a is sending frames tagged as VLAN 3, the tagging is
being stripped and they are being successfully received by RB-b but in
an untagged form. It could be that, of all the Hellos RB-a is sending on
this port, only the untagged ones are getting through to RB-b in which
case they might be arriving at RB-b untagged or tagged as being in some
arbitrary VLAN X. It could be that the only Hellos emitted by RB-a on
this port that get to RB-b are those sent tagged as VLAN X but they
arrive at RB-b tagged as VLAN Y. (This last is, I think, much less
likely than the others so we may not want to go to any extra trouble to
fix it but I think the same solution as for the other cases fixes it
also.)

@@@ All these cases point to a requirement that the outer VLAN tagging
status of a TRILL core IS-IS Hello when it is emitted must be noted
inside the TRILL encapsulation somewhere. The obvious place to put this
in the current design would be the inner VLAN tag but we have already
decided to use that to indicate per VLAN IS-IS messages as distinguished
from core IS-IS. (All of this discussion is about core instance IS-IS
Hellos.) This leaves approximately three choices: (1) revise the design
so that core versus per VLAN IS-IS instances are distinguished by a
TRILL Header flag bit and the inner VLAN tag in a core IS-IS Hellos
indicates the VLAN with which it was initially sent; (2) put the initial
VLAN tagging ID info inside the Hellos; or (3) something even more
disruptive to the current design. (Minor note: you would need some way
to indicate that a frame was not tagged with a VLAN ID. The obvious way
to do this is with the null VLAN ID, zero, as is done in a priority
tag.)

@@@ You don't have to worry about this for any other IS-IS PDUs besides
Hellos. The Hellos would map the topology and tell you what tagging to
use for other IS-IS PDU types. You don't have to worry about this for
any optional per VLAN IS-IS instances. They use the core IS-IS
determined topology and transport.

@@@ Also, if you can tell there are no intervening bridges, which I
believe can be fairly easily determined with 802.1AB, then just sending
truly untagged TRILL IS-IS frames is the way to go; there is no reason
to even priority tag them.

@@@ Nope, as above and per later message from Anoop, you can easily
configure diodes.

neither being DRB), and

have to report {(root bridge {set of VLANs}, root bridge {set of
VLANs})!!!

@@@ Yes, I believe that with Multiple STP (MSTP) you can get one root
bridge per spanning tree out a port. Seems like it would be pretty messy
to take this into account. This also relates to just what the Rbridge
port is doing with respect to *STP. It's pretty easy to just listen for
STP or RSTP BPDUs and grab the root bridge. For an MSTP BPDU, you can
equally easily grab the CIST root (CIST = Common and Internal Spanning
Tree) but it is not immediately clear to me if that is adequate. Each
MSTP BPDU can also have a variable number of multiple spanning tree
instance regional root identifiers in it...

@@@ Donald

**************

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sat, 18 Aug 2007 23:45:12 -0700

Some thoughts...

Remind me again what was wrong with the rule "you participate in the 
bridge spanning tree
algorithm, and become DRB if and only if you are root bridge".? That 
seems to avoid the
necessity of sending 4000 Hellos, or specifying in the Hellos "these are 
all the VLAN
tags I can hear each of my neighbors on".

I guess if you want to do load splitting so that R1 is DRB for VLAN A 
and R2 is DRB for
VLAN B that might be tricky if there's only one spanning tree instance 
on the layer 2 cloud.

But it does seem as though "become DRB iff you are the root of the 
spanning tree" is the
most robust solution. It doesn't seem to require sending Hellos for 
every possible VLAN tag.

Also, having multiple DRBs for load splitting -- shouldn't we be scared 
about the case where
bridge configuration can turn a VLAN A tag into a VLAN B tag?

Radia

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 19 Aug 2007 20:56:40 -0700

Radia,

You need to understand what type of ST is run in the network.
If it is per-VLAN ST, you need to send 4,000 BPDUs, worst than sending
4000 Hellos.
If you don't understand the ST configuration, you will have loops.

-- Silvano

P.S. I don't know why we are so stubborn on the 4000. By default there
is only VLAN 1 and we have other VLANs only if explicitly configured.

> Sent: Saturday, August 18, 2007 11:45 PM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Anoop Ghanwani; rbridge at postel.org
with

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 20 Aug 2007 10:57:29 -0700

> Sent: Sunday, August 19, 2007 8:57 PM
> To: Radia Perlman
> If it is per-VLAN ST, you need to send 4,000 BPDUs, worst 
> than sending 4000 Hellos.

Thought it might be useful to point out that per-VLAN ST
is a proprietary technology.

> P.S. I don't know why we are so stubborn on the 4000. By 
> default there is only VLAN 1 and we have other VLANs only if 
> explicitly configured.

Because most folks won't use the switch with it's default
configuration.  They configure many VLANs (100's is very 
typical) before actually deploying in the network.

Anoop

> > bridge spanning tree algorithm, and become DRB if and only 
> if you are 
> > root bridge".? That seems to avoid the necessity of sending 4000 
> > Hellos, or specifying in the Hellos "these
> are
> > all the VLAN
> > and R2 is DRB for VLAN B that might be tricky if there's only one 
> > spanning tree instance on the layer 2 cloud.
> > 
> > spanning tree" is the most robust solution. It doesn't seem 
> to require 
> > sending Hellos for every possible VLAN tag.
> >

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 20 Aug 2007 11:06:25 -0700

> Remind me again what was wrong with the rule "you participate 
> in the bridge spanning tree algorithm, and become DRB if and 
> only if you are root bridge".? That seems to avoid the 
> necessity of sending 4000 Hellos, or specifying in the Hellos 
> "these are all the VLAN tags I can hear each of my neighbors on".

There is no problem with that (at least not one
that I can see).  In fact, that would address
Dinesh's problem very well.  The only issue is that it
imposes on the user a network design issue which says:
"if you have RBridges in the network, then one of
them is going to be your STP root."  This may or
may not be desireable based on the network design.

> I guess if you want to do load splitting so that R1 is DRB 
> for VLAN A and R2 is DRB for VLAN B that might be tricky if 
> there's only one spanning tree instance on the layer 2 cloud.
> 
> But it does seem as though "become DRB iff you are the root 
> of the spanning tree" is the most robust solution. It doesn't 
> seem to require sending Hellos for every possible VLAN tag.
> 
> Also, having multiple DRBs for load splitting -- shouldn't we 
> be scared about the case where bridge configuration can turn 
> a VLAN A tag into a VLAN B tag?

I don't think this is a concern.  First off, a standard
bridge does not swap C-tags.  This function is only
allowed for S-tags.  That said, this is a feature that
must be carefully configured/managed by the operator.

Basically a VLAN A tag in one portion of the network
is equivalent to the VLAN B tag in the other portion
of the network.  This tends to be useful when joining
two networks; e.g. if I have 2 networks X & Y with VLANs
1-100 configured and I want to join them, at the
bridge that joins them, I will translate VLAN X's
1-100 so that they show up at 1001-1100 in VLAN Y's
network, and vice versa.

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 22 Aug 2007 16:15:03 -0400

So, thinking some more about what I said below, about only reporting the
lowest numbered VLAN seen in Hellos from a particular other Rbridge, I
was considering only the pairwise case. If it is just two Rbridges with
a bridged LAN between then, then indeed reporting only the lowest
numbered VLAN on which you heard a Hello from a neighbor in fine. But
this is insufficient in the general case. Consider the following
symmetric connectivity

 RB    VLANs    RB
  A     2, 3     B
  A        3     C

If RB-A and RB-B just report the lowest numbered VLAN on which they see
each other, it will be VLAN 2. But for RB-A and RB-C, it would be VLAN
3. However, if RB-A multicasts on both VLAN 2 and 3, which the
information would indicate it should, RB-B will get two copies. In this
case, RB-A should only multicast on VLAN 3, but it can't tell that.

Donald

-----Original Message-----
Sent: Thursday, August 16, 2007 4:42 PM

See below at @@@

-----Original Message-----

...

you've heard

...

@@@ Donald

---

From: james.d.carlson at sun.com (James Carlson)
Date: Wed, 22 Aug 2007 16:46:13 -0400

> case, RB-A should only multicast on VLAN 3, but it can't tell that.

I think this could still be made to work by having the RBs remove
VLANs from their candidate set of lowest-common-VLAN numbers as they
see Hellos disproving the original contention.

Thus, when RB-A sees VLAN 2 from RB-B, it tentatively believes this to
be the lowest common number.  When it sees VLAN 3 from RB-C, it must
now eliminate all those candidate VLANs less then 3 (just ID 2 in this
example) and start upwards from there -- now saying that VLAN 3 is the
minimum.

If you get to 4095, then there's nothing in common; stop and report
error.

You could make it more robust by including the minimum VLAN number
along with the "LAN ADDRESS" Intermediate System Neighbours in the
Hello.  When RB-A sends a Hello indicating that it can hear RB-C on
a minimum VLAN 3, RB-B knows that numbers below 3 aren't useful.

If someone actually configures a system where 4094 really is the
minimum common VLAN and all the others are allocated, well, I think he
gets what he deserves.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 30 Aug 2007 19:04:58 -0700

I'm not sure it matters to find a common VLAN. I think what matters for 
non-DRBs is
that the DRB hears you. What matters for the DRB is that all the other 
RBs hears you.

So for instance, it might be that DRB R1 transmits on {2, 3, and 4}, and 
R3 can't hear VLAN 2,
and R2 can't hear VLAN 2. It could be that if everyone transmitted on 
VLAN 4 that everyone
would hear each other, but that by the "reporting lowest VLAN ID" R1 
convinces R2 to send
Hellos on VLAN 2 and convinces R3 to send Hellos on VLAN 3, that it will 
wind up
that when R2 needs to forward to R3 on that layer 2 cloud there will be 
a one-hop suboptimality
(since when R2 needs to forward to R3 it will send to the DRB, R1).
Frankly, I don't care about that case. It works...it's just suboptimal. 
And if some customer
has specifically created partitioned VLANs consciously through careful 
configuration of
bridges, and they care about the one hop suboptimality, they can 
configure the RBridges to all
talk on 4.

I was also worried about how long an IS-IS Hello that applied to lots of 
different VLANs
might become in the most general conceivable case, if in one Hello R1 
announced a bunch
of different priorities, and then for each priority, a set of VLANs it 
applied to, with the VLAN
tags such that there was no way to aggregate them.

So I'd propose to say that if an RBridge is configured to have a 
different priority for one set
of VLANs than another, it will issue a different Hello. And also, that 
the VLANs for which
you are a particular priority must be in one range. The only reason to 
have multiple priorities
is for load splitting, and so there's no reason for standing one our 
head to allow someone to
configure priority x for all the even VLANs and y for all the odd VLANs.

So that means that a Hello will contain "my priority, range of VLAN tags 
this Hello applies to"
(where "range" is a low number and a high number of the range of VLAN 
tags, so it's only
4 bytes).

And there is also the list of neighbors you have heard Hellos from, 
along with the lowest
VLAN tag that you've heard from them. You *could* transmit on all the 
potential VLAN
tags you need in order to talk to all the neighbors reported in the 
DRB's Hello. So, in the
example in the 2nd paragraph above, R1 (the DRB) announces it hears from 
R2 on VLAN 2
and R3 on VLAN 3. We then could specify that R2 just transmits on VLAN 
2, and
R3 just transmits on VLAN 3. Or we could say that if R2 sees another 
non-DRB listed
in R1's Hello and R2 doesn't hear that one, that R2 could try sending 
Hellos on other
VLAN tags to see if it can create an adjacency to R3. But again, I'd 
have R2 declare
victory if R2 found a VLAN tag that the DRB can hear it on, and have R2 
just transmit
on a single VLAN tag (until it loses connectivity to the DRB).

So the rule I'm proposing is
a) initially there might be a set of VLAN tags to transmit on. This is 
either that the default
is to transmit on every VLAN tag that you support on that layer 2 cloud, 
or that the default
is to only transmit untagged, or on VLAN tag 1, and you have to be 
configured to transmit on more
VLANs than that. If you are configured (or the default is that) to only 
transmit with one VLAN
tag, then we don't need b)

b) if you are configured with a different priority for one set of VLANs 
than another, you
transmit a separate Hello for each priority, listing the range of VLANs 
that Hello applies to.
If you believe yourself to be DRB, then you continue to send on all the 
VLANs that you
are configured to send on for that priority. If you lose the DRB 
election for some set of
VLANs, then you only transmit on the VLAN tag that the DRB says to 
transmit on.
One bizarreness is that R1 might be priority 5 for VLANs {a, b, c, d, e, 
f, g}, and
R2 might be priority 4 for VLANs {a, b, c,} and priority 6 for {d, e, f, g}.
In that case (assuming lower number priority wins), R1 will be DRB for 
VLANs {d,e,f,g}
and R2 would be DRB for VLANs {a, b, c}. And in R1's pseudonode it only 
reports
{d,e,f,g} as attached VLANs, and R2 reports {a, b, c}

We need to come up with a concrete proposal for all these things, and 
hopefully soon. I think
we haven't reached consensus, though I don't think anyone's opinions 
differ by a lot. I think
the only contentious thing is what the default is.

Anyway, this is long enough -- see if people agree with this, which is 
basically a proposal
for having the DRB always send on all the VLANs it is configured to send 
Hellos on, and
non-DRBs start sending on all the VLANs they are configured to send 
Hellos on, but stop
when the DRB lets them know of a VLAN tag that works, and thenceforth 
only sends
on that one VLAN tag.

Radia