Subject: [rbridge] inner tag always an s-tag?

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 20 Sep 2007 10:47:55 -0700

This is a long overdue followup on whether
or not it is OK to have the inner tag always
be an s-tag.  The issue was brought up by 
Donald at the TRILL meeting in Chicago:
http://www3.ietf.org/proceedings/07jul/slides/trill-3/sld7.htm

The argument in favor of doing this was that
it allows us to get a DE (discard eligible) bit.

I was opposed to this.  The reason is that we
should preserve whatever inner tag was received
from the attached LAN.  RBridges could be attached
to LANs that actually use s-tags, or they could
be attached to LANs that use c-tags.  We need
to preserve what was originally received.

Also, if in future, IEEE comes up with some 
other way to use the CFI bit and if we need to 
use that within the RBridge network, we would have
to find a new place to carry that bit.

Finally, even with the c-tag format, we do 
have the capability to signal drop eligibility.
It is just encoded within the PCP (what used
to be called the priority and is now the priority
code point) so it reduces the number of priorities,
but if it's OK for bridges, it's probably going
to be OK for RBridges as well. 

Anoop

Content-class: urn:content-classes:message
Date: Thu, 20 Sep 2007 10:47:55 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] inner tag always an s-tag?
Status: RO
Content-Length: 1124

This is a long overdue followup on whether
or not it is OK to have the inner tag always
be an s-tag.  The issue was brought up by 
Donald at the TRILL meeting in Chicago:
http://www3.ietf.org/proceedings/07jul/slides/trill-3/sld7.htm

The argument in favor of doing this was that
it allows us to get a DE (discard eligible) bit.

I was opposed to this.  The reason is that we
should preserve whatever inner tag was received
from the attached LAN.  RBridges could be attached
to LANs that actually use s-tags, or they could
be attached to LANs that use c-tags.  We need
to preserve what was originally received.

Also, if in future, IEEE comes up with some 
other way to use the CFI bit and if we need to 
use that within the RBridge network, we would have
to find a new place to carry that bit.

Finally, even with the c-tag format, we do 
have the capability to signal drop eligibility.
It is just encoded within the PCP (what used
to be called the priority and is now the priority
code point) so it reduces the number of priorities,
but if it's OK for bridges, it's probably going
to be OK for RBridges as well. 

Anoop

Content-class: urn:content-classes:message
Date: Thu, 20 Sep 2007 09:05:18 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 1021

> -----Original Message-----
> From: Dinesh G Dutt [mailto:[email-masked]] 
> Sent: Wednesday, September 19, 2007 11:32 PM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> Anoop,
> 
> Anoop Ghanwani wrote:
> > And so is this.  Basically, from the perspective of what we 
> are trying 
> > to accomplish with MSTP, we could just listen to the 
> messages for the 
> > CIST (common and internal spanning
> > tree) which is the spanning tree that goes across all spanning tree 
> > regions and forwards traffic to VLANs that is not mapped to 
> any of the 
> > other instances.
> >   
> What you're saying then is that the DRB must be the root of 
> CIST, not of VLAN 1. Am I right ?

Hi Dinesh,

That's not what I'm trying to say at all.  All I'm
saying is that all RBridges (designated or not)
report who the root is for the CIST.  This is basically
to figure out whether they are connected to the same
LAN.

Anoop

Date: Thu, 20 Sep 2007 08:09:17 -0700
From: Dinesh G Dutt <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 1022

The statement pertained to which VLAN the DRB election is held on, not 
the VLAN on which the traffic is transported. I think this was for the 
case of doing DRB on a single VLAN,

Dinesh
Silvano Gai wrote:
> ... snip ...
>
>
>   
>>> *****************
>>> And as for allowing configuration to be some other VLAN other than 1
>>> -- that makes things
>>> complicated, because what do you do if some of the RBridges on a
>>>       
> cloud
>   
>>> are configured differently
>>> from others?
>>>       
>> I agree. I prefer to not provide a configurable option on this, but I
>> can foresee people complain,
>>
>>     
>
>
> Let's be realistic, if a customer has access to an existing VLAN 7 on a
> backbone and he wants to connect two RBridges to it, we are going to
> disallow it?
>
> Disallowing reasonable configuration by standard is never an option.
>
> -- Silvano
>
>   

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

Content-class: urn:content-classes:message
Date: Thu, 20 Sep 2007 07:59:42 -0700
From: "Silvano Gai" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 943

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Dinesh G Dutt
> Sent: Wednesday, September 19, 2007 11:32 PM
> To: Anoop Ghanwani
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> Anoop,
> 
> Anoop Ghanwani wrote:
> > And so is this.  Basically, from the perspective of what
> > we are trying to accomplish with MSTP, we could just listen
> > to the messages for the CIST (common and internal spanning
> > tree) which is the spanning tree that goes across all
> > spanning tree regions and forwards traffic to VLANs that is
> > not mapped to any of the other instances.
> >
> What you're saying then is that the DRB must be the root of CIST, not
of
> VLAN 1. Am I right ?

I disagree that the DRB must be the root of the CIST.
This imposes severe restrictions on interoperability.

-- Silvano

Content-class: urn:content-classes:message
Date: Thu, 20 Sep 2007 07:58:09 -0700
From: "Silvano Gai" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 608

... snip ...

> >
> > *****************
> > And as for allowing configuration to be some other VLAN other than 1
> > -- that makes things
> > complicated, because what do you do if some of the RBridges on a
cloud
> > are configured differently
> > from others?
> I agree. I prefer to not provide a configurable option on this, but I
> can foresee people complain,
> 

Let's be realistic, if a customer has access to an existing VLAN 7 on a
backbone and he wants to connect two RBridges to it, we are going to
disallow it?

Disallowing reasonable configuration by standard is never an option.

-- Silvano

Date: Wed, 19 Sep 2007 23:31:38 -0700
From: Dinesh G Dutt <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 626

Anoop,

Anoop Ghanwani wrote:
> And so is this.  Basically, from the perspective of what
> we are trying to accomplish with MSTP, we could just listen
> to the messages for the CIST (common and internal spanning
> tree) which is the spanning tree that goes across all
> spanning tree regions and forwards traffic to VLANs that is
> not mapped to any of the other instances.
>   
What you're saying then is that the DRB must be the root of CIST, not of 
VLAN 1. Am I right ?

Dinesh

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

Date: Wed, 19 Sep 2007 22:51:35 -0700
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 2682

Hi Radia,

Radia Perlman wrote:
> Dinesh G Dutt wrote:
>>
>> Will it need to support both (three if you include the currently 
>> dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP 
>> (Cisco's PVST is IEEE's STP run per VLAN).
> How different are these? How much trouble is it to listen to all the 
> variants? I assumed they
> were all interoperable. What happens if there is a bridged network 
> with bridges that
> support different of these variants?
Don't know how different things are. MSTP/RSTP can interoperate with 
older STP, I believe.
>
> From what I remember of "original STP" and "RSTP", listening to them 
> should be identical.
> RSTP uses the same message formats, and is the same protocol other 
> than adding loop prevention
> messages. So I'd assume if you are listening, it wouldn't matter if it 
> was STP vs RSTP.
The PDUs look different between MSTP and regular STP.
>
> MSTP, if I understand it correctly, involves noticing that different 
> bridges are root for different
> VLANs. However, maybe we can ignore that, and only listen to messages 
> for the spanning
> tree for VLAN 1. I'm assuming we can do that -- someone should correct 
> me if I'm wrong. The
> other plausible alternative is to listen to all the spanning trees, 
> and if you're doing load splitting
> of DRBs (one for VLANs 1-50, and the other for VLANs 51-79, say), then 
> in the pseudonode
> representing VLANs 1-50, you'd list the root bridges for the spanning 
> tree associated with
> each of the VLANs 1 through 50.
>
>
> As for your description of "PVST" -- again, the implication might be 
> that if you have a pseudonode
> representing all the VLANs, you'd have to list, in that pseudonode, a 
> different bridge ID since
> (if I understand what PVST is from your one phrase above), there might 
> be a different root
> bridge ID for each of those.
>
> But...I *thought* that the spanning tree is guaranteed not to be 
> partitioned, so listing just the
> root of the spanning tree corresponding to VLAN 1 should be all you 
> need in order to detect
> that there's an RBridge on the same link that you're not hearing 
> Hellos from, right?
I think you maybe right here.
>
> *****************
> And as for allowing configuration to be some other VLAN other than 1 
> -- that makes things
> complicated, because what do you do if some of the RBridges on a cloud 
> are configured differently
> from others?
I agree. I prefer to not provide a configurable option on this, but I 
can foresee people complain,

Dinesh

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

Content-class: urn:content-classes:message
Date: Wed, 19 Sep 2007 18:59:24 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 2624

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Monday, September 17, 2007 8:24 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> So, just to summarize what I think the proposed solution is, 
> plus a couple of questions interspersed, marked with ???
> 
> a) on each layer 2 cloud, all RBrdge-RBridge communication 
> (including IS-IS Hellos and encapsulated data packet 
> forwarding) will be sent with one VLAN tag.
> 
> ???question: Which VLAN tag?  untagged? VLAN 1? Something 
> else? And is that the
> *only* VLAN tag, or is it a default, and RBridges could be 
> configured to send on a different VLAN tag? (I'd prefer 
> picking one and not have it be configurable)???
> 
> b) it will be a MUST to listen to spanning tree messages and 
> include the root bridge ID in the pseudonode LSP. Also,

And the root bridge ID in the case where MSTP is enabled
is that of the CIST.

It must also include in the list of VLANs reachable on
that pseudonode and what is configured as the "RBridge 
control VLAN".  The list of VLANs reachable is later 
used for doing DRB election.

