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

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 30 Jul 2007 19:14:37 -0700

I had a conversation with Anoop, and he is (quite understandably)
uneasy about sending IS-IS Hellos tagged with every VLAN. So he
made the following suggestion, which I think makes sense.

a) declare that bridges must be configured
so that VLAN 1 (default VLAN) must not be
partitioned on a layer 2 cloud. We will detect the misconfiguration
if it occurs (see d)) so that we at least do not have loops, but TRILL 
will not
stand on its head to support what will be declared a gross misconfiguration.

b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
the following information in its IS-IS Hello:

. I am R1
. I hear Hellos from {R2, R3, R7, R11}
. If I am DRB, the pseudonode name will be R1.59
. My priority for the set of VLANs {A, D, W} is 7
. My priority for the set of VLANs {B, C, F, G, H} is 3

c) If R1 becomes DRB for at least one of the VLANs on the cloud,
then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
the ID of the root bridge on the primary spanning tree
instance for that layer 2 cloud, along with the set of VLANs for which
R1 is DRB on that cloud.

Note: The current draft spec isn't clear what information R1 reports in 
the pseudonode
LSP and what it reports in its own LSP.
I'm suggesting reporting the bridge ID and
set of VLANs in the pseudonode LSP.

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

e) This proposal supports multiple DRBs on a cloud for load splitting
based on VLANs, since the RBridges can have different priorities
for different VLANs. It still requires only sending one Hello, tagged
with VLAN 1. R2 should
not panic if R2 notices that R1.59 has the same root bridge as on
a port on which R2 is DRB, if R1.59's listed set of VLANs does not
include any VLANs for which R2 is DRB on the link with
that root bridge. If there is only partial overlap
of VLAN IDs, say the overlap is VLANs {D, F, and H},
then (the loser based on ID tie-breaker) will stop forwarding traffic
to/from that link that is tagged with VLANs D, F, or H.

f) If some VLAN, say VLAN C, is actually partitioned, then the
result of this is that some VLAN C endnodes on that layer 2 cloud
will be orphaned. We will choose NOT to solve that.

The result of this proposal is that
RBridges will only need to send IS-IS Hellos tagged
with VLAN 1, and the only thing it does NOT solve (over
the current proposal of sending Hellos with every possible VLAN tag on
each port) is that sometimes endnodes might get orphaned if you have
a partitioned VLAN.