> c) if R1 notices a pseudonode with a root bridge that is the 
> same as a link that R1 thinks
> R1 is designated on, R1 does not forward data to/from that 
> link if R1's 6-byte IS-IS ID is less than the ID of  the DRB 
> for that pseudonode
> 
> d) if R1 is DRB on a link, R1 will not decapsulate anything 
> onto the link from ingress R2 unless
> R1 has received an LSP from R2 and all pseudonodes that R2 
> claims to be attached to, and that R2 claims to be DRB for
> 
> e) when R1 first comes up, it waits some amount of time on a 
> link before deciding that it is DRB (several Hello 
> intervals), and after becoming DRB, it still does not forward 
> data off the link until it has synchronized LSP databases 
> with its neighbors. "Synchronizing" 
> means that it receives
> a CSNP from the neighbor, and winds up with LSPs at least as 
> up-to-date as those reported in that CSNP. (Note: I think it 
> would be a good idea to have a flag in the Hello message 
> saying "I'd like to receive a CSNP from you" in case the 
> neighbor sent one and it got lost -- on a LAN, the DRB should 
> be sending them periodically, but if we have pt-to-pt links 
> at least in current IS-IS, CSNPs are not sent periodically, 
> though we could say RBridges should send them periodically on 
> pt-to-pt links.)
> 
> So...is this pretty much everyone's understanding of how it 
> should work?

Content-class: urn:content-classes:message
Date: Wed, 19 Sep 2007 18:40:29 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Dinesh G Dutt" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 3423

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Tuesday, September 18, 2007 6:12 PM
> To: Dinesh G Dutt
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> Dinesh G Dutt wrote:
> >
> > Will it need to support both (three if you include the currently 
> > dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP 
> > (Cisco's PVST is IEEE's STP run per VLAN).
> How different are these? How much trouble is it to listen to 
> all the variants? I assumed they were all interoperable. What 
> happens if there is a bridged network with bridges that 
> support different of these variants?
> 
>  From what I remember of "original STP" and "RSTP", listening 
> to them should be identical.
> RSTP uses the same message formats, and is the same protocol 
> other than adding loop prevention messages. So I'd assume if 
> you are listening, it wouldn't matter if it was STP vs RSTP.

This is correct.

> MSTP, if I understand it correctly, involves noticing that 
> different bridges are root for different VLANs. However, 
> maybe we can ignore that, and only listen to messages for the 
> spanning tree for VLAN 1. I'm assuming we can do that -- 
> someone should correct me if I'm wrong. The other plausible 
> alternative is to listen to all the spanning trees, and if 
> you're doing load splitting of DRBs (one for VLANs 1-50, and 
> the other for VLANs 51-79, say), then in the pseudonode 
> representing VLANs 1-50, you'd list the root bridges for the 
> spanning tree associated with each of the VLANs 1 through 50.

And so is this.  Basically, from the perspective of what
we are trying to accomplish with MSTP, we could just listen
to the messages for the CIST (common and internal spanning
tree) which is the spanning tree that goes across all
spanning tree regions and forwards traffic to VLANs that is
not mapped to any of the other instances.
 
> As for your description of "PVST" -- again, the implication 
> might be that if you have a pseudonode representing all the 
> VLANs, you'd have to list, in that pseudonode, a different 
> bridge ID since (if I understand what PVST is from your one 
> phrase above), there might be a different root bridge ID for 
> each of those.
>
> But...I *thought* that the spanning tree is guaranteed not to 
> be partitioned, so listing just the root of the spanning tree 
> corresponding to VLAN 1 should be all you need in order to 
> detect that there's an RBridge on the same link that you're 
> not hearing Hellos from, right?
> 
> *****************
> And as for allowing configuration to be some other VLAN other 
> than 1 -- that makes things complicated, because what do you 
> do if some of the RBridges on a cloud are configured 
> differently from others?

The only problem with using VLAN 1 only is that it
may require an operator to renumber their VLAN 
configuration if VLAN 1 is being used for something
other than what we would like it to be used for.

One way to handle misconfiguration would be to 
say that, if this condition is detected, then we
use the lower numbered VLAN and the one with the
higher numbered VLAN logs a misconfiguration error
and goes silent.  A misconfiguration is detected
if the root/VLAN combination reported for the same
pseudonode by 2 RBridges is different.

Anoop

Date: Tue, 18 Sep 2007 18:12:15 -0700
From: Radia Perlman <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 2132

Dinesh G Dutt wrote:
>
> Will it need to support both (three if you include the currently 
> dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP 
> (Cisco's PVST is IEEE's STP run per VLAN).
How different are these? How much trouble is it to listen to all the 
variants? I assumed they
were all interoperable. What happens if there is a bridged network with 
bridges that
support different of these variants?

 From what I remember of "original STP" and "RSTP", listening to them 
should be identical.
RSTP uses the same message formats, and is the same protocol other than 
adding loop prevention
messages. So I'd assume if you are listening, it wouldn't matter if it 
was STP vs RSTP.

MSTP, if I understand it correctly, involves noticing that different 
bridges are root for different
VLANs. However, maybe we can ignore that, and only listen to messages 
for the spanning
tree for VLAN 1. I'm assuming we can do that -- someone should correct 
me if I'm wrong. The
other plausible alternative is to listen to all the spanning trees, and 
if you're doing load splitting
of DRBs (one for VLANs 1-50, and the other for VLANs 51-79, say), then 
in the pseudonode
representing VLANs 1-50, you'd list the root bridges for the spanning 
tree associated with
each of the VLANs 1 through 50.

As for your description of "PVST" -- again, the implication might be 
that if you have a pseudonode
representing all the VLANs, you'd have to list, in that pseudonode, a 
different bridge ID since
(if I understand what PVST is from your one phrase above), there might 
be a different root
bridge ID for each of those.

But...I *thought* that the spanning tree is guaranteed not to be 
partitioned, so listing just the
root of the spanning tree corresponding to VLAN 1 should be all you need 
in order to detect
that there's an RBridge on the same link that you're not hearing Hellos 
from, right?

*****************
And as for allowing configuration to be some other VLAN other than 1 -- 
that makes things
complicated, because what do you do if some of the RBridges on a cloud 
are configured differently
from others?

Radia

Date: Tue, 18 Sep 2007 08:04:18 -0700
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 2209

Hi Radia,

Some comments.

Radia Perlman wrote:
> So, just to summarize what I think the proposed solution is, plus a 
> couple of questions
> interspersed, marked
> with ???
>
> a) on each layer 2 cloud, all RBrdge-RBridge communication (including
> IS-IS Hellos and encapsulated data packet forwarding) will be sent with 
> one VLAN tag.
>
> ???question: Which VLAN tag?  untagged? VLAN 1? Something else? And is 
> that the
> *only* VLAN tag, or is it a default, and RBridges could be configured to 
> send on a different
> VLAN tag? (I'd prefer picking one and not have it be configurable)???
>
>   
VLAN 1 and I prefer it to be the only one, but maybe configurable. The 
frame must be tagged, not untagged as it leads to all kinds of corner 
cases.
> b) it will be a MUST to listen to spanning tree messages and include the 
> root bridge ID
> in the pseudonode LSP. Also,
>
>   
Will it need to support both (three if you include the currently 
dominant model, Cisco's) spanning tree protocols, IEEE STP and MSTP 
(Cisco's PVST is IEEE's STP run per VLAN).
> c) if R1 notices a pseudonode with a root bridge that is the same as a 
> link that R1 thinks
> R1 is designated on, R1 does not forward data to/from that link if R1's 
> 6-byte IS-IS ID
> is less than the ID of  the DRB for that pseudonode
>   
Need to think through this one.
> d) if R1 is DRB on a link, R1 will not decapsulate anything onto the 
> link from ingress R2 unless
> R1 has received an LSP from R2 and all pseudonodes that R2 claims to be 
> attached to,
> and that R2 claims to be DRB for
>   
Need to think through this one.
> e) when R1 first comes up, it waits some amount of time on a link before 
> deciding that it is DRB
> (several Hello intervals), and after becoming DRB, it still does not 
> forward data off the link until
> it has synchronized LSP databases with its neighbors. "Synchronizing" 
>   
This could cause a significant delay in bringing an RBridge up and how 
things work when a network is powered down and comes up. I'm not sure 
about this part yet.

Dinesh

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

Content-class: urn:content-classes:message
Date: Tue, 18 Sep 2007 07:18:48 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 8265

Radia,

I need to sudy your proposal in details, but the answer to your question
is easy: " By default is VLAN 1 and it is configurable".

VLAN 1 is the default of IEEE, and you cannot forbid with a standard to
config it.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Monday, September 17, 2007 8:24 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> So, just to summarize what I think the proposed solution is, plus a
> couple of questions
> interspersed, marked
> with ???
> 
> a) on each layer 2 cloud, all RBrdge-RBridge communication (including
> IS-IS Hellos and encapsulated data packet forwarding) will be sent
with
> one VLAN tag.
> 
> ???question: Which VLAN tag?  untagged? VLAN 1? Something else? And is
> that the
> *only* VLAN tag, or is it a default, and RBridges could be configured
to
> send on a different
> VLAN tag? (I'd prefer picking one and not have it be configurable)???
> 
> b) it will be a MUST to listen to spanning tree messages and include
the
> root bridge ID
> in the pseudonode LSP. Also,
> 
> c) if R1 notices a pseudonode with a root bridge that is the same as a
> link that R1 thinks
> R1 is designated on, R1 does not forward data to/from that link if
R1's
> 6-byte IS-IS ID
> is less than the ID of  the DRB for that pseudonode
> 
> d) if R1 is DRB on a link, R1 will not decapsulate anything onto the
> link from ingress R2 unless
> R1 has received an LSP from R2 and all pseudonodes that R2 claims to
be
> attached to,
> and that R2 claims to be DRB for
> 
> e) when R1 first comes up, it waits some amount of time on a link
before
> deciding that it is DRB
> (several Hello intervals), and after becoming DRB, it still does not
> forward data off the link until
> it has synchronized LSP databases with its neighbors. "Synchronizing"
> means that it receives
> a CSNP from the neighbor, and winds up with LSPs at least as
up-to-date
> as those reported
> in that CSNP. (Note: I think it would be a good idea to have a flag in
> the Hello message saying "I'd
> like to receive a CSNP from you" in case the neighbor sent one and it
> got lost -- on a LAN,
> the DRB should be sending them periodically, but if we have pt-to-pt
> links at least in current IS-IS,
> CSNPs are not sent periodically, though we could say RBridges should
> send them periodically
> on pt-to-pt links.)
> 
> So...is this pretty much everyone's understanding of how it should
work?
> 
> Radia
> 
> 
> 
> 
> Dinesh G Dutt wrote:
> > I agree to Radia's points with the addition of Silvano's points,
> >
> > Dinesh
> > Silvano Gai wrote:
> >> In the spirit of making progress, I am OK with this with the
addition
> >> that:
> >>
> >> 1) we don't generate BPDUs trying to become the root of the
Spanning
> >> Tree.
> >>
> >> 2) we don't care about temporary loops generated by repeaters
> (repeaters
> >> don't exist at 1 and 10 Gb/s), but we avoid all other temporary
loops.
> >>
> >> 3) Frame duplication is also a big deal, clearly unacceptable in
steady
> >> state, need to be analyzed carefully in transient: better to drop
than
> >> to duplicate.
> >>
> >> -- Silvano
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: [email-masked]
[mailto:[email-masked]]
> >>>
> >> On
> >>
> >>> Behalf Of Radia Perlman
> >>> Sent: Friday, September 14, 2007 12:18 PM
> >>> To: Erik Nordmark
> >>> Cc: Developing a hybrid router/bridge.
> >>> Subject: Re: [rbridge] Ambition with different VLAN configurations
> >>>
> >>> . I think we should only make sure that in odd configurations
there
> >>>
> >> are
> >>
> >>> no loops. We should
> >>> not worry about partitions caused by nontransitive connectivity.
> >>>
> >>> . I think we should go to some amount of trouble to ensure there
are
> >>>
> >> not
> >>
> >>> even temporary loops (not
> >>> just "no permanent loops".
> >>>
> >>> . It would be nice to say "never ever have any loops", but I don't
> >>>
> >> think
> >>
> >>> that's possible, given
> >>> repeaters coming up, messages getting lost, a bridge or RBridge
> >>> exhibiting bizarre behavior
> >>> due to some bug, etc. That has nothing to do with TRILL -- any
design
> >>> might occasionally
> >>> wind up with a loop in low probability events, and we should make
sure
> >>> that the probability
> >>> is very low and minimize the length of time/effect if things go
wrong.
> >>>
> >>> . I prefer a design in which there should be one VLAN tag (the
default
> >>> one) that
> >>> is not partitioned on a layer 2 cloud, and all RBridge-RBridge
> >>> communication on that cloud
> >>> (including Hello messages)
> >>> should have that VLAN tag on the outside, and if that VLAN is
indeed
> >>> partitioned, then
> >>> all but one RBridge, even if elected to be DRB on some set of
VLANs,
> >>> will refrain from
> >>> forwarding data to/from the link.
> >>>
> >>> Radia
> >>>
> >>> Erik Nordmark wrote:
> >>>
> >>>> The list has had discussions on how to do hellos with VLANs, and
the
> >>>> discussion makes me wonder whether we have agreement on the level
of
> >>>> ambition with various unusual VLAN configuration in the bridged
> >>>>
> >> LANs.
> >>
> >>>> By "ambition" I mean whether in a particular case we should:
> >>>> 1. Make RBridges provide full connectivity for all the nodes in
the
> >>>> bridged LAN
> >>>> 2. Make RBridges at least detect that there is something odd
about
> >>>>
> >> the
> >>
> >>>> VLAN configuration and ensure that no permanent loops can be
formed.
> >>>>
> >> But
> >>
> >>>> it would be ok to orphan some nodes from communicating.
> >>>>
> >>>> One can ask that question for different VLAN scenarios.
> >>>> One interesting case that Donald brought up is when there isn't a
> >>>>
> >> single
> >>
> >>>> VLAN tag on which all the RBridges can communicate.
> >>>> For instance, RB0 and RB1 can only send and receive using VLAN
tag
> >>>>
> >> 3.
> >>
> >>>> RB2 can only send and receive using VLAN tag 4.
> >>>> RB3 and RB4 can send and receive using both VLAN tag 3 and 4.
> >>>>
> >>>> There are different schemes for making hellos detect the
> >>>>
> >> connectivity in
> >>
> >>>> this case. So let's ignore that and instead look at the
implications
> >>>>
> >> on
> >>
> >>>> the data plane if we want ambition #1.
> >>>>
> >>>> Suppose RB4 has a multicast to send to all RBridges. Which VLAN
tag
> >>>> should it use? There isn't a single VLAN tag that it can use
> >>>>
> >> whichever
> >>
> >>>> reach all RBridge neighbors. But RB4 can't treat the port as two
> >>>> logically different ports (one for VLAN tag 3 and a separate one
for
> >>>>
> >> 4)
> >>
> >>>> either, since RB2 is a neighbor for both VLANs.
> >>>> Thus if we wanted this case to provide full connectivity it would
> >>>>
> >> seem
> >>
> >>>> like the data plane would need to be able to duplicate packets
and
> >>>>
> >> send
> >>
> >>>> some unicast; a possible strategy would be to multicast with tag
3,
> >>>>
> >> and
> >>
> >>>> then unicast a copy to RB2 (with tag 4). That way all the
> >>>>
> >> neighboring
> >>
> >>>> RBridges would receive the frame.
> >>>>
> >>>> That sounds complex.
> >>>>
> >>>> There might be other examples of odd VLAN configuration (such as
> >>>>
> >> bridges
> >>
> >>>> which untag and then add some other tag when forwarding the
frame)
> >>>>
> >> which
> >>
> >>>> are complex to fully support. What level of ambition should we
have
> >>>>
> >> for
> >>
> >>>> the odd cases?
> >>>>
> >>>>     Erik
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> [email-masked]
> >>>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [email-masked]
> >>> http://mailman.postel.org/mailman/listinfo/rbridge
> >>>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Date: Mon, 17 Sep 2007 20:23:53 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 7325

So, just to summarize what I think the proposed solution is, plus a 
couple of questions
interspersed, marked
with ???

a) on each layer 2 cloud, all RBrdge-RBridge communication (including
IS-IS Hellos and encapsulated data packet forwarding) will be sent with 
one VLAN tag.

???question: Which VLAN tag?  untagged? VLAN 1? Something else? And is 
that the
*only* VLAN tag, or is it a default, and RBridges could be configured to 
send on a different
VLAN tag? (I'd prefer picking one and not have it be configurable)???

b) it will be a MUST to listen to spanning tree messages and include the 
root bridge ID
in the pseudonode LSP. Also,

c) if R1 notices a pseudonode with a root bridge that is the same as a 
link that R1 thinks
R1 is designated on, R1 does not forward data to/from that link if R1's 
6-byte IS-IS ID
is less than the ID of  the DRB for that pseudonode

d) if R1 is DRB on a link, R1 will not decapsulate anything onto the 
link from ingress R2 unless
R1 has received an LSP from R2 and all pseudonodes that R2 claims to be 
attached to,
and that R2 claims to be DRB for

e) when R1 first comes up, it waits some amount of time on a link before 
deciding that it is DRB
(several Hello intervals), and after becoming DRB, it still does not 
forward data off the link until
it has synchronized LSP databases with its neighbors. "Synchronizing" 
means that it receives
a CSNP from the neighbor, and winds up with LSPs at least as up-to-date 
as those reported
in that CSNP. (Note: I think it would be a good idea to have a flag in 
the Hello message saying "I'd
like to receive a CSNP from you" in case the neighbor sent one and it 
got lost -- on a LAN,
the DRB should be sending them periodically, but if we have pt-to-pt 
links at least in current IS-IS,
CSNPs are not sent periodically, though we could say RBridges should 
send them periodically
on pt-to-pt links.)

So...is this pretty much everyone's understanding of how it should work?

Radia