We *could* in that case, if someone *actually wanted* to have VLAN A
partitioned on that cloud, configure the RBridges on that layer 2
cloud to explicitly run a different election
for VLAN A (and note in the pseudonode LSP that VLAN A had
an explicit election tagged with VLAN A so that if there were
two DRBs they wouldn't panic). But I'd prefer not solving this case and
keeping it simpler (and safer).

Radia

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 31 Jul 2007 08:38:43 -0700

Radia,

The fact that VLAN 1 (or any other VLANs) is partitioned is NOT a
misconfiguration. It is a reality in today networks. TRILL cannot change
this.

I disagree with this proposal.

I think we should stick with the current design that works in any
configuration. When we will gain implementation and deployment
experience we will optimize.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman
> Sent: Monday, July 30, 2007 7:15 PM
> To: rbridge at postel.org
> Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with
> allthe VLAN tags
> 
> if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
VLAN
> A
> have seen each other's Hellos and not both think they are DRB for VLAN
A
> (or
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 31 Jul 2007 09:37:43 -0700

I'd like to understand what problem customers are attempting to solve with
partitioned VLANs, and what hardship it would present to require at 
least one of the
VLANs to *not* be partitioned. With TRILL, if a customer eventually replaces
all bridges, the customer will not be able to partition VLANs anymore. 
Also, from
what Anoop was explaining to me, the GVRP protocol would automatically
configure the switch-to-switch links to join all the islands of VLANs. 
So it would
seem as though it can't be that fatal to solving customer problems to 
require
*one* VLAN on a layer 2 cloud to not be partitioned.

I'd guess that most of the time partitioned VLANs would be a result of 
misconfiguration,
or intentional configuration in one topology that becomes partitioning 
when the spanning
tree reconfigures.

The only thing I can imagine solve with intentionally partitioned VLANs 
is that the
VLAN space is too small, so they have to reuse the same number in 
different parts of
their cloud. In that case, I'd think a much cleaner solution would be 
expanding the
size of the VLAN, which would be easy with TRILL.

At any rate, everything involves tradeoffs. The plus side of the 
one-Hello-on-VLAN-1
proposal is simplicity and efficiency, since there only needs to be a 
single hello.

So anyway---what problem are customers solving with intentionally 
partitioned VLANs
on a layer 2 cloud?

Radia

Silvano Gai wrote:
>> Note: The current draft spec isn't clear what information R1 reports
>>     
> in
>   
>> the pseudonode
>> d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
>>     
> r11,
>   
>> actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
>>     
> would
>   
>> two DRBs they wouldn't panic). But I'd prefer not solving this case
>>     
> and
>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 31 Jul 2007 09:40:09 -0700

Silvano,

Dealing with partitioned VLANs will create all kinds
of complexity.  Even 802.1Q bridges don't really deal 
with that (assumming one is using something like 
GVRP/MVRP as required by the standard).  

It only works in 802.1Q devices if doing static 
configuration.  We can always allow for that mode
of operation as an option but the default should
always be to treat the partitioned case as a mis-
configuration.

However, in the general case, I have to hunt for 
a VLAN in order to make sure my core IS-IS packets
get through.  And if there's a reconfiguration in
the L2 topology, I might have to hunt for yet another
VLAN (one that was previously partitioned but is
now connected).

Current design works in any configuration but it
does not scale and it could take very long for the
network to converge.

I don't like having to send per-VLAN IS-IS hellos.
It would require too much CPU power on the switch.

Anoop

> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> Sent: Tuesday, July 31, 2007 8:39 AM
> To: Radia Perlman; rbridge at postel.org
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged withallthe VLAN tags
> 
> Radia,
>

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Tue, 31 Jul 2007 10:16:50 -0700

Hi Radia,

> stand on its head to support what will be declared a gross misconfiguration.
This will not fly. We originally had such a scheme a long time ago in 
our switches. We got so much flak from customers that we eventually had 
to back away from it. A single VLAN across the entire L2 cloud is 
unacceptable.

Also the number of deployments using GVRP/MVRP/VTP is quite 
insignificant. A significant (if not most) number of customers have 
deliberately turned off running these protocols to manage VLANs.

However, I'm sympathetic to Anoop's point and do think it is acceptable 
to partition the network in case of misconfiguration, but we MUST avoid 
loops at all costs. Let me think a little more,

Dinesh

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

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Tue, 31 Jul 2007 10:23:42 -0700

> partitioned VLANs, and what hardship it would present to require at 
The primary problem with having a VLAN everywhere is that the root of 
the spanning tree moves around leading to non-optimal forwarding in 
enterprise networks. Enterprise networks are carefully engineered 
networks and in the event of failure, they want to localize the effects 
as much as possible. So, they want each VLAN to be localized and roots 
where they want it to be. Having a common VLAN messes up that 
arrangement. Also, VLAN 1 is the default VLAN when a switch comes up and 
there is typically lots of customer data on it.
> all bridges, the customer will not be able to partition VLANs anymore. 
As I raised it in the meeting, this is a side-effect that has not been 
considered before and needs to be carefully thought through. I don't 
think many people are aware of this issue with TRILL that doesn't exist 
with 802.1Q bridges today.
> *one* VLAN on a layer 2 cloud to not be partitioned.
GVRP is not deployed by a significant majority of customers.

Dinesh

---

From: james.d.carlson at Sun.COM (James Carlson)
Date: Tue, 31 Jul 2007 13:57:17 -0400

Dinesh G Dutt writes:
> enterprise networks.

That shouldn't matter anymore with RBridges, right?  One of the points
of getting rid of STP is to get rid of the single root and the
disappointing paths created when STP shuts down useful links.

I understand the transition argument, but the idea of VLAN ID reuse
seems hard enough to manage over time that it's harmful.

Should we carry all of STP's baggage?

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 31 Jul 2007 11:18:30 -0700

I don't understand that problem. What you're describing might argue for 
bridges using a unique
spanning tree per VLAN in order to optimize traffic flow for that VLAN, 
but I don't
see what it has to do with wanting to partition VLANs.

Radia

Dinesh G Dutt wrote:
> networks and in the event of failure, they want to localize the 
> effects as much as possible. So, they want each VLAN to be localized 
> and roots where they want it to be. Having a common VLAN messes up 
> that arrangement. Also, VLAN 1 is the default VLAN when a switch comes 
> up and there is typically lots of customer data on it.
> think many people are aware of this issue with TRILL that doesn't 
> exist with 802.1Q bridges today.
>> Also, from
>> configure the switch-to-switch links to join all the islands of 
>> VLANs. So it would

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 31 Jul 2007 14:40:02 -0700

Radia,

We are describing to you how VLANs are deployed today in Enterprise
networks. You may say that "you don't like it", we may agree with you,
but this does not change how they are deployed.

For RBridges to be successful they need to be able to replace core
bridges without messing up the existing network configurations.

Today most customers do not deploy VLANs end-to-end and they do reuse
VLANs number in different part of the enterprise. If RBridges are not
capable of supporting this, they are not attractive.

Remember that the #1 customer requirement we have for TRILL is: "replace
core bridges with RBridges to enable Equal Cost Multi Path, all the rest
MUST remain the same".

GVRP is not deployed; I am not sure which customers Anoop is referring
to.

-- Silvano

> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> Sent: Tuesday, July 31, 2007 11:19 AM
> To: Dinesh G Dutt
> Cc: Silvano Gai; rbridge at postel.org
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
with
> >> I'd like to understand what problem customers are attempting to
solve
> >> with

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 31 Jul 2007 16:06:03 -0700

Hi Silvano,

Believe it or not there are customers out there that
use GVRP.  They might not be a majority, but they
do exist.

As far as I'm aware, it is _not_ very common
for customers to be reusing VLAN IDs within the
enterprise.  If they do reuse them, they are in
physically separate portions of the network that
are interconnected by routers.  That's the normal
tiered architecture that one tends to see in 
enterprises.

I have never come across a customer that uses
partitioned VLANs the way you mention, so I find
it hard to believe they are common.  There's always
the oddball, strange architecture out there.
Do we really need to force everyone to send per-VLAN
hellos to deal with that?  We can always design to
make that type of configuration work, but we should
optimize for the common case.

Anoop

> Sent: Tuesday, July 31, 2007 2:40 PM
> To: Radia Perlman; Dinesh G Dutt
> Cc: rbridge at postel.org
> We are describing to you how VLANs are deployed today in 
> Enterprise networks. You may say that "you don't like it", we 
> may agree with you, but this does not change how they are deployed.
> 
> For RBridges to be successful they need to be able to replace 
> core bridges without messing up the existing network configurations.
> 
> Today most customers do not deploy VLANs end-to-end and they 
> do reuse VLANs number in different part of the enterprise. If 
> RBridges are not capable of supporting this, they are not attractive.
> 
> Remember that the #1 customer requirement we have for TRILL 
> is: "replace core bridges with RBridges to enable Equal Cost 
> Multi Path, all the rest MUST remain the same".
> 
> GVRP is not deployed; I am not sure which customers Anoop is 
> referring to.
> 
> -- Silvano
> 
> > >> VLANs to *not* be partitioned. With TRILL, if a customer 
> eventually 
> > >> replaces all bridges, the customer will not be able to partition 
> > >> VLANs
> anymore.
> > >> VLANs. So it would seem as though it can't be that fatal 
> to solving 
> > >> customer problems
> to
> > >> require

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 31 Jul 2007 18:31:34 -0700

Silvano....I still don't know what problem customers are trying to solve 
with partitioned VLANs.
If it's that they want more than 4000 VLANs, then the design we had (before
Anoop's suggestion) also won't help them with that.
If it is an important problem to use more than 4000 VLANs,
we could (by extending the size of the VLAN tag within a TRILL campus) 
solve that
problem in a much more robust, easily understandable way than 
configuring interswitch
ports to block some VLANs. And I absolutely do not understand any other 
problems
that might be solved with intentionally partitioning VLANs, and it's 
impossible to design
something without understand the problem that needs to be solved.

We do have to carefully consider what "breaks"  (in the
proposal we are currently considering) if a customer does actually configure
bridges in some layer 2 cloud so that VLAN 1 is partitioned.
I believe the only consequence of a customer configuring
bridges so that VLAN 1 is partitioned in some layer 2 cloud  is that core
RBridges that might have connectivity to each
other through some VLAN other than
VLAN 1 will not realize they are adjacent, and will therefore not form 
IS-IS adjacencies, which
means fewer RBridge-RBridge links in the core than there might actually 
be. This might
actually cause the campus to get partitioned (since the only 
connectivity between RBridges
will be using VLAN 1, and if all the links in the cut set require an 
outer tag of other
than 1 in order for RBridges to talk, these links won't be found or
used). It might cause less good paths. However, it will *not* cause 
loops, because if
there is no connectivity for flooding of LSPs, data also won't flow in 
the core.

The advantage of this proposal is simplicity and scalability -- only one 
Hello per port.

As I said, I cannot understand what functionality is lost if all switch 
ports within a layer 2
cloud must be configured to pass VLAN 1, and until we do understand some
important hardship that this rule imposes, I'd say this (Anoop's proposal)
is obviously the right thing to do.

Radia

Silvano Gai wrote:
>> I don't understand that problem. What you're describing might argue
>>     
> for
>   
>> bridges using a unique
>> spanning tree per VLAN in order to optimize traffic flow for that
>>     
> VLAN,
>   
>> but I don't
>>> The primary problem with having a VLAN everywhere is that the root
>>>       
> of
>   
>>> that arrangement. Also, VLAN 1 is the default VLAN when a switch
>>>       
> comes
>   
>>>> all bridges, the customer will not be able to partition VLANs
>>>>         
> anymore.
>   
>>> As I raised it in the meeting, this is a side-effect that has not
>>>       
> been
>   
>>>> what Anoop was explaining to me, the GVRP protocol would
>>>>         
> automatically
>   
>>>> seem as though it can't be that fatal to solving customer problems
>>>>         
> to
>   
>>>> require

---

From: arien.vijn at ams-ix.net (Arien Vijn)
Date: Wed, 1 Aug 2007 08:37:51 +0200

> Silvano....I still don't know what problem customers are trying to  

We have to chop vlans to overcome limits with regards to link  
aggregation. We need more interswitch capacity than we can aggregate.  
Hence we have to use multiple vlans with multiple untagged links  
which are connected on a central core switch. All these vlans form  
one broadcast domain.

Since vlan information gets lost it is possible to reuse the same  
vlan id on different switches. Reusing ids has even some operation  
benefits in the current situation.

Nonetheless, TRILL might change this practice and the next generation  
of switches can aggregate more links.

One other thing. The default vlan is often solely used to park unused  
ports. It is often not interconnected in many networks. I guess many  
operators would appreciate a configurable vlan for IS-IS election.  
The default vlan for this should be the default vlan.

I believe it is not uncommon to run a dedicated vlan for these kind  
of purposes and I think it's way cleaner than IS-IS hellos tagged  
with every VLAN.

Hope this makes sense.

Arien

From: Arien Vijn <[email-masked]>
Date: Wed, 1 Aug 2007 08:37:51 +0200
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Status: RO
Content-Length: 1189

> Silvano....I still don't know what problem customers are trying to  

We have to chop vlans to overcome limits with regards to link  
aggregation. We need more interswitch capacity than we can aggregate.  
Hence we have to use multiple vlans with multiple untagged links  
which are connected on a central core switch. All these vlans form  
one broadcast domain.

Since vlan information gets lost it is possible to reuse the same  
vlan id on different switches. Reusing ids has even some operation  
benefits in the current situation.

Nonetheless, TRILL might change this practice and the next generation  
of switches can aggregate more links.

One other thing. The default vlan is often solely used to park unused  
ports. It is often not interconnected in many networks. I guess many  
operators would appreciate a configurable vlan for IS-IS election.  
The default vlan for this should be the default vlan.

I believe it is not uncommon to run a dedicated vlan for these kind  
of purposes and I think it's way cleaner than IS-IS hellos tagged  
with every VLAN.

Hope this makes sense.

Arien

Date: Tue, 31 Jul 2007 18:31:34 -0700
From: Radia Perlman <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Status: RO
Content-Length: 5383

Radia

Silvano Gai wrote:
>> From: Radia Perlman [mailto:[email-masked]]
>> Cc: Silvano Gai; [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 31 Jul 2007 16:06:03 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Dinesh G Dutt" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
Status: RO
Content-Length: 4458

Hi Silvano,

Anoop

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> Cc: [email-masked]
> > From: Radia Perlman [mailto:[email-masked]]
> > Cc: Silvano Gai; [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 31 Jul 2007 14:40:02 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Dinesh G Dutt" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Status: RO
Content-Length: 2955

Radia,

-- Silvano

> From: Radia Perlman [mailto:[email-masked]]
> Cc: Silvano Gai; [email-masked]
with
for
VLAN,
solve
of
comes
anymore.
been
automatically
to
> > GVRP is not deployed by a significant majority of customers.

Date: Tue, 31 Jul 2007 11:18:30 -0700
From: Radia Perlman <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Status: RO
Content-Length: 1835

Radia

> GVRP is not deployed by a significant majority of customers.

Date: Tue, 31 Jul 2007 13:57:17 -0400
From: James Carlson <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Status: RO
Content-Length: 978

-- 
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: Tue, 31 Jul 2007 11:05:14 -0700
From: Dinesh G Dutt <[email-masked]>
To: [email-masked]
Subject: [rbridge] Aging timer For MAC Entries
Status: RO
Content-Length: 1363

Since the proposal to learn from data frames is the default mode in 
RBridges now, we must also  mention how to age the MAC addresses learnt 
in the RBridge forwarding table; this includes MAC addresses learnt on 
directly attached local ports (local MACs) and those learnt about remote 
entities (remote MACs), containing the mapping of remote MAC address to 
RBridge nickname.

The basic guideline is to follow the IEEE 802.1Q bridge standards. The 
2005 version of the 802.1Q draft has the following to say (section 
8.8.3) about entries learnt from data frames (called Dynamic Filtering 
entries in IEEE lingo):
"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 specifies that the recommended default value is 300s and that 
the range of allowed values is 10-1,000,000 secs.

I recommend that we adopt the similar text and recommend the same range 
and default value.

Dinesh

Date: Tue, 31 Jul 2007 10:23:42 -0700
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Status: RO
Content-Length: 1660

Dinesh

Date: Tue, 31 Jul 2007 10:16:50 -0700
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all	the VLAN tags
Status: RO
Content-Length: 1324

Hi Radia,

Dinesh

Content-class: urn:content-classes:message
Date: Tue, 31 Jul 2007 09:40:09 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags
Status: RO
Content-Length: 6153

Silvano,

Anoop

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> To: Radia Perlman; [email-masked]
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Radia Perlman
> > To: [email-masked]
> > [email-masked]
> [email-masked]

Date: Tue, 31 Jul 2007 09:37:43 -0700
From: Radia Perlman <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Status: RO
Content-Length: 6151

Radia

Silvano Gai wrote:
>> From: [email-masked] [mailto:[email-masked]]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> To: [email-masked]
>> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 31 Jul 2007 08:38:43 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with allthe VLAN tags
Status: RO
Content-Length: 4508

Radia,

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> To: [email-masked]
in
r11,
VLAN
would
A
and
> [email-masked]

Date: Mon, 30 Jul 2007 19:14:37 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Avoiding sending multiple IS-IS Hellos tagged with all the VLAN tags
Status: RO
Content-Length: 3557

. I am R1

Radia

Date: Mon, 30 Jul 2007 07:33:23 -0400
From: James Carlson <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Addition of "Other Multicast" bit to the Multicast Router	Attached Bits
Status: RO
Content-Length: 522

Eastlake III Donald-LDE008 writes:
> 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:
[...]

This result sounds good to me.  Thanks for the update.

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

Content-class: urn:content-classes:message
Date: Sat, 28 Jul 2007 23:43:17 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Addition of "Other Multicast" bit to the Multicast Router Attached Bits
Status: RO
Content-Length: 2024

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

Content-class: urn:content-classes:message
Date: Sat, 28 Jul 2007 15:51:03 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Results from the Chicago TRILL Meeting
Status: RO
Content-Length: 781

Hi everyone,

I believe we had some very productive TRILL meetings at the Chicago IETF
last week. There were some tentative consensuses arrived at which Erik
Nordmark and I will be confirming by posting them to the list and some
issues discussed which did not appear to be resolved at the meeting and
which probably need further discussion on the list.

As we get the minutes together from the meeting, Erik or I will be
posting these issues/decisions to the list with some effort to make
different threads / subject lines for the different issues.

Thanks,
Donald

====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 111 Locke Drive             +1-508-333-2270 (cell)
 Marlborough, MA 01752 USA
 [email-masked]

Date: Fri, 27 Jul 2007 13:31:43 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] separating out the header spec
Status: RO
Content-Length: 1817

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

Hi, all,

I spoke with Eric today, and came to an observation that might be useful
to make explicit in the separation of the header spec from other parts
of our protocols.

In a sense, this ought to be a split that reflects the functional
separation of the data plane from the control plane.

Data plane - encapsulation headers, semantics of the fields, and
forwarding operations based on the encapsulation headers

Control plane - protocols used to setup state used by the data plane

If that's the split, then I understand the utility and agree this is a
useful way to get the data plane spec out more quickly. Can anyone who
was strongly in favor of the split let me know if this makes sense, or
if they're thinking of something else?

PS - there are other planes, as well, e.g., the management plane (MIBs),
and the one I hope we can avoid in these discussions (the customer plane =
;-)

Joe

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

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

--------------enig70BB247C69B6C527084036E5--

Content-class: urn:content-classes:message
Date: Thu, 26 Jul 2007 17:12:37 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL Meeting Materials for IETF-69 up to date
Status: RO
Content-Length: 231

Hi,

I've updated the TRILL meeting materials on the IETF-69th meeting
materials page:
https://datatracker.ietf.org/meeting/69/materials.html
so that it shows what was actually presented in the order it was shown.

Thanks,
Donald

Date: Thu, 26 Jul 2007 10:55:52 -0500
From: Mark Townsley <[email-masked]>
To: [email-masked]
Subject: [rbridge] [Fwd: IETF Streaming]
Status: RO
Content-Length: 770

FYI about audio recordings...

And the archive is here:

http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/
ftp://limestone.uoregon.edu/pub/videolab/media/ietf69/

-------- Original Message --------
Subject: 	IETF Streaming
Date: 	Fri, 20 Jul 2007 16:59:41 -0700
From: 	Joel Jaeggli <[email-masked]>
To: 	IETF Discussion <[email-masked]>

The webpage for the streaming has been updated to reflect the schedule
for monday and tuesday.

http://videolab.uoregon.edu/events/ietf/

One addition is that we intend to record and broadcast the Sunday IEPG
meeting located in the crystal ballroom from 1000-1200 CDT.

Regards
Joel Jaeggli

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

Content-class: urn:content-classes:message
Date: Wed, 18 Jul 2007 12:21:25 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-03.txt
Status: RO
Content-Length: 4417

Folks,

This version of the Architecture draft reflects efforts since the
last meeting to align terminology among the various WG drafts.

A later version is yet to be written in which this draft will be
revised to:

1) reduce discussions relating to protocol - or implementation -
   specific details and continue the alignment efforts (with the
   protocol specification in particular);
2) incorporate one or two concepts, discussion points and figures
   that it is felt should be moved from the protocol specification
   to the architecture document;