Dinesh G Dutt wrote:
> I agree to Radia's points with the addition of Silvano's points,
>
> Dinesh
> Silvano Gai wrote:
>> In the spirit of making progress, I am OK with this with the addition
>> that:
>>
>> 1) we don't generate BPDUs trying to become the root of the Spanning
>> Tree.
>>
>> 2) we don't care about temporary loops generated by repeaters (repeaters
>> don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops.
>>
>> 3) Frame duplication is also a big deal, clearly unacceptable in steady
>> state, need to be analyzed carefully in transient: better to drop than
>> to duplicate.
>>
>> -- Silvano
>>
>>
>>  
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>>     
>> On
>>  
>>> Behalf Of Radia Perlman
>>> Sent: Friday, September 14, 2007 12:18 PM
>>> To: Erik Nordmark
>>> Cc: Developing a hybrid router/bridge.
>>> Subject: Re: [rbridge] Ambition with different VLAN configurations
>>>
>>> . I think we should only make sure that in odd configurations there
>>>     
>> are
>>  
>>> no loops. We should
>>> not worry about partitions caused by nontransitive connectivity.
>>>
>>> . I think we should go to some amount of trouble to ensure there are
>>>     
>> not
>>  
>>> even temporary loops (not
>>> just "no permanent loops".
>>>
>>> . It would be nice to say "never ever have any loops", but I don't
>>>     
>> think
>>  
>>> that's possible, given
>>> repeaters coming up, messages getting lost, a bridge or RBridge
>>> exhibiting bizarre behavior
>>> due to some bug, etc. That has nothing to do with TRILL -- any design
>>> might occasionally
>>> wind up with a loop in low probability events, and we should make sure
>>> that the probability
>>> is very low and minimize the length of time/effect if things go wrong.
>>>
>>> . I prefer a design in which there should be one VLAN tag (the default
>>> one) that
>>> is not partitioned on a layer 2 cloud, and all RBridge-RBridge
>>> communication on that cloud
>>> (including Hello messages)
>>> should have that VLAN tag on the outside, and if that VLAN is indeed
>>> partitioned, then
>>> all but one RBridge, even if elected to be DRB on some set of VLANs,
>>> will refrain from
>>> forwarding data to/from the link.
>>>
>>> Radia
>>>
>>> Erik Nordmark wrote:
>>>    
>>>> The list has had discussions on how to do hellos with VLANs, and the
>>>> discussion makes me wonder whether we have agreement on the level of
>>>> ambition with various unusual VLAN configuration in the bridged
>>>>       
>> LANs.
>>  
>>>> By "ambition" I mean whether in a particular case we should:
>>>> 1. Make RBridges provide full connectivity for all the nodes in the
>>>> bridged LAN
>>>> 2. Make RBridges at least detect that there is something odd about
>>>>       
>> the
>>  
>>>> VLAN configuration and ensure that no permanent loops can be formed.
>>>>       
>> But
>>  
>>>> it would be ok to orphan some nodes from communicating.
>>>>
>>>> One can ask that question for different VLAN scenarios.
>>>> One interesting case that Donald brought up is when there isn't a
>>>>       
>> single
>>  
>>>> VLAN tag on which all the RBridges can communicate.
>>>> For instance, RB0 and RB1 can only send and receive using VLAN tag
>>>>       
>> 3.
>>  
>>>> RB2 can only send and receive using VLAN tag 4.
>>>> RB3 and RB4 can send and receive using both VLAN tag 3 and 4.
>>>>
>>>> There are different schemes for making hellos detect the
>>>>       
>> connectivity in
>>  
>>>> this case. So let's ignore that and instead look at the implications
>>>>       
>> on
>>  
>>>> the data plane if we want ambition #1.
>>>>
>>>> Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag
>>>> should it use? There isn't a single VLAN tag that it can use
>>>>       
>> whichever
>>  
>>>> reach all RBridge neighbors. But RB4 can't treat the port as two
>>>> logically different ports (one for VLAN tag 3 and a separate one for
>>>>       
>> 4)
>>  
>>>> either, since RB2 is a neighbor for both VLANs.
>>>> Thus if we wanted this case to provide full connectivity it would
>>>>       
>> seem
>>  
>>>> like the data plane would need to be able to duplicate packets and
>>>>       
>> send
>>  
>>>> some unicast; a possible strategy would be to multicast with tag 3,
>>>>       
>> and
>>  
>>>> then unicast a copy to RB2 (with tag 4). That way all the
>>>>       
>> neighboring
>>  
>>>> RBridges would receive the frame.
>>>>
>>>> That sounds complex.
>>>>
>>>> There might be other examples of odd VLAN configuration (such as
>>>>       
>> bridges
>>  
>>>> which untag and then add some other tag when forwarding the frame)
>>>>       
>> which
>>  
>>>> are complex to fully support. What level of ambition should we have
>>>>       
>> for
>>  
>>>> the odd cases?
>>>>
>>>>     Erik
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [email-masked]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>       
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>     
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>   
>

Content-class: urn:content-classes:message
Date: Mon, 17 Sep 2007 01:36:56 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Amit Gupta" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] RSTP BRIDGE not receiving BPDUs
Status: RO
Content-Length: 10100

This is a multi-part message in MIME format.

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

I believe that if any of STP, RSTP, or MSTP is enabled on a port, then
BPDUs will be sent periodically regardless of whether any BPDUs are
being received.
=20
Donald

________________________________

From: Amit Gupta [mailto:[email-masked]]=20
Sent: Thursday, August 23, 2007 11:28 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] RSTP BRIDGE not receiving BPDUs

The scenario here is that the2 bridges are connected in a ring topology
with eaps providing the ring protection while RSTP is providing the
uplink/downlink protection. The reason the other port is not receiving
the BPDU is because the EAPS is blocking one of the links to avoid loops
in the ring.Thus even though the each bridge has 2 paths 2 reach the
other but at any given time will only be able to receive BPDU from the
path that is not blocked by EAPS. so thats why I was wondering what
state/role would be the port that is not receiving the BPDU.=20
Will it keep sending the Hello BPDU even though it is not receiving any
?
=20

________________________________

From: Eastlake III Donald-LDE008 [mailto:[email-masked]]
Sent: Thu 8/23/2007 6:28 PM
To: Amit Gupta
Cc: [email-masked]
Subject: RE: [rbridge] RSTP BRIDGE not receiving BPDUs

Well, I'm sure there are people on this list who could help you but this
is really not the 802.1 mailing list, which would seem more appropriate.
=20
It is a generally characteristic of STP protocols that the loss of
frames leads to ports becoming enabled. So, while I am not an RSTP
expert, I would guess that in the normal case the port not receiving
BPDUs would end up in Forwarding state and would believe itself to be
root unless their is a better root visible out some other port...
=20
But I could be wrong and maybe I am misunderstanding you.... I am
assuming you mean "2 bridges are interconnected and of the 2 ports only
1 port on *one* bridge is receiving BPDU's" but in your statement in the
message below, you say "each" rather than "one" which seems
inconsistent.
=20
On wonders what is blocking the BPDUs and why the one hop physical link
between the bridges is letting BPDUs through in only on direction and
not the other...
=20
Donald

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Amit Gupta
Sent: Thursday, August 23, 2007 8:21 PM
To: [email-masked]
Subject: Re: [rbridge] RSTP BRIDGE not receiving BPDUs

It is a very basic question. What would be the state and role of a port
if you stop receiving the RSTP BPDU's on that bridge port.

If 2 bridges are interconnected and of the 2 ports only 1 port on each
bridge is receiving BPDU's , will that cause any issues ?

=20

Thanks,

-A

=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3132" name=3DGENERATOR>
<STYLE>P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D687032700-17092007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I believe that if any of STP, RSTP, or MSTP is =
enabled on a=20
port, then BPDUs will be sent periodically regardless of whether any =
BPDUs are=20
being received.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D687032700-17092007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D687032700-17092007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Donald</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Amit Gupta =
[mailto:[email-masked]]=20
<BR><B>Sent:</B> Thursday, August 23, 2007 11:28 PM<BR><B>To:</B> =
Eastlake III=20
Donald-LDE008<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
[rbridge]=20
RSTP BRIDGE not receiving BPDUs<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV id=3DidOWAReplyText86668 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>The scenario =
here is that=20
the2 bridges are connected in a ring topology with eaps providing the =
ring=20
protection while RSTP is providing the uplink/downlink protection. The =
reason=20
the other port is not receiving the BPDU is because the EAPS is blocking =
one of=20
the links to avoid loops in the ring.Thus even though the each bridge =
has 2=20
paths 2 reach the other but at any given time will only be able to =
receive BPDU=20
from the path that is not blocked by EAPS. so thats why I was wondering =
what=20
state/role would be the port that is not receiving the BPDU. =
</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Will it keep sending the =
Hello BPDU even=20
though it is not receiving any ?</FONT></DIV>
<DIV dir=3Dltr>&nbsp;</DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Eastlake III Donald-LDE008=20
[mailto:[email-masked]]<BR><B>Sent:</B> Thu 8/23/2007 6:28 =

PM<BR><B>To:</B> Amit Gupta<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B>=20
RE: [rbridge] RSTP BRIDGE not receiving BPDUs<BR></FONT><BR></DIV>
<DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>Well, I'm sure there are people on this list =
who could=20
help you but this is really not the 802.1 mailing list, which would seem =
more=20
appropriate.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>It is a generally characteristic of STP =
protocols that=20
the loss of frames leads to ports becoming enabled. So, while I am not =
an RSTP=20
expert, I would guess that in the normal case the port not receiving =
BPDUs would=20
end up in Forwarding state and would believe itself to be root unless =
their is a=20
better root visible out some other port...</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>But I could be wrong and maybe I am =
misunderstanding=20
you.... I am assuming you mean "2 bridges are interconnected and of the =
2 ports=20
only 1 port on *one* bridge is receiving BPDU&#8217;s" but in your =
statement in the=20
message below, you say "each" rather than "one" which seems=20
inconsistent.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>On wonders what is blocking the BPDUs and why =
the one=20
hop physical link between the bridges is letting BPDUs through in only =
on=20
direction and not the other...</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D965551701-24082007>Donald</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Amit=20
Gupta<BR><B>Sent:</B> Thursday, August 23, 2007 8:21 PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Re: [rbridge] RSTP BRIDGE not =
receiving=20
BPDUs<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It is a very =
basic=20
question. </SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">What would be the state =
and role of=20
a port if you stop receiving the RSTP BPDU&#8217;s on that bridge=20
port.</SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">If 2 bridges are =
interconnected and=20
of the 2 ports only 1 port on each bridge is receiving BPDU&#8217;s , =
will that cause=20
any issues ?</SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks,</SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">-A</SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C7F8EC.C2EEED17--

Content-class: urn:content-classes:message
Date: Mon, 17 Sep 2007 01:36:55 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 3245

It's just a recommendation in the IEEE 802.1Q-2005 Standard as quoted
below.

Donald

>From IEEE 802.1Q-2005, Section 8.8.3, "Dynamic Filtering Entries", page
56:

The ageing out of Dynamic Filtering Entries ensures that end stations
that have been moved to a different part of the network will not be
permanently prevented from receiving frames. It also takes account of
changes in the active topology of the network that can cause end
stations to appear to move from the point of view of the bridge; i.e.,
the path to those end stations subsequently lies through a different
Bridge Port.

The Ageing Time may be set by management (Clause 12). A range of
applicable values and a recommended default is specified in Table 8-3;
this is suggested to remove the need for explicit configuration in most
cases. If the value of Ageing Time can be set by management, the Bridge
shall have the capability to use values in the range specified, with a
granularity of 1 s.

              Table 8-3-Ageing time parameter value

    Parameter        Recommended Default Value        Range
   Ageing Time         300.0 s.                     10.0 - 1,000,000.0s

NOTE 4-The granularity is specified in order to establish a common basis
for the granularity expressed in the management operations defined in
Clause 12, not to constrain the granularity of the actual timer
supported by a conformant implementation. If the implementation supports
a granularity other than 1 s, then it is possible that the value read
back by management following a Set operation will not match the actual
value expressed in the Set.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 7:30 PM
To: James Carlson
Cc: Eastlake III Donald-LDE008; [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers

James Carlson wrote:
> Joe Touch writes:
>> James Carlson wrote:
>>> Instead, our role is to design TRILL, and specify what's _required_
to
>>> make that work.  Is there an issue here that, if someone had a good
>>> reason to use some other set of defaults for these parameters, doing
>>> so would break TRILL?
>> I'm concerned about breaking the non-TRILL devices by TRILL behavior.
If
>> our caches have timeouts different from theirs, then the overall
system
>> won't be as plug-and-play -- or, more specifically, more
'replug-and-play'.
>>
>> That's why we're recommending IEEE values and defaults; that didn't
come
>> out of the blue.
> 
> Yes, and that's precisely the reason to "recommend" those defaults --
> as in BCP 14 "SHOULD."  I never did suggest that they came out of the
> blue or that anyone ought to ignore them.
> 
> However, as a matter of operating TRILL, they don't appear (to me at
> least) to be key issues that will cause TRILL failure.  That means
> they're not a "MUST."

That's fine. Let's hear what others think. I just want to make sure
we're picking the right one and understanding what we're picking; I
really didn't have an a-priori decision.

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

Content-class: urn:content-classes:message
Date: Mon, 17 Sep 2007 01:36:58 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: V-field reversion
Status: RO
Content-Length: 1395

Right. (I'm generally using the somewhat less formal wording from the
minutes in these consensus checks.)

Thanks,
Donald

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 9:53 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: V-field reversion

Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus at the Chicago meeting for a change from protocol draft -05:
> 
>    Eliminate different V field values and revert to two version bits
>    and two reserved bits with the previous provisions that this draft
>    specifies version zero, frames with an unknown version are
>    discarded, reserved bits MUST be zero and are ignored on receipt.

Minor nit to avoid ambiguity:

...MUST be _set to_ zero...

> If no particular controversy arises over this in the next two weeks,
we
> will declare it to be the working group consensus.
> 
> Thanks,
> Donald & Erik
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

Date: Sat, 15 Sep 2007 17:24:01 -0700
From: Dinesh G Dutt <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 5307

I agree to Radia's points with the addition of Silvano's points,

Dinesh
Silvano Gai wrote:
> In the spirit of making progress, I am OK with this with the addition
> that:
>
> 1) we don't generate BPDUs trying to become the root of the Spanning
> Tree.
>
> 2) we don't care about temporary loops generated by repeaters (repeaters
> don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops.
>
> 3) Frame duplication is also a big deal, clearly unacceptable in steady
> state, need to be analyzed carefully in transient: better to drop than
> to duplicate.
>
> -- Silvano
>
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> Sent: Friday, September 14, 2007 12:18 PM
>> To: Erik Nordmark
>> Cc: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Ambition with different VLAN configurations
>>
>> . I think we should only make sure that in odd configurations there
>>     
> are
>   
>> no loops. We should
>> not worry about partitions caused by nontransitive connectivity.
>>
>> . I think we should go to some amount of trouble to ensure there are
>>     
> not
>   
>> even temporary loops (not
>> just "no permanent loops".
>>
>> . It would be nice to say "never ever have any loops", but I don't
>>     
> think
>   
>> that's possible, given
>> repeaters coming up, messages getting lost, a bridge or RBridge
>> exhibiting bizarre behavior
>> due to some bug, etc. That has nothing to do with TRILL -- any design
>> might occasionally
>> wind up with a loop in low probability events, and we should make sure
>> that the probability
>> is very low and minimize the length of time/effect if things go wrong.
>>
>> . I prefer a design in which there should be one VLAN tag (the default
>> one) that
>> is not partitioned on a layer 2 cloud, and all RBridge-RBridge
>> communication on that cloud
>> (including Hello messages)
>> should have that VLAN tag on the outside, and if that VLAN is indeed
>> partitioned, then
>> all but one RBridge, even if elected to be DRB on some set of VLANs,
>> will refrain from
>> forwarding data to/from the link.
>>
>> Radia
>>
>> Erik Nordmark wrote:
>>     
>>> The list has had discussions on how to do hellos with VLANs, and the
>>> discussion makes me wonder whether we have agreement on the level of
>>> ambition with various unusual VLAN configuration in the bridged
>>>       
> LANs.
>   
>>> By "ambition" I mean whether in a particular case we should:
>>> 1. Make RBridges provide full connectivity for all the nodes in the
>>> bridged LAN
>>> 2. Make RBridges at least detect that there is something odd about
>>>       
> the
>   
>>> VLAN configuration and ensure that no permanent loops can be formed.
>>>       
> But
>   
>>> it would be ok to orphan some nodes from communicating.
>>>
>>> One can ask that question for different VLAN scenarios.
>>> One interesting case that Donald brought up is when there isn't a
>>>       
> single
>   
>>> VLAN tag on which all the RBridges can communicate.
>>> For instance, RB0 and RB1 can only send and receive using VLAN tag
>>>       
> 3.
>   
>>> RB2 can only send and receive using VLAN tag 4.
>>> RB3 and RB4 can send and receive using both VLAN tag 3 and 4.
>>>
>>> There are different schemes for making hellos detect the
>>>       
> connectivity in
>   
>>> this case. So let's ignore that and instead look at the implications
>>>       
> on
>   
>>> the data plane if we want ambition #1.
>>>
>>> Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag
>>> should it use? There isn't a single VLAN tag that it can use
>>>       
> whichever
>   
>>> reach all RBridge neighbors. But RB4 can't treat the port as two
>>> logically different ports (one for VLAN tag 3 and a separate one for
>>>       
> 4)
>   
>>> either, since RB2 is a neighbor for both VLANs.
>>> Thus if we wanted this case to provide full connectivity it would
>>>       
> seem
>   
>>> like the data plane would need to be able to duplicate packets and
>>>       
> send
>   
>>> some unicast; a possible strategy would be to multicast with tag 3,
>>>       
> and
>   
>>> then unicast a copy to RB2 (with tag 4). That way all the
>>>       
> neighboring
>   
>>> RBridges would receive the frame.
>>>
>>> That sounds complex.
>>>
>>> There might be other examples of odd VLAN configuration (such as
>>>       
> bridges
>   
>>> which untag and then add some other tag when forwarding the frame)
>>>       
> which
>   
>>> are complex to fully support. What level of ambition should we have
>>>       
> for
>   
>>> the odd cases?
>>>
>>>     Erik
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>       
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>     
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> 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

Content-class: urn:content-classes:message
Date: Sat, 15 Sep 2007 07:50:07 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Erik Nordmark" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 4480

In the spirit of making progress, I am OK with this with the addition
that:

1) we don't generate BPDUs trying to become the root of the Spanning
Tree.

2) we don't care about temporary loops generated by repeaters (repeaters
don't exist at 1 and 10 Gb/s), but we avoid all other temporary loops.