3) incorporate one or two of the ideas previously included in the
   routing requirements draft, and remove the current reference to 
   that (now defunct) draft.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, July 12, 2007 2:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-03.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transparent Interconnection 
> of Lots of Links Working Group of the IETF.
> 
> 	Title		: The Architecture of an RBridge 
> Solution to TRILL
> 	Author(s)	: E. Gray
> 	Filename	: draft-ietf-trill-rbridge-arch-03.txt
> 	Pages		: 35
> 	Date		: 2007-7-12
> 	
> RBridges are link layer (L2) devices that use routing protocols 
>         as a control plane. They combine several of the 
> benefits of the 
>         link layer with network layer routing benefits. RBridges use 
>         existing link state routing (without requiring 
> configuration) to 
>         improve RBridge to RBridge aggregate throughput. 
> RBridges also 
> 
>         provide support for IP multicast and IP address resolution 
>         optimizations. They are intended to be applicable to 
> similar L2 
>         network sizes as conventional bridges and are intended to be 
>         backward compatible with those bridges as both ingress/egress 
>         and transit. They also support VLANs (although this generally 
>         requires configuration) and otherwise attempt to 
> retain as much 
>         'plug and play' as is already available in existing bridges. 
>         This document proposes an RBridge system as a solution to the 
>         TRILL problem. It also defines the RBridge 
> architecture, defines 
>         its terminology, and describes basic components and desired 
>         behavior. One or more separate documents specify the 
> protocols 
>         and mechanisms that satisfy the architecture presented herein.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-a
> rch-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of 
> the message. 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-ietf-trill-rbridge-arch-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-trill-rbridge-arch-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