3) Frame duplication is also a big deal, clearly unacceptable in steady
state, need to be analyzed carefully in transient: better to drop than
to duplicate.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Friday, September 14, 2007 12:18 PM
> To: Erik Nordmark
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> . I think we should only make sure that in odd configurations there
are
> no loops. We should
> not worry about partitions caused by nontransitive connectivity.
> 
> . I think we should go to some amount of trouble to ensure there are
not
> even temporary loops (not
> just "no permanent loops".
> 
> . It would be nice to say "never ever have any loops", but I don't
think
> that's possible, given
> repeaters coming up, messages getting lost, a bridge or RBridge
> exhibiting bizarre behavior
> due to some bug, etc. That has nothing to do with TRILL -- any design
> might occasionally
> wind up with a loop in low probability events, and we should make sure
> that the probability
> is very low and minimize the length of time/effect if things go wrong.
> 
> . I prefer a design in which there should be one VLAN tag (the default
> one) that
> is not partitioned on a layer 2 cloud, and all RBridge-RBridge
> communication on that cloud
> (including Hello messages)
> should have that VLAN tag on the outside, and if that VLAN is indeed
> partitioned, then
> all but one RBridge, even if elected to be DRB on some set of VLANs,
> will refrain from
> forwarding data to/from the link.
> 
> Radia
> 
> Erik Nordmark wrote:
> > The list has had discussions on how to do hellos with VLANs, and the
> > discussion makes me wonder whether we have agreement on the level of
> > ambition with various unusual VLAN configuration in the bridged
LANs.
> >
> > By "ambition" I mean whether in a particular case we should:
> > 1. Make RBridges provide full connectivity for all the nodes in the
> > bridged LAN
> > 2. Make RBridges at least detect that there is something odd about
the
> > VLAN configuration and ensure that no permanent loops can be formed.
But
> > it would be ok to orphan some nodes from communicating.
> >
> > One can ask that question for different VLAN scenarios.
> > One interesting case that Donald brought up is when there isn't a
single
> > VLAN tag on which all the RBridges can communicate.
> > For instance, RB0 and RB1 can only send and receive using VLAN tag
3.
> > RB2 can only send and receive using VLAN tag 4.
> > RB3 and RB4 can send and receive using both VLAN tag 3 and 4.
> >
> > There are different schemes for making hellos detect the
connectivity in
> > this case. So let's ignore that and instead look at the implications
on
> > the data plane if we want ambition #1.
> >
> > Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag
> > should it use? There isn't a single VLAN tag that it can use
whichever
> > reach all RBridge neighbors. But RB4 can't treat the port as two
> > logically different ports (one for VLAN tag 3 and a separate one for
4)
> > either, since RB2 is a neighbor for both VLANs.
> > Thus if we wanted this case to provide full connectivity it would
seem
> > like the data plane would need to be able to duplicate packets and
send
> > some unicast; a possible strategy would be to multicast with tag 3,
and
> > then unicast a copy to RB2 (with tag 4). That way all the
neighboring
> > RBridges would receive the frame.
> >
> > That sounds complex.
> >
> > There might be other examples of odd VLAN configuration (such as
bridges
> > which untag and then add some other tag when forwarding the frame)
which
> > are complex to fully support. What level of ambition should we have
for
> > the odd cases?
> >
> >     Erik
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 14 Sep 2007 16:39:28 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Erik Nordmark" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 4160

I concur with Radia on all points.

Anoop 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Friday, September 14, 2007 12:18 PM
> To: Erik Nordmark
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Ambition with different VLAN configurations
> 
> . I think we should only make sure that in odd configurations 
> there are 
> no loops. We should
> not worry about partitions caused by nontransitive connectivity.
> 
> . I think we should go to some amount of trouble to ensure 
> there are not 
> even temporary loops (not
> just "no permanent loops".
> 
> . It would be nice to say "never ever have any loops", but I 
> don't think 
> that's possible, given
> repeaters coming up, messages getting lost, a bridge or RBridge 
> exhibiting bizarre behavior
> due to some bug, etc. That has nothing to do with TRILL -- any design 
> might occasionally
> wind up with a loop in low probability events, and we should 
> make sure 
> that the probability
> is very low and minimize the length of time/effect if things go wrong.
> 
> . I prefer a design in which there should be one VLAN tag 
> (the default 
> one) that
> is not partitioned on a layer 2 cloud, and all RBridge-RBridge 
> communication on that cloud
> (including Hello messages)
> should have that VLAN tag on the outside, and if that VLAN is indeed 
> partitioned, then
> all but one RBridge, even if elected to be DRB on some set of VLANs, 
> will refrain from
> forwarding data to/from the link.
> 
> Radia
> 
> Erik Nordmark wrote:
> > The list has had discussions on how to do hellos with 
> VLANs, and the 
> > discussion makes me wonder whether we have agreement on the 
> level of 
> > ambition with various unusual VLAN configuration in the 
> bridged LANs.
> >
> > By "ambition" I mean whether in a particular case we should:
> > 1. Make RBridges provide full connectivity for all the nodes in the 
> > bridged LAN
> > 2. Make RBridges at least detect that there is something 
> odd about the 
> > VLAN configuration and ensure that no permanent loops can 
> be formed. But 
> > it would be ok to orphan some nodes from communicating.
> >
> > One can ask that question for different VLAN scenarios.
> > One interesting case that Donald brought up is when there 
> isn't a single 
> > VLAN tag on which all the RBridges can communicate.
> > For instance, RB0 and RB1 can only send and receive using 
> VLAN tag 3.
> > RB2 can only send and receive using VLAN tag 4.
> > RB3 and RB4 can send and receive using both VLAN tag 3 and 4.
> >
> > There are different schemes for making hellos detect the 
> connectivity in 
> > this case. So let's ignore that and instead look at the 
> implications on 
> > the data plane if we want ambition #1.
> >
> > Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag 
> > should it use? There isn't a single VLAN tag that it can 
> use whichever 
> > reach all RBridge neighbors. But RB4 can't treat the port as two 
> > logically different ports (one for VLAN tag 3 and a 
> separate one for 4) 
> > either, since RB2 is a neighbor for both VLANs.
> > Thus if we wanted this case to provide full connectivity it 
> would seem 
> > like the data plane would need to be able to duplicate 
> packets and send 
> > some unicast; a possible strategy would be to multicast 
> with tag 3, and 
> > then unicast a copy to RB2 (with tag 4). That way all the 
> neighboring 
> > RBridges would receive the frame.
> >
> > That sounds complex.
> >
> > There might be other examples of odd VLAN configuration 
> (such as bridges 
> > which untag and then add some other tag when forwarding the 
> frame) which 
> > are complex to fully support. What level of ambition should 
> we have for 
> > the odd cases?
> >
> >     Erik
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Date: Fri, 14 Sep 2007 12:17:39 -0700
From: Radia Perlman <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 3428

. I think we should only make sure that in odd configurations there are 
no loops. We should
not worry about partitions caused by nontransitive connectivity.

. I think we should go to some amount of trouble to ensure there are not 
even temporary loops (not
just "no permanent loops".

. It would be nice to say "never ever have any loops", but I don't think 
that's possible, given
repeaters coming up, messages getting lost, a bridge or RBridge 
exhibiting bizarre behavior
due to some bug, etc. That has nothing to do with TRILL -- any design 
might occasionally
wind up with a loop in low probability events, and we should make sure 
that the probability
is very low and minimize the length of time/effect if things go wrong.

. I prefer a design in which there should be one VLAN tag (the default 
one) that
is not partitioned on a layer 2 cloud, and all RBridge-RBridge 
communication on that cloud
(including Hello messages)
should have that VLAN tag on the outside, and if that VLAN is indeed 
partitioned, then
all but one RBridge, even if elected to be DRB on some set of VLANs, 
will refrain from
forwarding data to/from the link.

Radia

Erik Nordmark wrote:
> The list has had discussions on how to do hellos with VLANs, and the 
> discussion makes me wonder whether we have agreement on the level of 
> ambition with various unusual VLAN configuration in the bridged LANs.
>
> By "ambition" I mean whether in a particular case we should:
> 1. Make RBridges provide full connectivity for all the nodes in the 
> bridged LAN
> 2. Make RBridges at least detect that there is something odd about the 
> VLAN configuration and ensure that no permanent loops can be formed. But 
> it would be ok to orphan some nodes from communicating.
>
> One can ask that question for different VLAN scenarios.
> One interesting case that Donald brought up is when there isn't a single 
> VLAN tag on which all the RBridges can communicate.
> For instance, RB0 and RB1 can only send and receive using VLAN tag 3.
> RB2 can only send and receive using VLAN tag 4.
> RB3 and RB4 can send and receive using both VLAN tag 3 and 4.
>
> There are different schemes for making hellos detect the connectivity in 
> this case. So let's ignore that and instead look at the implications on 
> the data plane if we want ambition #1.
>
> Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag 
> should it use? There isn't a single VLAN tag that it can use whichever 
> reach all RBridge neighbors. But RB4 can't treat the port as two 
> logically different ports (one for VLAN tag 3 and a separate one for 4) 
> either, since RB2 is a neighbor for both VLANs.
> Thus if we wanted this case to provide full connectivity it would seem 
> like the data plane would need to be able to duplicate packets and send 
> some unicast; a possible strategy would be to multicast with tag 3, and 
> then unicast a copy to RB2 (with tag 4). That way all the neighboring 
> RBridges would receive the frame.
>
> That sounds complex.
>
> There might be other examples of odd VLAN configuration (such as bridges 
> which untag and then add some other tag when forwarding the frame) which 
> are complex to fully support. What level of ambition should we have for 
> the odd cases?
>
>     Erik
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Date: Wed, 12 Sep 2007 10:43:37 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Ambition with different VLAN configurations
Status: RO
Content-Length: 2028

The list has had discussions on how to do hellos with VLANs, and the 
discussion makes me wonder whether we have agreement on the level of 
ambition with various unusual VLAN configuration in the bridged LANs.

By "ambition" I mean whether in a particular case we should:
1. Make RBridges provide full connectivity for all the nodes in the 
bridged LAN
2. Make RBridges at least detect that there is something odd about the 
VLAN configuration and ensure that no permanent loops can be formed. But 
it would be ok to orphan some nodes from communicating.

One can ask that question for different VLAN scenarios.
One interesting case that Donald brought up is when there isn't a single 
VLAN tag on which all the RBridges can communicate.
For instance, RB0 and RB1 can only send and receive using VLAN tag 3.
RB2 can only send and receive using VLAN tag 4.
RB3 and RB4 can send and receive using both VLAN tag 3 and 4.

There are different schemes for making hellos detect the connectivity in 
this case. So let's ignore that and instead look at the implications on 
the data plane if we want ambition #1.

Suppose RB4 has a multicast to send to all RBridges. Which VLAN tag 
should it use? There isn't a single VLAN tag that it can use whichever 
reach all RBridge neighbors. But RB4 can't treat the port as two 
logically different ports (one for VLAN tag 3 and a separate one for 4) 
either, since RB2 is a neighbor for both VLANs.
Thus if we wanted this case to provide full connectivity it would seem 
like the data plane would need to be able to duplicate packets and send 
some unicast; a possible strategy would be to multicast with tag 3, and 
then unicast a copy to RB2 (with tag 4). That way all the neighboring 
RBridges would receive the frame.

That sounds complex.

There might be other examples of odd VLAN configuration (such as bridges 
which untag and then add some other tag when forwarding the frame) which 
are complex to fully support. What level of ambition should we have for 
the odd cases?

    Erik

Date: Fri, 07 Sep 2007 16:30:04 -0700
From: Joe Touch <[email-masked]>
To: James Carlson <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 2119

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

James Carlson wrote:
> Joe Touch writes:
>> James Carlson wrote:
>>> Instead, our role is to design TRILL, and specify what's _required_ t=
o
>>> make that work.  Is there an issue here that, if someone had a good
>>> reason to use some other set of defaults for these parameters, doing
>>> so would break TRILL?
>> I'm concerned about breaking the non-TRILL devices by TRILL behavior. =
If
>> our caches have timeouts different from theirs, then the overall syste=
m
>> won't be as plug-and-play -- or, more specifically, more 'replug-and-p=
lay'.
>>
>> That's why we're recommending IEEE values and defaults; that didn't co=
me
>> out of the blue.
>=20
> Yes, and that's precisely the reason to "recommend" those defaults --
> as in BCP 14 "SHOULD."  I never did suggest that they came out of the
> blue or that anyone ought to ignore them.
>=20
> However, as a matter of operating TRILL, they don't appear (to me at
> least) to be key issues that will cause TRILL failure.  That means
> they're not a "MUST."

That's fine. Let's hear what others think. I just want to make sure
we're picking the right one and understanding what we're picking; I
really didn't have an a-priori decision.

Joe

--=20
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

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

--------------enig276CABB76B39BE5166298D45--

Date: Fri, 7 Sep 2007 13:58:31 -0400
From: James Carlson <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 1451

Joe Touch writes:
> James Carlson wrote:
> > Instead, our role is to design TRILL, and specify what's _required_ to
> > make that work.  Is there an issue here that, if someone had a good
> > reason to use some other set of defaults for these parameters, doing
> > so would break TRILL?
> 
> I'm concerned about breaking the non-TRILL devices by TRILL behavior. If
> our caches have timeouts different from theirs, then the overall system
> won't be as plug-and-play -- or, more specifically, more 'replug-and-play'.
> 
> That's why we're recommending IEEE values and defaults; that didn't come
> out of the blue.

Yes, and that's precisely the reason to "recommend" those defaults --
as in BCP 14 "SHOULD."  I never did suggest that they came out of the
blue or that anyone ought to ignore them.

However, as a matter of operating TRILL, they don't appear (to me at
least) to be key issues that will cause TRILL failure.  That means
they're not a "MUST."

I think it's an important distinction, but I suppose it's not a hill
worth dying on.  If you feel that we simply cannot proceed without a
"MUST" here, or a copy of some IEEE text, then I'll relent.  It's not
as though I was going to ignore those defaults myself anyway.

-- 
James Carlson, Solaris Networking              <[email-masked]>
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

Date: Fri, 07 Sep 2007 07:15:29 -0700
From: Joe Touch <[email-masked]>
To: James Carlson <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 1993

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

James Carlson wrote:
> Joe Touch writes:
>> James Carlson wrote:
>>> Lacking a clear interoperability issue for TRILL itself, SHOULD seems=

>>> right to me.  It means that implementations are required to follow
>>> that IEEE standard unless they've got a good reason to do otherwise.
>> I'd say MUST follow IEEE requirements.
>=20
> Where's the TRILL requirement for this?
>=20
> I'm saying SHOULD because our role here isn't to design IEEE
> protocols, nor is it to "enforce" any rules set down by IEEE.
>=20
> Instead, our role is to design TRILL, and specify what's _required_ to
> make that work.  Is there an issue here that, if someone had a good
> reason to use some other set of defaults for these parameters, doing
> so would break TRILL?

I'm concerned about breaking the non-TRILL devices by TRILL behavior. If
our caches have timeouts different from theirs, then the overall system
won't be as plug-and-play -- or, more specifically, more 'replug-and-play=
'.

That's why we're recommending IEEE values and defaults; that didn't come
out of the blue.

Joe

--=20
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

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

--------------enig45455B86B063230BCA51E469--

Date: Fri, 7 Sep 2007 06:41:50 -0400
From: James Carlson <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 2176

Joe Touch writes:
> James Carlson wrote:
> > Lacking a clear interoperability issue for TRILL itself, SHOULD seems
> > right to me.  It means that implementations are required to follow
> > that IEEE standard unless they've got a good reason to do otherwise.
> 
> I'd say MUST follow IEEE requirements.

Where's the TRILL requirement for this?

I'm saying SHOULD because our role here isn't to design IEEE
protocols, nor is it to "enforce" any rules set down by IEEE.

Instead, our role is to design TRILL, and specify what's _required_ to
make that work.  Is there an issue here that, if someone had a good
reason to use some other set of defaults for these parameters, doing
so would break TRILL?

If there's no such issue, then we don't need a "MUST."  Following the
IEEE norms becomes just an issue of good practice, and not a
fundamental requirement of the protocol.

I'm not talking about people who wantonly ignore standards.  There's
nothing we can do about that situation -- they'll ignore MUST just as
easily as they'll ignore the implication of SHOULD.  I'm talking about
requirements for TRILL itself.

> I'm wondering how the IEEE spec's the defaults; if they're a MUST, then
> why wouldn't we follow suit? How would we know what would break with
> intermediate bridges? If, alternately, the defaults are SHOULDs, then
> ours can be too.
> 
> I don't think it would be useful to diverge from those specs except
> where we deliberately need to.

I'm not suggesting creating a divergence in actual values.  I'm
suggesting that we don't need to copy the IEEE language into the TRILL
documents _unless_ there's a specific TRILL-related issue to solve.

Using SHOULD doesn't actually diverge us from IEEE, even if they use
MUST.  It provides leeway for a savvy implementor to spurn IEEE's
mandate for the good of TRILL, _if_ that's actually the right thing to
do.  It still requires others to follow IEEE if they don't have that
"good reason."

-- 
James Carlson, Solaris Networking              <[email-masked]>
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

Date: Thu, 06 Sep 2007 19:56:20 -0700
From: Joe Touch <[email-masked]>
To: John Leslie <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 1334

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

John Leslie wrote:
=2E..
>> I don't think it would be useful to diverge from those specs except
>> where we deliberately need to.
>=20
>    IMHO, we face scaling issues that IEEE does not. It may not be easy
> to foresee those effects of scaling, but we should at least leave
> ourselves wiggle room to deal with them.

Scaling is outside this work. We're not intended to scale beyond what
IEEE works for.

Joe
--=20
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

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

--------------enig2480AFCB31C1F9095EC39C67--

Date: Thu, 6 Sep 2007 21:45:47 -0400
From: John Leslie <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 1888

Joe Touch <[email-masked]> wrote:
> James Carlson wrote:
>> Joe Touch writes:
>>> Eastlake III Donald-LDE008 wrote:
>>> 
>>>> This is a check via the mailing list to confirm or refute an apparent
>>>> consensus at the Chicago meeting:
>>>>
>>>>    MAC address remembering timers in TRILL should have the same
>>>>    configuration limits and default as in 802.1Q-2005.
>> 
>>> Minor question:
>>>
>>> Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc?
>> 
>> What would be the basis of the MUST?  Is there something in TRILL that
>> falls apart if an implementation fails to heed this advice?  I don't
>> see what the exact interoperability issue would be.
>> 
>> Lacking a clear interoperability issue for TRILL itself, SHOULD seems
>> right to me.  It means that implementations are required to follow
>> that IEEE standard unless they've got a good reason to do otherwise.
> 
> I'd say MUST follow IEEE requirements.

   I agree with James: absent something which falls apart, we should
avoid a MUST.

> I'm wondering how the IEEE spec's the defaults; if they're a MUST, then
> why wouldn't we follow suit?

   IEEE specs can change; ours (effectively) can't.

> How would we know what would break with intermediate bridges?

   That's what we're paid the big bucks for... ;^)

> If, alternately, the defaults are SHOULDs, then ours can be too.

   If theirs are MUSTs, why doesn't simply referencing them suffice.
If we put a MUST in our document, it should be because we know that
failure to implement it would harm interoperability of _our_
protocol.

> I don't think it would be useful to diverge from those specs except
> where we deliberately need to.

   IMHO, we face scaling issues that IEEE does not. It may not be easy
to foresee those effects of scaling, but we should at least leave
ourselves wiggle room to deal with them.

--
John Leslie <[email-masked]>

Date: Thu, 06 Sep 2007 17:22:58 -0700
From: Joe Touch <[email-masked]>
To: James Carlson <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 2280

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

James Carlson wrote:
> Joe Touch writes:
>> Eastlake III Donald-LDE008 wrote:
>>> This is a check via the mailing list to confirm or refute an apparent=

>>> consensus at the Chicago meeting:
>>>
>>>    MAC address remembering timers in TRILL should have the same
>>>    configuration limits and default as in 802.1Q-2005.
>> Minor nits:
>>
>> replace "remembering" with "cache persistence"
>>
>> replace "default" with "defaults" (isn't there more than one timer?)
>>
>> Minor question:
>>
>> Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc?
>=20
> What would be the basis of the MUST?  Is there something in TRILL that
> falls apart if an implementation fails to heed this advice?  I don't
> see what the exact interoperability issue would be.
>=20
> Lacking a clear interoperability issue for TRILL itself, SHOULD seems
> right to me.  It means that implementations are required to follow
> that IEEE standard unless they've got a good reason to do otherwise.

I'd say MUST follow IEEE requirements.

I'm wondering how the IEEE spec's the defaults; if they're a MUST, then
why wouldn't we follow suit? How would we know what would break with
intermediate bridges? If, alternately, the defaults are SHOULDs, then
ours can be too.

I don't think it would be useful to diverge from those specs except
where we deliberately need to.

Joe

--=20
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

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

--------------enig488554C0A375BD1EFC4EC588--

Date: Thu, 6 Sep 2007 10:54:04 -0400
From: James Carlson <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 1159

Joe Touch writes:
> Eastlake III Donald-LDE008 wrote:
> > This is a check via the mailing list to confirm or refute an apparent
> > consensus at the Chicago meeting:
> > 
> >    MAC address remembering timers in TRILL should have the same
> >    configuration limits and default as in 802.1Q-2005.
> 
> Minor nits:
> 
> replace "remembering" with "cache persistence"
> 
> replace "default" with "defaults" (isn't there more than one timer?)
> 
> Minor question:
> 
> Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc?

What would be the basis of the MUST?  Is there something in TRILL that
falls apart if an implementation fails to heed this advice?  I don't
see what the exact interoperability issue would be.

Lacking a clear interoperability issue for TRILL itself, SHOULD seems
right to me.  It means that implementations are required to follow
that IEEE standard unless they've got a good reason to do otherwise.

-- 
James Carlson, Solaris Networking              <[email-masked]>
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

Date: Thu, 06 Sep 2007 06:54:15 -0700
From: Joe Touch <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 1734

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

Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus at the Chicago meeting:
>=20
>    MAC address remembering timers in TRILL should have the same
>    configuration limits and default as in 802.1Q-2005.

Minor nits:

replace "remembering" with "cache persistence"

replace "default" with "defaults" (isn't there more than one timer?)

Minor question:

Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc?

Joe

>=20
> If no particular controversy arises over this in the next two weeks, we=

> will declare it to be the working group consensus.
>=20
> Thanks,
> Donald & Erik
>=20
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

--=20
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

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

--------------enigFFA39FA68A21060EC07E39D4--

Date: Thu, 06 Sep 2007 06:52:36 -0700
From: Joe Touch <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Consensus Check: V-field reversion
Status: RO
Content-Length: 1761

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

Eastlake III Donald-LDE008 wrote:
> This is a check via the mailing list to confirm or refute an apparent
> consensus at the Chicago meeting for a change from protocol draft -05:
>=20
>    Eliminate different V field values and revert to two version bits
>    and two reserved bits with the previous provisions that this draft
>    specifies version zero, frames with an unknown version are
>    discarded, reserved bits MUST be zero and are ignored on receipt.

Minor nit to avoid ambiguity:

=2E..MUST be _set to_ zero...

> If no particular controversy arises over this in the next two weeks, we=

> will declare it to be the working group consensus.
>=20
> Thanks,
> Donald & Erik
>=20
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

--=20
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

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

--------------enig9BB3C141B5B1263B8D108FAD--

Date: Wed, 05 Sep 2007 19:56:31 -0700
From: Joe Touch <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Proposed new milestones
Status: RO
Content-Length: 3352

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

Regarding the PAS, I'd be very glad to wrap it up by Dec. Unfortunately,
I have received no input on the pending issues indicated therein since
Oct 2006. Do we have a plan on how to resolve those open issues?

(I can post a summary to the list if that'd help)

Joe

Erik Nordmark wrote:
> Any comments on these proposed new milestone dates? We discussed=20
> withdrawing the second milestone at and before Chicago. Do the dates=20
> look reasonable?
>=20
>=20
> Dec 2007	Submit architecture document to IEEE/IETF expert review
>=20
> WITHDRAWN	Submit routing protocol requirements to the IESG for
> 		publication as an Informational RFC
>=20
> Dec 2007	Submit problem statement and applicability to IESG for
> 		Informational RFC
>=20
> Mar 2007	Submit architecture document to the IESG for publication
> 		as an Informational RFC
>=20
> Done		Choose routing protocol(s) that can meet the
> 		requirements
>=20
> Dec 2007	Submit base protocol specification to IEEE/IETF
> 		expert review
>=20
> Mar 2008	Base protocol specification submitted to the
> 		IESG for publication as a Proposed Standard RFC
>=20
> Dec 2008	Re-charter or shut down the WG
>=20
> ------
>=20
> For reference - the currently posted list of milestones are:
> Done	  	Accept base protocol specification as a WG document
>=20
> Done	  	Accept problem statement and applicability as a WG work
> 		item
>=20
> Done	  	Start work with routing area WG(s) to undertake TRILL
> 		extensions
>=20
> Done	  	Accept architecture document as a WG work item
>=20
> Done	  	Accept routing protocol requirements as a WG work item
>=20
> Aug 2006	Submit architecture document to IEEE/IETF expert review
>=20
> Aug 2006	Submit routing protocol requirements to the IESG for
> 		publication as an Informational RFC
>=20
> Aug 2006	Submit problem statement and applicability to IESG for
> 		Informational RFC
>=20
> Nov 2006	Submit architecture document to the IESG for publication
> 		as an Informational RFC
>=20
> Dec 2006	Choose routing protocol(s) that can meet the
> 		requirements
>=20
> Dec 2006	Submit base protocol specification to IEEE/IETF
> 		expert review
>=20
> Mar 2007	Base protocol specification submitted to the
> 		IESG for publication as a Proposed Standard RFC
>=20
> Jul 2007	Re-charter or shut down the WG
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

--=20
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

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

--------------enig1BA8058C0E79D78EE793D4F2--

Date: Wed, 05 Sep 2007 16:34:34 -0700
From: Erik Nordmark <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Proposed new milestones
Status: RO
Content-Length: 2962

Silvano Gai wrote:
> My understanding was that we added a milestone to last call the frame
> format before the end of the year.

We didn't actually discuss that at the meeting. If the WG wants to 
commit to doing a WG last call this year that is fine. And we don't 
actually have to add it to the page.

But the ADs want to see us to update the current set of milestones since 
the current set is out of date. Thus I'm inclined to proceed without 
adding that particular milestone and instead get the updated milestones 
to the ADs.

    Erik

> -- Silvano
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
> On
>> Behalf Of Erik Nordmark
>> Sent: Friday, August 31, 2007 9:00 AM
>> To: Developing a hybrid router/bridge.
>> Subject: [rbridge] Proposed new milestones
>>
>> Any comments on these proposed new milestone dates? We discussed
>> withdrawing the second milestone at and before Chicago. Do the dates
>> look reasonable?
>>
>>
>> Dec 2007	Submit architecture document to IEEE/IETF expert review
>>
>> WITHDRAWN	Submit routing protocol requirements to the IESG for
>> 		publication as an Informational RFC
>>
>> Dec 2007	Submit problem statement and applicability to IESG for
>> 		Informational RFC
>>
>> Mar 2007	Submit architecture document to the IESG for publication
>> 		as an Informational RFC
>>
>> Done		Choose routing protocol(s) that can meet the
>> 		requirements
>>
>> Dec 2007	Submit base protocol specification to IEEE/IETF
>> 		expert review
>>
>> Mar 2008	Base protocol specification submitted to the
>> 		IESG for publication as a Proposed Standard RFC
>>
>> Dec 2008	Re-charter or shut down the WG
>>
>> ------
>>
>> For reference - the currently posted list of milestones are:
>> Done	  	Accept base protocol specification as a WG document
>>
>> Done	  	Accept problem statement and applicability as a WG work
>> 		item
>>
>> Done	  	Start work with routing area WG(s) to undertake TRILL
>> 		extensions
>>
>> Done	  	Accept architecture document as a WG work item
>>
>> Done	  	Accept routing protocol requirements as a WG work item
>>
>> Aug 2006	Submit architecture document to IEEE/IETF expert review
>>
>> Aug 2006	Submit routing protocol requirements to the IESG for
>> 		publication as an Informational RFC
>>
>> Aug 2006	Submit problem statement and applicability to IESG for
>> 		Informational RFC
>>
>> Nov 2006	Submit architecture document to the IESG for publication
>> 		as an Informational RFC
>>
>> Dec 2006	Choose routing protocol(s) that can meet the
>> 		requirements
>>
>> Dec 2006	Submit base protocol specification to IEEE/IETF
>> 		expert review
>>
>> Mar 2007	Base protocol specification submitted to the
>> 		IESG for publication as a Proposed Standard RFC
>>
>> Jul 2007	Re-charter or shut down the WG
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Tue, 4 Sep 2007 08:34:59 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: MAC learning timers
Status: RO
Content-Length: 372

This is a check via the mailing list to confirm or refute an apparent
consensus at the Chicago meeting:

   MAC address remembering timers in TRILL should have the same
   configuration limits and default as in 802.1Q-2005.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

Content-class: urn:content-classes:message
Date: Tue, 4 Sep 2007 08:33:02 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Check: V-field reversion
Status: RO
Content-Length: 560

This is a check via the mailing list to confirm or refute an apparent
consensus at the Chicago meeting for a change from protocol draft -05:

   Eliminate different V field values and revert to two version bits
   and two reserved bits with the previous provisions that this draft
   specifies version zero, frames with an unknown version are
   discarded, reserved bits MUST be zero and are ignored on receipt.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

Content-class: urn:content-classes:message
Date: Tue, 4 Sep 2007 08:22:29 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Consensus: Addition of "Other Multicast" bit to the Multicast RouterAttached Bits
Status: RO
Content-Length: 2625

There seems to be plenty of support and almost no opposition to the
technical change below so we declare it to be the consensus of the TRILL
working group.

Donald & Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Saturday, July 28, 2007 11:43 PM
To: [email-masked]
Subject: [rbridge] Addition of "Other Multicast" bit to the Multicast
RouterAttached Bits

In the base protocol draft -05 there are two multicast router attachment
bits. The tentative consensus at the TRILL meeting last week was to add
a third bit so the situation would be as follows:

o There are 3 bits in TRILL IS-IS LSPs that appear per VLAN per Rbridge.
They are named "Other Multicast (OM)", "IPv4 attached multicast router
(MR4)", and "IPv6 attached multicast router (MR6)".

o When these bits are set, they cause all multicast frames for the
appropriate VLAN to be sent to the Rbridge with the bit on for IPv4
derived multicast (MR4), IPv6 derived multicast (MR6), or all other
multicast (OM). (Even if the MR4 or MR6 bit is off, multicast data
frames are still sent to the Rbridge if multicast listeners for that
data are reported by the Rbridge.)

o MR4 is set by an RBridge when it, as Designated Rbridge (DRB),
receives a native IGMP Query or IPv4 MRD Report on a port. (As per the
relevant RFCs, the bit times out and is cleared unless repeatedly set.)
This is an IGMP-snooping action. If an RBridge doesn't support this
IGMP-snooping action, it always sets this bit to 1.

o MR6 is set by an RBridge when it, as DRB, receives a native MLD Query
or IPv6 MRD Report on port. This is an MLD-snooping action. (As per the
relevant RFCs, the bit times out and is cleared unless repeatedly set.)
If an RBridge doesn't support this MLD-snooping action, it always sets
this bit to 1.

o OM can't be set by dynamic signaling since non-IPv4/IPv6 derived
multicast frames have no widely deployed signaling mechanism. It's value
is set by either configuration or deciding on a default setting.

o The recommendation is to default the 3 bits to {1,0,0} for
{OM,MR4,MR6} respectively for Rbridges that implement IP derived
multicast snooping. This causes all non-IPv4/IPv6 (other) multicast
frames to be flooded to such RBridges and snooping protocols can set the
MR4 and MR6 bits conditionally. For Rbridges that do not implement IP
derived multicast snooping, the bits should default to (1,1,1).

Thanks,
Donald

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