To: [email-masked]
From: [email-masked]
Date: Thu, 12 Jul 2007 14:15:02 -0400
Cc: [email-masked]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-03.txt
Status: RO
Content-Length: 3768

--NextPart

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

	Title		: The Architecture of an RBridge Solution to TRILL
	Author(s)	: E. Gray
	Filename	: draft-ietf-trill-rbridge-arch-03.txt
	Pages		: 35
	Date		: 2007-7-12
	
RBridges are link layer (L2) devices that use routing protocols 
        as a control plane. They combine several of the benefits of the 
        link layer with network layer routing benefits. RBridges use 
        existing link state routing (without requiring configuration) to 
        improve RBridge to RBridge aggregate throughput. RBridges also 

        provide support for IP multicast and IP address resolution 
        optimizations. They are intended to be applicable to similar L2 
        network sizes as conventional bridges and are intended to be 
        backward compatible with those bridges as both ingress/egress 
        and transit. They also support VLANs (although this generally 
        requires configuration) and otherwise attempt to retain as much 
        'plug and play' as is already available in existing bridges. 
        This document proposes an RBridge system as a solution to the 
        TRILL problem. It also defines the RBridge architecture, defines 
        its terminology, and describes basic components and desired 
        behavior. One or more separate documents specify the protocols 
        and mechanisms that satisfy the architecture presented herein.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-03.txt

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

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-rbridge-arch-03.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Date: Wed, 11 Jul 2007 23:32:43 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Preliminary Agenda for Chicago
Status: RO
Content-Length: 552

Hi,

We're getting this up a bit later than usual but there is a preliminary
draft agenda for the TRILL meeting at the 69th IETF meeting in Chicago
linked from the meeting materials page at
https://datatracker.ietf.org/meeting/69/materials.html.

Anyone wishing to make a presentation or with an idea or request for the
agenda, please post to this list or send to
<mailto:[email-masked]>. We can update the posted agenda
for a few more days.

You might find the various pointers at http://tools.ietf.org/wg/trill/
useful.

Thanks,
Donald

To: [email-masked]
From: [email-masked]
Date: Tue, 10 Jul 2007 16:15:01 -0400
Cc: [email-masked]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-05.txt
Status: RO
Content-Length: 3534

--NextPart

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

	Title		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman, et al.
	Filename	: draft-ietf-trill-rbridge-protocol-05.txt
	Pages		: 71
	Date		: 2007-7-10
	
RBridges allow for optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and multipathing for both unicast and multicast traffic. They
   achieve these goals using IS-IS routing and encapsulation of traffic
   with a header that includes a hop count.

   RBridges are compatible with previous IEEE 802.1 bridges as well as
   current IPv4 and IPv6 routers and end nodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design supports VLANs, and, optionally, optimization of the
   distribution of multi-destination frames based on VLAN and IP derived
   multicast groups.  It also allows forwarding tables to be based on
   RBridge destinations (rather than end node destinations), which
   allows internal forwarding tables to be substantially smaller than in
   conventional bridge systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-05.txt

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

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-05.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 05 Jul 2007 09:05:35 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] IS-IS Consensus Call, Routing Requirements Document
Status: RO
Content-Length: 1938

There hasn't been any objection to this, thus we declare WG consensus for
  - Selecting IS-IS is the routing protocol to be used by TRILL
  - Moving the key points from the Routing Requirements into the 
Architecture document, and removing the Routing Requirements document 
from our set of milestones.

    Erik & Donald

-------- Original Message --------
Subject: [rbridge] IS-IS Consensus Call, Routing Requirements Document
Date: Mon, 18 Jun 2007 12:52:14 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
To: [email-masked]

It appears that there has been some change in the IESG position on the
selection of a link state routing protocol for TRILL. Since we have been
working on the TRILL protocol specification for some time and no
reasonable alternative has appeared, if there is a TRILL working group
consensus for IS-IS, we expect that this will satisfy the IESG. As a
consequence, the Routing Requirements document, which was originally
requested by the IESG as a basis for deciding on the routing protocol,
would no longer be necessary after a selection of IS-IS. This document,
in fact, ran into a lot of opposition in the IESG, not because of what
it says about routing requirements, but mostly because it was somehow
misinterpreted as a TRILL requirements document. We would expect that,
after selection of IS-IS, the key points of the Routing Requirements
document would be merged into the Architecture document and no longer be
a separate deliverable.

The discussion in the working group has given the impression that there
is a consensus for IS-IS. In fact, it may come as a surprise to some
people that it has not yet been officially selected. Unless significant
opposition appears, we will judge that IS-IS is the consensus.

Thanks,
Erik and Donald

[email-masked]

Date: Tue, 03 Jul 2007 19:18:57 -0700
From: Joe Touch <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Inner/Outer versus Data/Transport
Status: RO
Content-Length: 3410

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

Eastlake III Donald-LDE008 wrote:
> Hi,
>=20
> A terminology question has come up concerning the current use of Inner
> and Outer in the protocol specification.
>=20
> Currently these words are used in a way pretty close to their usual
> English meaning. When a frame is being transported inside a TRILL
> Header, the Ethernet header on the outside of the frame is called the
> Outer header and the one inside the envelope is called the Inner header=
=2E
> But, when talking about a native frame, what will become the Inner
> header when encapsulated is also called an Outer header, because it is
> on the outside of the native frame.
>=20
> This doesn't bother me and I suspect is fine for native English speaker=
s
> because the inside/outside connotation of Inner and Outer override any
> problem with the same header fields being called Outer when they are at=

> the start of a native frame and Inner when they are inside a TRILL
> envelope.
>=20
> However, some find this very confusing. For example, consider someone
> implementing an Rbridge where the VLAN associated with an incoming fram=
e
> is considered meta data stored in a register/variable separate from but=

> associated with the frame payload. (The VLAN might come from an Outer
> VLAN Tag or be assigned based on the port, etc.) What are you going to
> call this register/variable? If the incoming frame is a native frame
> then, if it is encapsulated, this VLAN tag information will appear in
> the "Inner VLAN" position. But if the frame is forwarded in native form=

> to another local link, it will appear in the "Outer VLAN" position. So
> neither Inner nor Outer seems to be an appropriate name for this
> hypothetical register/variable.
>=20
> It has been suggested that "Inner" be changed to "Data" and "Outer" be
> changed to "Transport" for TRILL frames and to "Data" from native
> frames, or some similar change.

Transport has a meaning in the IETF, and this isn't it - even when
encapsulated, the inner header isn't the transport header.

> I think that such naming would be
> reasonably clear and would have the effect that, for example, the Data
> VLAN Tag could be called that whether it appeared on the outside of a
> native frame or inside a TRILL envelope.=20
>=20
> I don't really care one way or the other and am soliciting working grou=
p
> opinion on this question.

I think the terms we have are fine, and that diagrams that clarify what
they mean are sufficient. Introducing new terms is as likely to cause
confusion with the currently non-confused as it would be to resolve
confusion in the confused.

Joe

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

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

--------------enigF40870BEF4E19E4950156600--

Content-class: urn:content-classes:message
Date: Tue, 3 Jul 2007 10:51:19 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Inner/Outer versus Data/Transport
Status: RO
Content-Length: 2103

Hi,

A terminology question has come up concerning the current use of Inner
and Outer in the protocol specification.

Currently these words are used in a way pretty close to their usual
English meaning. When a frame is being transported inside a TRILL
Header, the Ethernet header on the outside of the frame is called the
Outer header and the one inside the envelope is called the Inner header.
But, when talking about a native frame, what will become the Inner
header when encapsulated is also called an Outer header, because it is
on the outside of the native frame.

This doesn't bother me and I suspect is fine for native English speakers
because the inside/outside connotation of Inner and Outer override any
problem with the same header fields being called Outer when they are at
the start of a native frame and Inner when they are inside a TRILL
envelope.

However, some find this very confusing. For example, consider someone
implementing an Rbridge where the VLAN associated with an incoming frame
is considered meta data stored in a register/variable separate from but
associated with the frame payload. (The VLAN might come from an Outer
VLAN Tag or be assigned based on the port, etc.) What are you going to
call this register/variable? If the incoming frame is a native frame
then, if it is encapsulated, this VLAN tag information will appear in
the "Inner VLAN" position. But if the frame is forwarded in native form
to another local link, it will appear in the "Outer VLAN" position. So
neither Inner nor Outer seems to be an appropriate name for this
hypothetical register/variable.

It has been suggested that "Inner" be changed to "Data" and "Outer" be
changed to "Transport" for TRILL frames and to "Data" from native
frames, or some similar change. I think that such naming would be
reasonably clear and would have the effect that, for example, the Data
VLAN Tag could be called that whether it appeared on the outside of a
native frame or inside a TRILL envelope. 

I don't really care one way or the other and am soliciting working group
opinion on this question.

Thanks,
Donald

Content-class: urn:content-classes:message
Date: Mon, 2 Jul 2007 14:33:29 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 11181

Hi Anoop,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Sunday, July 01, 2007 4:27 PM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] a clarification about the core IS-IS instance

Donald,

This does assume that the IS-IS instance used
by TRILL uses an address (all-rbridges) that is
different than that used today by IS-IS.

@@@ Right. That's what the current and all previous version of the
Rbridge/TRILL protocol have assumed. You certainly wouldn't want to use
the same multicast address as Layer-3 IS-IS because it would increase
the chances for confusion between Layer 3 IS-IS messages and TRILL IS-IS
messages.

Why can't we just get a separate address for
this?  That way, an all-rbridges address must
never appear in the inner mac da field.

@@@ I don't understand what problem you are trying to solve. In the
current protocol draft (-04), the inner MAC DA field is All-Rbridges if
and only if it is a TRILL IS-IS frame. We could get a "separate"
multicast address for this, say "All-TBD". Then the inner MAC DA field
would be "All-TBD" if and only if it is a TRILL IS-IS frame. Why is it
easier to check for one 48 bit value than another 48 bit value?

@@@ I understood your previous statement to have mean that you would
prefer a different multicast address to a TRILL Header bit. That's fine,
assuming we have to make that choice. In fact, if the multicast
addresses were consecutive, as seems likely, you are really just saying
you would prefer a flag bit in the bottom bit of the multicast address
to a flag bit in the TRILL Header. But it turns out we don't need a flag
bit at all, in either place. So I just don't understand what the purpose
of a second multicast address would be.

@@@ I would have thought you would like the decision tree described
below since
	(1) it uses the current TRILL Header fields as specified in the
current draft and you have said you don't want to move any fields
around,
	(2) it has no dependency on a TRILL Header "IS-IS" Flag or V
field value, as you requested,
	(3) it uses only the fields that you listed as reasonable inputs
to forwarding/processing decisions, and
	(4) it clearly works.

@@@ Thanks,
@@@ Donald

Anoop

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, June 29, 2007 12:56 PM
> To: [email-masked]
> Subject: Re: [rbridge] a clarification about the core IS-IS instance
> 
> Hi,
> 
> I've been thinking about this some more and come to the 
> conclusion that,
> with the arrangement added in protocol specification -04 where a TRILL
> Header is always present, we don't need a bit to distinguish 
> TRILL IS-IS
> frames from TRILL data frames. That's because we can do so using the
> inner MAC destination address.  There isn't any need for any 
> additional
> multicast addresses.
> 
> There are different ways to order the tests that are 
> equivalent but here
> is how I think of it (leaving out some details like VLANs for 
> clarity):
> 
> The first thing to do is to test if the Ethertype is TRILL.
> 
> (1) If the Ethertype is not TRILL, you have a native frame 
> and I believe
> the processing described in the -04 draft, while it could be more
> detailed, is correct, starting with discarding the frame 
> unless you are
> acting as the Designated Rbridge (DRB).
> 
> (2) If the Ethertype is TRILL, your DRB status doesn't matter. If the
> frame is well formed, the outer MAC destination address will either be
> All Rbridges or a unicast address. If its unicast and not addressed to
> you, you discard the frame. At this point, you can check the inner MAC
> destination address.
> 
> (2A) If the inner MAC destination address is not All 
> Rbridges, you have
> a TRILL data frame.
> 
> (2B) If the inner MAC destination address is All Rbridges, you have a
> TRILL IS-IS frame. If the inner VLAN tag is absent, it is a core
> instance frame. If the inner VLAN tag is present, it is a per VLAN
> instance frame.
> 
> So, it now appears to me that a Header flag bit to distinguish TRILL
> data from TRILL IS-IS is not necessary.
> 
> Thanks,
> Donald
> 
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Friday, June 29, 2007 3:10 PM
> To: Silvano Gai; Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Silvano/Donald/Radia,
> 
> I would prefer to see a different multicast address
> used for the TRILL IS-IS instances.  Was there any
> consensus on this at the time it was discussed.  I
> do remember seeing the discussion, but I can't remember
> how it concluded.
> 
> Anoop 
> 
> > From: Silvano Gai [mailto:[email-masked]] 
> > Sent: Thursday, June 28, 2007 1:54 PM
> > To: Eastlake III Donald-LDE008; Anoop Ghanwani
> > Cc: [email-masked]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> > 
> > Donald,
> > 
> > Radia confirmed that all the ISIS messages are sent to multicast
> > addresses and therefore we discussed the possibility to use separate
> > multicast addresses instead of the V bit
> > 
> > -- Silvano
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Behalf Of Eastlake III Donald-LDE008
> > > Sent: Thursday, June 28, 2007 8:46 AM
> > > To: Anoop Ghanwani
> > > Cc: [email-masked]
> > > Subject: Re: [rbridge] a clarification about the core 
> IS-IS instance
> > > 
> > > If it were not for the V bit, how would you distinguish an IS-IS
> > routing
> > > packet conveying layer 3 routing information being sent 
> > inside a TRILL
> > > data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
> > inside
> > > a TRILL IS-IS frame?
> > > 
> > > Donald
> > > 
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Sent: Thursday, June 28, 2007 10:34 AM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [email-masked]
> > > Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> > > 
> > > Hi Donald,
> > > 
> > > Thanks again.
> > > 
> > > What's the function of the V-bit in all
> > > of this?  What does an RBridge gain by looking
> > > at this, that it cannot get by looking at
> > > fields that it already has to?
> > > 
> > > Anoop
> > > 
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[email-masked]]
> > > > Sent: Thursday, June 28, 2007 7:30 AM
> > > > To: Anoop Ghanwani
> > > > Cc: [email-masked]
> > > > Subject: RE: [rbridge] a clarification about the core 
> > IS-IS instance
> > > >
> > > > Hi Anoop,
> > > >
> > > > That looks about right, although you also have to check that
> > > > the inner length/type field is in the length range. And if
> > > > you determine that a TRILL IS-IS frame is for a per VLAN
> > > > instance, you still don't know if you should process as well
> > > > as forwarding it until you check whether you are DRB for a
> > > > link with an end station in that VLAN.
> > > >
> > > > Donald
> > > >
> > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > Sent: Thursday, June 28, 2007 10:00 AM
> > > > To: Eastlake III Donald-LDE008
> > > > Cc: [email-masked]
> > > > Subject: RE: [rbridge] a clarification about the core 
> > IS-IS instance
> > > >
> > > > Hi Donald,
> > > >
> > > > Thanks for the clarification.  Yes, I do remember the
> > > > discussion on the list.  At that time it looked like the
> > > > Ethertype would tell if the frame was IS-IS.
> > > > It now looks like even the core IS-IS instance will use a
> > > > DSAP/SSAP (for some reason I thought we were going to use a
> > > > new Ethertype for the core IS-IS instance).
> > > >
> > > > So, to identify a core IS-IS frame (which all RBridges should
> > > > be interested in) one would have to check for:
> > > > outer.etype = trill
> > > > inner.dsap = xx
> > > > inner.ssap = xx
> > > > inner.ctl = yy
> > > > inner.vlan = not present
> > > >
> > > > The V bit doesn't really seem all that useful since both the
> > > > core frames and the per-VLAN instance have it set, so that
> > > > bit doesn't tell one whether or the packet needs to be
> > > > processed as a control packet at a given RBridge.  The above
> > > > fields are necessary and sufficient.  Please let me know if
> > > > I'm missing something re the V bit.
> > > >
> > > > Thanks,
> > > > Anoop
> > > >
> > > > > From: Eastlake III Donald-LDE008
> > > > > [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 27, 2007 9:09 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [rbridge] a clarification about the core IS-IS
> > instance
> > > > >
> > > > > Hi Anoop,
> > > > >
> > > > > Yes, that was a change that was extensively discussed on
> > > > the mailing
> > > > > list. There wasn't a formal consensus determination but it
> > > > was clear
> > > > > that the sentiment of the group was to always have a TRILL
> > > > Header on
> > > > > TRILL IS-IS frames and use a formerly reserved bit in 
> the header
> > to
> > > > > distinguish a TRILL IS-IS frame from a TRILL data frame
> > > > whose contents
> > > > > happens to be a (presumably layer 3) IS-IS message.
> > > > >
> > > > > I believe your second point is correct. Checking for the TRILL
> > > > > Ethertype is the key to deciding whether to process a frame
> > > > if you are
> > > > > not DRB on that port and VLAN. (This ignores the
> > > > bridging/media frames
> > > > > sent to the block of multicast 16 addresses reserved for that
> > > > > purpose.)
> > > > >
> > > > > Thanks,
> > > > > Donald
> > > > >
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of 
> Anoop Ghanwani
> > > > > Sent: Wednesday, June 27, 2007 9:42 PM
> > > > > To: [email-masked]
> > > > > Subject: [rbridge] a clarification about the core 
> IS-IS instance
> > > > >
> > > > > From reading the previous version of the draft I got the
> > impression
> > > > > that frames sent as part of the core IS-IS would not
> > > > contain a trill
> > > > > header or inner header.  However, on reading this version, it
> > looks
> > > > > like the core IS-IS instance would in fact contain a 
> > trill header.
> > > > >
> > > > > Assuming that the above is true, would it be safe to 
> assume that
> > an
> > > > > RBridge, for a port that is connected to a LAN for which it
> > > > is not a
> > > > > DRB, will drop all frames whose Ethertype does not 
> > indicate trill?
> > > > >
> > > > > Anoop
> > > > >
> > > >
> > > 
> > > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Sun, 1 Jul 2007 13:29:35 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 8119

Radia,

I would prefer a separate multicast address.
I think Silvano also said he would prefer it that way.
It makes things a lot simple from a parsing/frame 
validation standpoint.

Anoop 

> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Friday, June 29, 2007 10:27 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] a clarification about the core IS-IS instance
> 
> At the time I thought there might be some IS-IS messages sent 
> unicast. 
> If that were
> true (which it turns out it isn't), then differentiating 
> based on multicast addresses would not have worked.
> 
> I don't think this is a big deal either way, and I don't 
> think anyone had strong opinions about it.
> 
> Radia
> 
> 
> 
> 
> Anoop Ghanwani wrote:
> > Silvano/Donald/Radia,
> >
> > I would prefer to see a different multicast address used 
> for the TRILL 
> > IS-IS instances.  Was there any consensus on this at the 
> time it was 
> > discussed.  I do remember seeing the discussion, but I 
> can't remember 
> > how it concluded.
> >
> > Anoop
> >
> >   
> >> From: Silvano Gai [mailto:[email-masked]]
> >> Sent: Thursday, June 28, 2007 1:54 PM
> >> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> >> Cc: [email-masked]
> >> Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> >>
> >>
> >> Donald,
> >>
> >> Radia confirmed that all the ISIS messages are sent to multicast 
> >> addresses and therefore we discussed the possibility to 
> use separate 
> >> multicast addresses instead of the V bit
> >>
> >> -- Silvano
> >>
> >>     
> >>> From: [email-masked] 
> [mailto:[email-masked]]
> >>>       
> >> On
> >>     
> >>> Behalf Of Eastlake III Donald-LDE008
> >>> Sent: Thursday, June 28, 2007 8:46 AM
> >>> To: Anoop Ghanwani
> >>> Cc: [email-masked]
> >>> Subject: Re: [rbridge] a clarification about the core 
> IS-IS instance
> >>>
> >>> If it were not for the V bit, how would you distinguish an IS-IS
> >>>       
> >> routing
> >>     
> >>> packet conveying layer 3 routing information being sent
> >>>       
> >> inside a TRILL
> >>     
> >>> data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
> >>>       
> >> inside
> >>     
> >>> a TRILL IS-IS frame?
> >>>
> >>> Donald
> >>>
> >>> From: Anoop Ghanwani [mailto:[email-masked]]
> >>> Sent: Thursday, June 28, 2007 10:34 AM
> >>> To: Eastlake III Donald-LDE008
> >>> Cc: [email-masked]
> >>> Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> >>>
> >>> Hi Donald,
> >>>
> >>> Thanks again.
> >>>
> >>> What's the function of the V-bit in all of this?  What does an 
> >>> RBridge gain by looking at this, that it cannot get by looking at 
> >>> fields that it already has to?
> >>>
> >>> Anoop
> >>>
> >>>       
> >>>> From: Eastlake III Donald-LDE008
> >>>> [mailto:[email-masked]]
> >>>> Sent: Thursday, June 28, 2007 7:30 AM
> >>>> To: Anoop Ghanwani
> >>>> Cc: [email-masked]
> >>>> Subject: RE: [rbridge] a clarification about the core
> >>>>         
> >> IS-IS instance
> >>     
> >>>> Hi Anoop,
> >>>>
> >>>> That looks about right, although you also have to check that the 
> >>>> inner length/type field is in the length range. And if you 
> >>>> determine that a TRILL IS-IS frame is for a per VLAN 
> instance, you 
> >>>> still don't know if you should process as well as forwarding it 
> >>>> until you check whether you are DRB for a link with an 
> end station 
> >>>> in that VLAN.
> >>>>
> >>>> Donald
> >>>>
> >>>> From: Anoop Ghanwani [mailto:[email-masked]]
> >>>> Sent: Thursday, June 28, 2007 10:00 AM
> >>>> To: Eastlake III Donald-LDE008
> >>>> Cc: [email-masked]
> >>>> Subject: RE: [rbridge] a clarification about the core
> >>>>         
> >> IS-IS instance
> >>     
> >>>> Hi Donald,
> >>>>
> >>>> Thanks for the clarification.  Yes, I do remember the 
> discussion on 
> >>>> the list.  At that time it looked like the Ethertype 
> would tell if 
> >>>> the frame was IS-IS.
> >>>> It now looks like even the core IS-IS instance will use 
> a DSAP/SSAP 
> >>>> (for some reason I thought we were going to use a new 
> Ethertype for 
> >>>> the core IS-IS instance).
> >>>>
> >>>> So, to identify a core IS-IS frame (which all RBridges should be 
> >>>> interested in) one would have to check for:
> >>>> outer.etype = trill
> >>>> inner.dsap = xx
> >>>> inner.ssap = xx
> >>>> inner.ctl = yy
> >>>> inner.vlan = not present
> >>>>
> >>>> The V bit doesn't really seem all that useful since both 
> the core 
> >>>> frames and the per-VLAN instance have it set, so that 
> bit doesn't 
> >>>> tell one whether or the packet needs to be processed as 
> a control 
> >>>> packet at a given RBridge.  The above fields are necessary and 
> >>>> sufficient.  Please let me know if I'm missing something 
> re the V 
> >>>> bit.
> >>>>
> >>>> Thanks,
> >>>> Anoop
> >>>>
> >>>>         
> >>>>> From: Eastlake III Donald-LDE008
> >>>>> [mailto:[email-masked]]
> >>>>> Sent: Wednesday, June 27, 2007 9:09 PM
> >>>>> To: Anoop Ghanwani
> >>>>> Cc: [email-masked]
> >>>>> Subject: RE: [rbridge] a clarification about the core IS-IS
> >>>>>           
> >> instance
> >>     
> >>>>> Hi Anoop,
> >>>>>
> >>>>> Yes, that was a change that was extensively discussed on
> >>>>>           
> >>>> the mailing
> >>>>         
> >>>>> list. There wasn't a formal consensus determination but it
> >>>>>           
> >>>> was clear
> >>>>         
> >>>>> that the sentiment of the group was to always have a TRILL
> >>>>>           
> >>>> Header on
> >>>>         
> >>>>> TRILL IS-IS frames and use a formerly reserved bit in the header
> >>>>>           
> >> to
> >>     
> >>>>> distinguish a TRILL IS-IS frame from a TRILL data frame
> >>>>>           
> >>>> whose contents
> >>>>         
> >>>>> happens to be a (presumably layer 3) IS-IS message.
> >>>>>
> >>>>> I believe your second point is correct. Checking for the TRILL 
> >>>>> Ethertype is the key to deciding whether to process a frame
> >>>>>           
> >>>> if you are
> >>>>         
> >>>>> not DRB on that port and VLAN. (This ignores the
> >>>>>           
> >>>> bridging/media frames
> >>>>         
> >>>>> sent to the block of multicast 16 addresses reserved for that
> >>>>> purpose.)
> >>>>>
> >>>>> Thanks,
> >>>>> Donald
> >>>>>
> >>>>> From: [email-masked]
> >>>>> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
> >>>>> Sent: Wednesday, June 27, 2007 9:42 PM
> >>>>> To: [email-masked]
> >>>>> Subject: [rbridge] a clarification about the core IS-IS instance
> >>>>>
> >>>>> From reading the previous version of the draft I got the
> >>>>>           
> >> impression
> >>     
> >>>>> that frames sent as part of the core IS-IS would not
> >>>>>           
> >>>> contain a trill
> >>>>         
> >>>>> header or inner header.  However, on reading this version, it
> >>>>>           
> >> looks
> >>     
> >>>>> like the core IS-IS instance would in fact contain a
> >>>>>           
> >> trill header.
> >>     
> >>>>> Assuming that the above is true, would it be safe to assume that
> >>>>>           
> >> an
> >>     
> >>>>> RBridge, for a port that is connected to a LAN for which it
> >>>>>           
> >>>> is not a
> >>>>         
> >>>>> DRB, will drop all frames whose Ethertype does not
> >>>>>           
> >> indicate trill?
> >>     
> >>>>> Anoop
> >>>>>
> >>>>>           
> >>> [email-masked]
> > [email-masked]

Content-class: urn:content-classes:message
Date: Sun, 1 Jul 2007 13:27:14 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 9212

Donald,

This does assume that the IS-IS instance used
by TRILL uses an address (all-rbridges) that is
different than that used today by IS-IS.

Why can't we just get a separate address for
this?  That way, an all-rbridges address must
never appear in the inner mac da field.

Anoop

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, June 29, 2007 12:56 PM
> To: [email-masked]
> Subject: Re: [rbridge] a clarification about the core IS-IS instance
> 
> Hi,
> 
> I've been thinking about this some more and come to the 
> conclusion that,
> with the arrangement added in protocol specification -04 where a TRILL
> Header is always present, we don't need a bit to distinguish 
> TRILL IS-IS
> frames from TRILL data frames. That's because we can do so using the
> inner MAC destination address.  There isn't any need for any 
> additional
> multicast addresses.
> 
> There are different ways to order the tests that are 
> equivalent but here
> is how I think of it (leaving out some details like VLANs for 
> clarity):
> 
> The first thing to do is to test if the Ethertype is TRILL.
> 
> (1) If the Ethertype is not TRILL, you have a native frame 
> and I believe
> the processing described in the -04 draft, while it could be more
> detailed, is correct, starting with discarding the frame 
> unless you are
> acting as the Designated Rbridge (DRB).
> 
> (2) If the Ethertype is TRILL, your DRB status doesn't matter. If the
> frame is well formed, the outer MAC destination address will either be
> All Rbridges or a unicast address. If its unicast and not addressed to
> you, you discard the frame. At this point, you can check the inner MAC
> destination address.
> 
> (2A) If the inner MAC destination address is not All 
> Rbridges, you have
> a TRILL data frame.
> 
> (2B) If the inner MAC destination address is All Rbridges, you have a
> TRILL IS-IS frame. If the inner VLAN tag is absent, it is a core
> instance frame. If the inner VLAN tag is present, it is a per VLAN
> instance frame.
> 
> So, it now appears to me that a Header flag bit to distinguish TRILL
> data from TRILL IS-IS is not necessary.
> 
> Thanks,
> Donald
> 
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Friday, June 29, 2007 3:10 PM
> To: Silvano Gai; Eastlake III Donald-LDE008
> Cc: [email-masked]
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Silvano/Donald/Radia,
> 
> I would prefer to see a different multicast address
> used for the TRILL IS-IS instances.  Was there any
> consensus on this at the time it was discussed.  I
> do remember seeing the discussion, but I can't remember
> how it concluded.
> 
> Anoop 
> 
> > From: Silvano Gai [mailto:[email-masked]] 
> > Sent: Thursday, June 28, 2007 1:54 PM
> > To: Eastlake III Donald-LDE008; Anoop Ghanwani
> > Cc: [email-masked]
> > Subject: RE: [rbridge] a clarification about the core IS-IS instance
> > 
> > Donald,
> > 
> > Radia confirmed that all the ISIS messages are sent to multicast
> > addresses and therefore we discussed the possibility to use separate
> > multicast addresses instead of the V bit
> > 
> > -- Silvano
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Behalf Of Eastlake III Donald-LDE008
> > > Sent: Thursday, June 28, 2007 8:46 AM
> > > To: Anoop Ghanwani
> > > Cc: [email-masked]
> > > Subject: Re: [rbridge] a clarification about the core 
> IS-IS instance
> > > 
> > > If it were not for the V bit, how would you distinguish an IS-IS
> > routing
> > > packet conveying layer 3 routing information being sent 
> > inside a TRILL
> > > data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
> > inside
> > > a TRILL IS-IS frame?
> > > 
> > > Donald
> > > 
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Sent: Thursday, June 28, 2007 10:34 AM
> > > To: Eastlake III Donald-LDE008
> > > Cc: [email-masked]
> > > Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> > > 
> > > Hi Donald,
> > > 
> > > Thanks again.
> > > 
> > > What's the function of the V-bit in all
> > > of this?  What does an RBridge gain by looking
> > > at this, that it cannot get by looking at
> > > fields that it already has to?
> > > 
> > > Anoop
> > > 
> > > > From: Eastlake III Donald-LDE008
> > > > [mailto:[email-masked]]
> > > > Sent: Thursday, June 28, 2007 7:30 AM
> > > > To: Anoop Ghanwani
> > > > Cc: [email-masked]
> > > > Subject: RE: [rbridge] a clarification about the core 
> > IS-IS instance
> > > >
> > > > Hi Anoop,
> > > >
> > > > That looks about right, although you also have to check that
> > > > the inner length/type field is in the length range. And if
> > > > you determine that a TRILL IS-IS frame is for a per VLAN
> > > > instance, you still don't know if you should process as well
> > > > as forwarding it until you check whether you are DRB for a
> > > > link with an end station in that VLAN.
> > > >
> > > > Donald
> > > >
> > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > Sent: Thursday, June 28, 2007 10:00 AM
> > > > To: Eastlake III Donald-LDE008
> > > > Cc: [email-masked]
> > > > Subject: RE: [rbridge] a clarification about the core 
> > IS-IS instance
> > > >
> > > > Hi Donald,
> > > >
> > > > Thanks for the clarification.  Yes, I do remember the
> > > > discussion on the list.  At that time it looked like the
> > > > Ethertype would tell if the frame was IS-IS.
> > > > It now looks like even the core IS-IS instance will use a
> > > > DSAP/SSAP (for some reason I thought we were going to use a
> > > > new Ethertype for the core IS-IS instance).
> > > >
> > > > So, to identify a core IS-IS frame (which all RBridges should
> > > > be interested in) one would have to check for:
> > > > outer.etype = trill
> > > > inner.dsap = xx
> > > > inner.ssap = xx
> > > > inner.ctl = yy
> > > > inner.vlan = not present
> > > >
> > > > The V bit doesn't really seem all that useful since both the
> > > > core frames and the per-VLAN instance have it set, so that
> > > > bit doesn't tell one whether or the packet needs to be
> > > > processed as a control packet at a given RBridge.  The above
> > > > fields are necessary and sufficient.  Please let me know if
> > > > I'm missing something re the V bit.
> > > >
> > > > Thanks,
> > > > Anoop
> > > >
> > > > > From: Eastlake III Donald-LDE008
> > > > > [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 27, 2007 9:09 PM
> > > > > To: Anoop Ghanwani
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [rbridge] a clarification about the core IS-IS
> > instance
> > > > >
> > > > > Hi Anoop,
> > > > >
> > > > > Yes, that was a change that was extensively discussed on
> > > > the mailing
> > > > > list. There wasn't a formal consensus determination but it
> > > > was clear
> > > > > that the sentiment of the group was to always have a TRILL
> > > > Header on
> > > > > TRILL IS-IS frames and use a formerly reserved bit in 
> the header
> > to
> > > > > distinguish a TRILL IS-IS frame from a TRILL data frame
> > > > whose contents
> > > > > happens to be a (presumably layer 3) IS-IS message.
> > > > >
> > > > > I believe your second point is correct. Checking for the TRILL
> > > > > Ethertype is the key to deciding whether to process a frame
> > > > if you are
> > > > > not DRB on that port and VLAN. (This ignores the
> > > > bridging/media frames
> > > > > sent to the block of multicast 16 addresses reserved for that
> > > > > purpose.)
> > > > >
> > > > > Thanks,
> > > > > Donald
> > > > >
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of 
> Anoop Ghanwani
> > > > > Sent: Wednesday, June 27, 2007 9:42 PM
> > > > > To: [email-masked]
> > > > > Subject: [rbridge] a clarification about the core 
> IS-IS instance
> > > > >
> > > > > From reading the previous version of the draft I got the
> > impression
> > > > > that frames sent as part of the core IS-IS would not
> > > > contain a trill
> > > > > header or inner header.  However, on reading this version, it
> > looks
> > > > > like the core IS-IS instance would in fact contain a 
> > trill header.
> > > > >
> > > > > Assuming that the above is true, would it be safe to 
> assume that
> > an
> > > > > RBridge, for a port that is connected to a LAN for which it
> > > > is not a
> > > > > DRB, will drop all frames whose Ethertype does not 
> > indicate trill?
> > > > >
> > > > > Anoop
> > > > >
> > > >
> > > 
> > > [email-masked]
> [email-masked]