Subject: [rbridge] per-VLAN instances of IS-IS

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 8 Jun 2007 09:59:21 -0700

Section 3.3.3.2 of the rBridge base spec 
talks about the per VLAN instance of IS-IS.

I can see why that would be useful.
However, if looks like there could be
problems scaling.  If an end rBridge 
participates in 1000 VLANs, it will have
to maintain 1000 adjacencies.  

Plus, it looks like for the per-VLAN IS-IS
instance, the RBridge network operates
as single LAN segment.  That would mean
having to go through DR/BDR election for
each instance.  

Operating 100's of routers on a single 
LAN segment would poses its own set of 
scaling issues.  Having per VLAN instances
exacerbates the problem.

Have the scaling issues been considered
at all?  It might actually be better to
just use the core IS-IS instance.

The following statement in Section 3.3.3.2
of the draft appears to be incorrect/incomplete:

"RBridges with endnodes in VLAN A also 
receive and process the frame in their 
VLAN-A IS-IS instance."

The frame also has to be processed by all
RBridges that might be along the path for
reaching the VLANs, otherwise we wouldn't
be able to prune the distribution trees
correctly.

Anoop

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Fri, 8 Jun 2007 12:41:22 -0500

Anoop,

	Having per-VLAN instances of IS-IS helps to simplify 
interactions - thus increasing the likelihood of correct 
specification leading to interoperable implementations.

	This is accomplished at some cost in extremely complex
deployment scenarios - such as the one you cite as an example
- but the cost is not nearly as high as you make it sound.

	Please see in-line comments below for further details.

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani
> Sent: Friday, June 08, 2007 12:59 PM
> To: rbridge at postel.org
> Subject: [rbridge] per-VLAN instances of IS-IS
> 
> 
> problems scaling.  

I am not convinced that you do.  Having a per-VLAN IS-IS
instance greatly simplifies interactions, and allows us 
to effectively define RBridges in a single VLAN context
- leaving implementers free to implement inter-VLAN as 
already implemented in 802.1Q (and related) implementation.

This is more than just "useful."  See below for further
clarification.

> If an end rBridge 

This is effectively true if we postulate only a single IS-IS
instance for all VLANs, because you have to scope routing
activities, link-state, etc. - on a per-VLAN basis even if
that is the case.

What you accomplish by using a single instance is to make it
far more difficult to describe, understand and correctly
implement RBridge routing protocol behaviors.
 
> having to go through DR/BDR election for

And this would be correct behavior.  An RBridge should only
be eligible for ingress and egress to a local VLAN is it is
configured to participate in that local VLAN.  Hence, it may
only participate in DR election for VLANs on a local bridged
LAN if it participates in those VLANs.

This is central to one of the issues with specifying - and
correctly implementing - RBridge functionality.

There are optimizations we may consider at a later date that
will reduce - for example - messaging overhead, and there are
already existing optimizations to reduce the actual state
maintenance overhead to roughly the same as would be the case
with a single IS-IS instance.
 
> scaling issues.  Having per VLAN instances

Are there deployment scenarios in today's bridging community
where we support this kind of network as a bidged network?

If there are not, then please recall that sclability of the
current solution is targetted only for routghly the same
size networks as can be established with bridging today.

You make it sound as if we're expected to solve problems 
with RBridges for which solutions have never been specified
for routing.

As for complicating the problem with VLAN instances, think
about how complicated this scenario would be already with 
802.1Q VLANs running any of today's spanning tree protocols.

Also, note that in this same situation with routers in place
of RBridges, each router would most likely be required to 
have a logical interface in each VLAN on every link to which
it is connected.

In other words, this situation is just plain complicated -
irrespective of what you're trying to do to deal with it.

> just use the core IS-IS instance.

Scaling has been considered.  Large increases in scalability 
are not a primary goal - relative to existing bridging, for
example.

RTFC!  Increased scalability over existing bridging was 
explicitly NOT included in the charter as a goal.

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

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 8 Jun 2007 13:47:53 -0400

Hi Anoop,

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 08, 2007 12:59 PM
To: rbridge at postel.org
Subject: [rbridge] per-VLAN instances of IS-IS

@@@ These issues have been raised, although the possibility of using the
core IS-IS instances hasn't been discussed much.  If you do have 1,000
VLANs, using the core instance means that every Rbridge in the campus
would have to know all end stations, even if that Rbridge is in an area
of the campus that only uses one or a few VLANs.

@@@ The WG appears to favor a change so that all Rbridges MUST be able
to learn entirely from data, the way IEEE 802.1 bridges do, based on
frames that they encapsulate and decapsulate. There are, however,
advantages to using the per VLAN IS-IS instances, such as improved
security in learning remote end node addresses if those end states
register with their local Rbridge using some layer 2 protocol such as
802.1X and IS-IS security is in use for the IS-IS messages. So it seems
appropriate at this time to say in the draft that Rbridges MAY implement
and use the per VLAN IS-IS technique. Of course, it should also be
possible to use a management protocol to configure end station
addresses, configure so as to turn off learning from data, etc.

@@@ I expect the next version of the protocol specification to reflect
this change so that learning only from data is the zero configuration
method.

@@@ Right. It actually says "... all RBridges forward it as an ordinary
frame in VLAN A ..." in the previous paragraph.

Anoop

@@@ Thanks,
@@@ Donald

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 8 Jun 2007 18:15:04 -0700

> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
>
...
> This is more than just "useful."  See below for further

I'm not quite sure I get it, but I'll look below.

> implement RBridge routing protocol behaviors.

I understand there will be some complexity in
describing all the VLANs and multicast addresses
in a single instance, but I think it scales better
than multiple instances.  Why?  Consider the
following picture:

           D
           |
v1 -- A -- B -- C -- v1
           | 
           E

A-E are RBridges.

In this picture VLAN v1 is configured only on A
and C.  B doesn't have v1 configured on it.  Yet
B needs to know about VLAN v1's location in order
to correctly prune its trees.

What I'm getting at is that all RBridges in the 
network need to know about all VLANs so that they
can prune their trees for each VLAN correctly.

If you have an instance per VLAN we are talking
about maintain up to 4K instances in each Rbridge.
And it's not unheard of to configure a 1000
VLANs in regular 802.1Q device.

> LAN if it participates in those VLANs.

See above for why this is not true.  Or
tell me how I can do pruning without interior
RBridges knowing about all VLANs.

> where we support this kind of network as a bidged network?

Not in a bridged network.  But if I recall correctly,
and I may be off since the charter may have changed
since the beginning, one of the goals of rBridges was
to be able to build large campuses without routers
and routing-related configuration.  Has that gone away?
It is not atypical to find a campus with 20K users
on 100's of VLANs with ~100 nodes.

> size networks as can be established with bridging today.

Even with a network of today's bridges there would
be scaling issues if you had say 20-30 rBridges
all trying to establish adjacencies between groups
of themselves for a few 100 VLANs.  It is not 
atypical to have ~1000 VLANs configured in core
switches.

> 802.1Q VLANs running any of today's spanning tree protocols.

They scale just fine because they limit the 
maximum number of trees and have some VLANs share
a tree.  They don't try to run one STP instance
per VLAN.
 
> have a logical interface in each VLAN on every link to which

This cannot be compared with routers.  We're talking
about bridging here.  If we routed, we'd just terminate
the MAC domain at the edge router and we wouldn't
run into any of these issues.  No sense in having a
VLAN interface on every router in the campus.
(One could design the network that way, but it would
be a really bad way to do it.)
 
> explicitly NOT included in the charter as a goal.

I thought I knew what the charter was but I went back
and read it again anyway.  I didn't find much there
to work with with respect to scalability requirements.
It talks about a "problem statement and applicability"
document.  I'm not sure which of the published documents
that is. 

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 8 Jun 2007 18:25:08 -0700

> From: Eastlake III Donald-LDE008 
> 
> See below at @@@
> 
..
> this change so that learning only from data is the zero configuration

The learning approach will work for unicast addresses.
It will not work for pruning the trees for multicast
addresses and flooding to VLANs.  Those addresses
and VLAN membership information needs to be sent
around to all RBridges in the network.

> frame in VLAN A ..." in the previous paragraph.

This doesn't work.  See my response to Eric 
for why it doesn't.

Thanks,
Anoop

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sat, 9 Jun 2007 08:06:31 -0700

Anoop,

You are right; there is a tremendous scalability issue.

My proposal is to completely drop the per-VLAN ISIS instance and learn
from data frames. Proven, scalable, it works.

-- Silvano

> Sent: Friday, June 08, 2007 9:59 AM

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sat, 9 Jun 2007 10:01:35 -0700

Anoop,

The proposal for multicast is to move this information in the core
inbstance of ISIS.

-- Silvano

> Sent: Friday, June 08, 2007 6:25 PM
> To: Eastlake III Donald-LDE008
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> 
>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 9 Jun 2007 20:33:26 -0400

See below at ###

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Saturday, June 09, 2007 1:02 PM
To: Anoop Ghanwani; Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Anoop,

### If you referring to the various multicast listener and IP multicast
router information, it has to be in the core instance so pruning can
happen in transit Rbridges.

-- Silvano

> around to all RBridges in the network.

### Correct, that information has to be in the core instance and is
incorrectly shown in the current draft as being in the per VLAN
instance.

### Donald

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Mon, 11 Jun 2007 10:55:29 -0500

Anoop,

	Thanks for the well thought out reply.  Please see continuing 
discussion below...

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:anoop at brocade.com] 
> Sent: Friday, June 08, 2007 9:15 PM
> To: Eric Gray (LO/EUS)
> Importance: High

Note that this configuration - if A-E were Q-bridges - 
would be pathological, resulting in segmenting v1.

I believe you've over-simplified interactions to make
a point, and the result is an example that does not 
make that point.

In the above scenario, two simple approaches might have
been used that would not share the pathology of the given
example:

1) B might be configured to support v1 (flat model).
2) A and C might be configured to tunnel (e.g. - Q-in-Q)
   v1 via B, using a VID for which B is configured
   (hierarchical model).

It may be difficult to imagine why the second choice may
be useful, given the over-simplified example, but it is
actually quite likely to be useful in complex secnarios
- particularly involving edge bridges with very large 
numbers of subscriber-facing ports with large overlap
in VLAN membership among edge bridges.

These same approaches are also useful with RBridges.

> can prune their trees for each VLAN correctly.

Yes, in a flat model, this would be true.  With the
alternative approach, only edge RBridges really have
to know about VLANs at the edge.  Pruding in core 
RBridges occurs as a consequence of Q-in-Q (or like
approach) configuration.

> VLANs in regular 802.1Q device.

Yes.  I believe this essentially makes my point.  It
is done today, with today's bridges, hence scalability
is apparently not a real concern (yet).

> RBridges knowing about all VLANs.

Use a hierarchical model model with VID-based tunneling.

This is not a trivially easy configuration for some real-world
deployment scenarios we can all probably imagine.  But it is
also not as trivially easy to break, once correctly configured.

> on 100's of VLANs with ~100 nodes.

That never was a goal.  There are people who might like to make
it one, but that's (IMO) a malignant nightmare.

There is no conceivable way to build devices that do everything
a router does without incorporating all of the complexity (read
"cost") of a router into that device.  If that's what somebody
really wants to do, then I'd like to hear how they propose to
design routing complexity - using a routing protocol, and putting
everything else a router does into it - without the end product 
actually being MORE complex (read "expensive") than anybody's 
current routing implementation.

> atypical to have ~1000 VLANs configured in core

So, for IS-IS (or OSPF), issues with "adjacencies" are not
subject to the same sorts of concerns as (for example) BGP.

What maintaining adjacencies really means is keeping up to
date on link state for a peer-set.  What you're pointing 
out is that - for many VLANs - the numer of peer-sets for
which link state has to be maintained may be large.

Short of using hierarchical VLANs, this is competely and
absolutely unavoidable - unless we're going to accept the
consequences of specifying incorrect VLAN interactions as
a mechanism for effectively doing the same thing (i.e. -
effectively specifying hierarchy using some other means,
or simply hoping that people can somehow get it right).

If you assume - as I do - that VLAN traffic is only supposed
to traverse links for which that VLAN is configured (either
explicitly or implicity), than not including a VLAN (again,
either explicitly or implicitly) in the configuration for a
specific link means that that VLAN's traffic is not supposed
to traverse that link.  Period.

> a tree.  They don't try to run one STP instance

Right.  Assuming you've gotten your head around the notion of
hierarchical VLANs, how is this different?

> be a really bad way to do it.)

The point is that - if you had 1000 (or 4000) VLANs, in a
subnet, you would terminate a large percentage of those on
connected routers.

If you imagine that there are many sch subnets (as seems to
be implied in your earlier comments), then this would also
be true for other physical interfaces on each router.

Also, if you believe that RBridges may be used to replace
routers, then you compound this issue.

> document.  I'm not sure which of the published documents

It is the one that has that name.  Joe Touch is the main
author/editor (with Radia Perlman).  It apparently has been 
allowed to expire.

See: 

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=147
71

for more information.

By the way, it actually did not expire very long ago, so it
is likely that there is a new version in the works.

However, the way that IETF charters typically work is that
they are exclusive, rather than inclusive, by default.  In
other words, the fact that the charter does not explicitly
include increased scalability as a goal CANNOT be read to
mean that it may be a goal because it is not explicitly 
excluded.

Per the charter, the design goals for the TRILL solution are:

- Minimal or no configuration required
- Load-splitting among multiple paths
- Routing loop mitigation (possibly through a TTL field)
- Support of multiple points of attachment
- Support for broadcast and multicast
- No significant service delay after attachment
- No less secure than existing bridged solutions

There is nothing in these explicitly listed goals that can
be stretched to include the notion of hugely increased scale,
or replacement of routers.

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 11 Jun 2007 09:50:49 -0700

Silvano Gai wrote:
> My proposal is to completely drop the per-VLAN ISIS instance
> and learn from data frames. Proven, scalable, it works.
> 

An RFC does not tell any implementation how to store the
bits and bytes used to retain configuration data. It merely
specifies what information is retained, not how.

I do not see how the method of learning the information is
relevant to efficiently encoding it.

If your presumption is that information learned form data
frames is droppable then the efficiency in storage comes
from giving an implementation the option to forget information
that it does not find useful. But given that all implementations
have finite limits on their storage it would seem to be an 
implicit part of any protocol that did not demand that the
a node drop out of the network when it hit is memory limit.

The only other possible optimization on information retention
is if you allow assumptions about the data. Examples that come
to mind, but which are probably not acceptable, include:

a) assuming that a MAC address is unique.
b) assuming that the topology is the same for all VLANs.
   That is the topology for any VLAN is a subset of "the" topology.

Were you thinking of these or other encoding optimizations? Or is
the scalability strictly a matter of gaining the option to forget?
If so, why wouldn't the option to forget be valuable/necessary no
matter what other decisions are made?

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 11 Jun 2007 09:58:12 -0700

Eric,

I don't think it's worth continuing this discussion
since it looks like there is agreement from several
others that understand the scaling issues and it
looks like there is consensus that it needs to be
addressed.  That's all that I was hoping to achieve.

Thanks,
Anoop 

> Sent: Monday, June 11, 2007 8:55 AM
> To: Anoop Ghanwani
> 	Thanks for the well thought out reply.  Please see 
> continuing discussion below...
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> interactions - 
> > > thus increasing the likelihood of correct specification 
> leading to 
> > > interoperable implementations.
> > > 
> deployment 
> > > scenarios - such as the one you cite as an example
> > > I am not convinced that you do.  Having a per-VLAN IS-IS instance 
> > > greatly simplifies interactions, and allows us to 
> effectively define 
> > > RBridges in a single VLAN context
> > > - leaving implementers free to implement inter-VLAN as already 
> > > implemented in 802.1Q (and related) implementation.
> > > 
> > > > participates in 1000 VLANs, it will have to maintain 1000 
> > > > adjacencies.
> > > 
> > > activities, link-state, etc. - on a per-VLAN basis even 
> if that is 
> > > the case.
> > > 
> > > What you accomplish by using a single instance is to make it far 
> > > more difficult to describe, understand and correctly implement 
> > > RBridge routing protocol behaviors.
> > 
> > I understand there will be some complexity in describing 
> all the VLANs 
> > and multicast addresses in a single instance, but I think it scales 
> > better than multiple instances.  Why?  Consider the 
> following picture:
> > 
> >            D
> >            |
> > v1 -- A -- B -- C -- v1
> >            | 
> >            E
> > 
> > A-E are RBridges.
> > 
> > In this picture VLAN v1 is configured only on A and C.  B 
> doesn't have 
> > v1 configured on it.  Yet B needs to know about VLAN v1's 
> location in 
> > order to correctly prune its trees.
> 
> Note that this configuration - if A-E were Q-bridges - would 
> be pathological, resulting in segmenting v1.
> 
> I believe you've over-simplified interactions to make a 
> point, and the result is an example that does not make that point.
> 
> In the above scenario, two simple approaches might have been 
> used that would not share the pathology of the given
> example:
> 
> It may be difficult to imagine why the second choice may be 
> useful, given the over-simplified example, but it is actually 
> quite likely to be useful in complex secnarios
> - particularly involving edge bridges with very large numbers 
> of subscriber-facing ports with large overlap in VLAN 
> membership among edge bridges.
> 
> > What I'm getting at is that all RBridges in the network 
> need to know 
> > about all VLANs so that they can prune their trees for each VLAN 
> > correctly.
> 
> alternative approach, only edge RBridges really have to know 
> about VLANs at the edge.  Pruding in core RBridges occurs as 
> a consequence of Q-in-Q (or like
> approach) configuration.
> 
> > 
> > If you have an instance per VLAN we are talking about 
> maintain up to 
> > 4K instances in each Rbridge.
> > And it's not unheard of to configure a 1000 VLANs in regular 802.1Q 
> > device.
> > 
> 
> Yes.  I believe this essentially makes my point.  It is done 
> today, with today's bridges, hence scalability is apparently 
> not a real concern (yet).
> 
> > 
> > > > Plus, it looks like for the per-VLAN IS-IS instance, 
> the RBridge 
> > > > network operates as single LAN segment.  That would 
> mean having to 
> > > > go through DR/BDR election for each instance.
> > > 
> > > And this would be correct behavior.  An RBridge should only be 
> > > eligible for ingress and egress to a local VLAN is it is 
> configured 
> > > to participate in that local VLAN.  Hence, it may only 
> participate 
> > > in DR election for VLANs on a local bridged LAN if it 
> participates 
> > > in those VLANs.
> > 
> > See above for why this is not true.  Or tell me how I can 
> do pruning 
> > without interior RBridges knowing about all VLANs.
> 
> This is not a trivially easy configuration for some 
> real-world deployment scenarios we can all probably imagine.  
> But it is also not as trivially easy to break, once correctly 
> configured.
> 
> > 
> > > This is central to one of the issues with specifying - 
> and correctly 
> > > implementing - RBridge functionality.
> > > 
> > > There are optimizations we may consider at a later date that will 
> > > reduce - for example - messaging overhead, and there are already 
> > > existing optimizations to reduce the actual state maintenance 
> > > overhead to roughly the same as would be the case with a single 
> > > IS-IS instance.
> > >  
> > > > 
> > > > Operating 100's of routers on a single LAN segment 
> would poses its 
> > > > own set of scaling issues.  Having per VLAN instances 
> exacerbates 
> > > > the problem.
> > > 
> > > Are there deployment scenarios in today's bridging 
> community where 
> > > we support this kind of network as a bidged network?
> > 
> > Not in a bridged network.  But if I recall correctly, and I 
> may be off 
> > since the charter may have changed since the beginning, one of the 
> > goals of rBridges was to be able to build large campuses without 
> > routers and routing-related configuration.  Has that gone away?
> > It is not atypical to find a campus with 20K users on 100's 
> of VLANs 
> > with ~100 nodes.
> 
> That never was a goal.  There are people who might like to 
> make it one, but that's (IMO) a malignant nightmare.
> 
> There is no conceivable way to build devices that do 
> everything a router does without incorporating all of the 
> complexity (read
> "cost") of a router into that device.  If that's what 
> somebody really wants to do, then I'd like to hear how they 
> propose to design routing complexity - using a routing 
> protocol, and putting everything else a router does into it - 
> without the end product actually being MORE complex (read 
> "expensive") than anybody's current routing implementation.
> 
> > 
> > > If there are not, then please recall that sclability of 
> the current 
> > > solution is targetted only for routghly the same size networks as 
> > > can be established with bridging today.
> > 
> > Even with a network of today's bridges there would be 
> scaling issues 
> > if you had say 20-30 rBridges all trying to establish adjacencies 
> > between groups of themselves for a few 100 VLANs.  It is 
> not atypical 
> > to have ~1000 VLANs configured in core switches.
> 
> date on link state for a peer-set.  What you're pointing out 
> is that - for many VLANs - the numer of peer-sets for which 
> link state has to be maintained may be large.
> 
> consequences of specifying incorrect VLAN interactions as a 
> mechanism for effectively doing the same thing (i.e. - 
> effectively specifying hierarchy using some other means, or 
> simply hoping that people can somehow get it right).
> 
> > > You make it sound as if we're expected to solve problems with 
> > > RBridges for which solutions have never been specified 
> for routing.
> > >
> > > As for complicating the problem with VLAN instances, 
> think about how 
> > > complicated this scenario would be already with 802.1Q 
> VLANs running 
> > > any of today's spanning tree protocols.
> > 
> > They scale just fine because they limit the maximum number of trees 
> > and have some VLANs share a tree.  They don't try to run one STP 
> > instance per VLAN.
> 
> > > Also, note that in this same situation with routers in place of 
> > > RBridges, each router would most likely be required to have a 
> > > logical interface in each VLAN on every link to which it is 
> > > connected.
> > 
> > This cannot be compared with routers.  We're talking about bridging 
> > here.  If we routed, we'd just terminate the MAC domain at the edge 
> > router and we wouldn't run into any of these issues.  No sense in 
> > having a VLAN interface on every router in the campus.
> > (One could design the network that way, but it would be a 
> really bad 
> > way to do it.)
> 
> be implied in your earlier comments), then this would also be 
> true for other physical interfaces on each router.
> 
> > > > Have the scaling issues been considered at all?  It 
> might actually 
> > > > be better to just use the core IS-IS instance.
> > > 
> > > Scaling has been considered.  Large increases in 
> scalability are not 
> > > a primary goal - relative to existing bridging, for example.
> > > 
> > I thought I knew what the charter was but I went back and read it 
> > again anyway.  I didn't find much there to work with with 
> respect to 
> > scalability requirements.
> > document.  I'm not sure which of the published documents that is.
> 
> mean that it may be a goal because it is not explicitly excluded.
> 
> There is nothing in these explicitly listed goals that can be 
> stretched to include the notion of hugely increased scale, or 
> replacement of routers.
> 
> > 
> > Anoop
> > 
>

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Mon, 11 Jun 2007 12:24:04 -0500

Anoop,

	Two things:

1) From Radia's response, I think this is (again) a case of my
   getting confused by the strange use of "per-VLAN" in this 
   context.  On that score, I agree that there is little point
   in continuing that part of this discussion.  Part of the 
   reason for my confusion on this score is that I was under 
   the impression that the specific scalability concern you
   raised doesn't exist any more.

2) On the issue of scalability - in general - the responses I've
   seen are not sufficient to justify your observation for the
   general issue of scalability.  What I've seen is agreement on
   the specific issues associated with "per-VLAN" announcements
   - which, as Radia indicates, is going away.

	I believe we all need to get on that page (the one where
that particular misnomer doesn't exist).  Otherwise, we're going
to continue to create confusion over the use of IS-IS instances
(in general) and the impact that this has on scalability.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Monday, June 11, 2007 12:58 PM
> To: Eric Gray (LO/EUS)
> about bridging

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 14 Jun 2007 21:53:53 -0700

I'm catching up after travelling, so if someone else answered this, 
sorry about that.

> can prune their trees for each VLAN correctly.
Yes--all the intermediate RBridges need to know which edge RBridges (where
an "edge RBridge is one that is acting as a Designated RBridge on a link)
are attached to which VLANs.

But an RBridge that is not an edge RBridge does *not* need to know about
any endnodes. And an RBridge that is not the DR for a link in VLAN A does
*not* need to know about endnodes in VLAN A.

So...mostly I'm confused (and I think others are) about what is meant by
"a per-VLAN instance of IS-IS". When I was using the phrase I meant
the piece of IS-IS that announced VLAN A endnodes, and that information
only would have to go to RBridges that are Designated RBridge for a link 
in VLAN A.

But, as Donald said, we are switching to having the default case being 
that the
mapping between (ingress RBridge, source endnode) is learned by the egress
RBridge that decapsulates a data packet onto its link. That way only 
Designated
RBridges learn endnode locations, and only learn endnode locations that are
talking to endnodes on that RBridge's link.

We are also allowing optional advertisement of attached endnodes in VLAN A,
and optional learning from these, in a "per-VLAN IS-IS instance", which does
nothing but advertise the location of endnodes, and is broadcast only to
Designated RBridges attached to that VLAN. The intention is that endnodes
announced in this way would be endnodes that are definitively learned 
through
some sort of layer 2 enrollment protocol.

Radia

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 15 Jun 2007 11:14:43 -0700

> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Thursday, June 14, 2007 9:54 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); rbridge at postel.org

That is correct.  However, even in that scenario, I
don't think it makes sense to have a per-VLAN 
IS-IS instance - maintaining the adjacencies
for a given instance won't scale to large
numbers of VLANs.  I would probably be better
to just use the single instance and encode
the information in such a way that the receiver
can quickly determine what it needs to care
about.  

However, as you point out below, I think
it makes more sense to solve this problem using
learning at the edge RBridges.  But that doesn't
solve the problem for multicasts so those will
have to be advertised anyway, and they will
have to be sent to all Rbridges in the
network.

> some sort of layer 2 enrollment protocol.

If you absolutely had to have multiple IS-IS
instances, it might make sense to have some
number 'n' and then define a mapping of VLANs
to each instance.  Having 4K instances of IS-IS
running in an RBridge won't scale.

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 15 Jun 2007 15:40:36 -0400

You only have an instance of IS-IS for VLAN x in Rbridge y is Rbridge y
is advertising that it has directly connected end stations in VLAN x. Is
it plausible that an Rbridge would be reporting that it has directly
connected end stations in all of 4K VLANs?

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 15, 2007 2:15 PM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] per-VLAN instances of IS-IS

...

Anoop

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Fri, 15 Jun 2007 15:04:46 -0500

Anoop,

	There are two issues you're attempting to address in this 
mail.  One is the issue with advertising, and you have further 
broken that into unicast and multicast.  The other is with how
the RBridge link state protocols scale.

	On the first issue, you agree that having the default mode
for acquiring unicast MAC reachability be via learning, addresses
that portion of the scalability issue.  For multicast, you seem
to assume that multicast optimization is required - because the
only reason why acquiring multicast address reachability would
be needed is if you absolutely require multicast optimization 
(instead of treating multicast as broadcast - as is still allowed 
for a standard bridge).

	On the issue of link-state protocol scalability, do you have
any evidence to support your claims for non-scalability?  Does it
(your evidence) include a comparison of scalability of multiple
instances to scalability of similar single instance solution? 
Throwing the number of adjacencies around does not - in and of 
itself - prove much of anything.

Thanks!
--
Eric Gray
Principal Engineer
Ericsson

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Fri, 15 Jun 2007 15:10:09 -0500

Donald,

	This is the essence of why I asked the questions I asked Anoop.
In the real world, if you have a significant overlap in VLAN membership
at the edges, then you achieve similarly significant scaling advantages
by grouping VLANs and using Q-in-Q.  It is therefore very difficult to
imagine a realistic scenario in which you would actually have N-squared
order of adjacencies for even a large part of 4K VLANs.

	It is for this very reason that I would like to hear about real
world scenarios where the above reasoning does not apply...

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, June 15, 2007 3:41 PM
> To: Anoop Ghanwani
> Cc: rbridge at postel.org; Radia Perlman

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 15 Jun 2007 13:46:36 -0700

> [mailto:Donald.Eastlake at motorola.com] 
> Sent: Friday, June 15, 2007 12:41 PM
> To: Anoop Ghanwani

I understand that.  But it's not completely
out of the world to have 4K VLANs configured
in a "core" switch.  If you had RBridge 
network attached to one of these, you'd have
to be able to deal with the 4K instances.

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 15 Jun 2007 13:51:48 -0700

> Sent: Friday, June 15, 2007 1:05 PM
> To: Anoop Ghanwani
> 	There are two issues you're attempting to address in 
> this mail.  One is the issue with advertising, and you have 
> further broken that into unicast and multicast.  The other is 
> with how the RBridge link state protocols scale.
> 
> 	On the first issue, you agree that having the default 
> mode for acquiring unicast MAC reachability be via learning, 
> addresses that portion of the scalability issue.  For 
> multicast, you seem to assume that multicast optimization is 
> required - because the only reason why acquiring multicast 
> address reachability would be needed is if you absolutely 
> require multicast optimization (instead of treating multicast 
> as broadcast - as is still allowed for a standard bridge).

All I can say is - try selling a bridge that doesn't do 
IGMP snooping to someone that actually uses multicast.
That will address your concern on why the optimization
is absolutely essential.

> 	On the issue of link-state protocol scalability, do you 
> have any evidence to support your claims for non-scalability? 
>  Does it (your evidence) include a comparison of scalability 
> of multiple instances to scalability of similar single 
> instance solution? 
> Throwing the number of adjacencies around does not - in and 
> of itself - prove much of anything.

I don't know too many midrange routers that are
capable of supporting 4K adjacencies.  I do know
several midrange switches that are perfectly 
capable of supporting all 4K VLANs and mapping
them to MST instances.

Why don't you prove that it scales, instead of
having me prove otherwise?  :-)

Anoop

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Mon, 18 Jun 2007 08:35:27 -0500

Anoop,

	Please see below...

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Friday, June 15, 2007 4:52 PM
> To: Eric Gray (LO/EUS)

Here is where the problem arises.  With bridges, the ability to
do IGMP snooping can be a local optimization.  Hence it makes a
lot of sense to incorporate the capability (possibly as an add-
on feature) in deployments where it is useful.

But, the weakness in your argument is two pronged, when dealing
with TRILL: one is the argument that IGMP snooping will not work 
as a local optimization in TRILL (of which I am not convinced)
and the other is the phrase -

	"to someone [who] actually uses multicast"

- which would appear not to apply in at least some cases.

In fact, I believe it is the case that most networks use IP
multicast almost exclusively for routing protocols (for which
we have previously concluded IGMP snooping does not work).

But, you suppose that this "optimization" is required to be
supported ubiquitously in both senses - i.e. - for all RBridges 
in any deployment and for all deployments.  And yet it is clearly
not required in all cases.

Also, note the recent change in consensus to use learning from
the data path would definitely seem to apply to the multicast
case as well as to the unicast case.  From the fact that MAC
reachability advertisement is no longer the default for RBridge
routing protocol(s), it should be apparent that RBridges can 
implement IGMP snooping as a local optimization just as existing 
switces do.

What that means to me is that the protocol specification does not 
have to address this - in part because it is an optimization (and
- therefore - optional) and in part because it is implementable 
as a strictly local optimization in any specific implementation.

--
E

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Mon, 18 Jun 2007 08:59:01 -0500

Anoop,

	See additional response(s) below...

--
Eric Gray
Principal Engineer
Ericsson  

> having me prove otherwise?  :-)

You are the one who asserted that scale is an issue.

I have made the point that significant increases in
scalability is not a goal of the TRILL work.

I have made the point that - once you suppose that a
single physical LAN might have as many as 4K VLANs 
within it - this same scaling issue exists today for
any routing protocol.  Apparently, you did not quite
understand this point - but I made it none-the-less.

I also have made the (somewhat subtle) point that the
concept of "adjacencies" in soft-state protocols is
not quite the scalability issue that you think it is.

Thus, my argument is that your concerns are not a 
problem we need to solve.

In a rational discussion, it IS NOT necessary for a
person to prove that a problem does not need to be 
solved.  Otherwise, it would be possible to endlessly 
stall rational discussions with arbitrary "problems" 
and a supposed "necessity" to establish that none of 
them need to be solved.

In any rational discussion, it IS necessary to show
that there is a point in pursuing resolution of any
specific issue or problem.  Otherwise, it would be 
likely that any rational discussion would quickly 
become pointless.

Hence, it is necessary for you to prove that your
specific problem is in fact an issue that we need 
to address and it is not necessary for me to prove 
that it is not.

So far, you have simply asserted that there is an 
issue with scalability that we need to solve.

Prove it. 

--
E

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 18 Jun 2007 11:17:49 -0700

> Sent: Monday, June 18, 2007 6:35 AM
> To: Anoop Ghanwani
> Here is where the problem arises.  With bridges, the ability 
> to do IGMP snooping can be a local optimization.  Hence it 
> makes a lot of sense to incorporate the capability (possibly 
> as an add- on feature) in deployments where it is useful.
> 
> But, the weakness in your argument is two pronged, when 
> dealing with TRILL: one is the argument that IGMP snooping 
> will not work as a local optimization in TRILL (of which I am 
> not convinced) and the other is the phrase -
> 

I'd recommend looking at some of the IP multicast
applications that enterprises deploy.  It's not just
routing protocols.
 
> supported ubiquitously in both senses - i.e. - for all 
> RBridges in any deployment and for all deployments.  And yet 
> it is clearly not required in all cases.
> 
> Also, note the recent change in consensus to use learning 
> from the data path would definitely seem to apply to the 
> multicast case as well as to the unicast case.  
 
This is definitely a scalable option for unicast; no argument
there.  However it doesn't apply to multicast.

> From the fact 
> that MAC reachability advertisement is no longer the default 
> for RBridge routing protocol(s), it should be apparent that 
> RBridges can implement IGMP snooping as a local optimization 
> just as existing switces do.

Absolutely not!  Snooping requires that control and data
use exactly the same path in the network.  With rBridges
that is not true (especially when one introduces 
multipathing).

> What that means to me is that the protocol specification does 
> not have to address this - in part because it is an optimization (and
> - therefore - optional) and in part because it is 
> implementable as a strictly local optimization in any 
> specific implementation.

It depends on whether or not you care for people to
build and deploy the specification.

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 18 Jun 2007 11:36:25 -0700

> Sent: Monday, June 18, 2007 6:59 AM
> To: Anoop Ghanwani
> > I don't know too many midrange routers that are capable of 
> supporting 
> > 4K adjacencies.  I do know several midrange switches that are 
> > perfectly capable of supporting all 4K VLANs and mapping 
> them to MST 
> > instances.

> I also have made the (somewhat subtle) point that the concept 
> of "adjacencies" in soft-state protocols is not quite the 
> scalability issue that you think it is.

And I just don't get it.

> Thus, my argument is that your concerns are not a problem we 
> need to solve.
> 
> In a rational discussion, it IS NOT necessary for a person to 
> prove that a problem does not need to be solved.  Otherwise, 
> it would be possible to endlessly stall rational discussions 
> with arbitrary "problems" 
> and a supposed "necessity" to establish that none of them 
> need to be solved.
> 
> In any rational discussion, it IS necessary to show that 
> there is a point in pursuing resolution of any specific issue 
> or problem.  Otherwise, it would be likely that any rational 
> discussion would quickly become pointless.
> 
> Hence, it is necessary for you to prove that your specific 
> problem is in fact an issue that we need to address and it is 
> not necessary for me to prove that it is not.
> 
> So far, you have simply asserted that there is an issue with 
> scalability that we need to solve.
> 
> Prove it. 

I don't have much more to offer in terms of argument
other than what I already have.  So we'll just have
to disagree on this matter.

Anoop

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Mon, 18 Jun 2007 13:42:41 -0500

Anoop,

	I tend to view your response below as yet another reason
why RBridges MUST use a common path for unicast and multicast
(as well as broadcast and flooded) traffic.  In fact, it is a
very good reason to limit use of "multipathing" in general.

	It is not clear exactly what you mean by your reference to 
differences between control and data paths.  Control messages are 
from one RBridge to another and - presumably - follow the same 
path as data addressed from RBridge to RBridge.  That path may be 
different from data transitting an RBridge campus, but there is 
no RBridge "control" traffic that transits a campus.

	Are you suggesting that IGMP should be treated as a control
protocol within TRILL?

	Nor is it very clear why this observation is specific to 
our discussion of multicast optimization.  As a general rule, if 
there is one reasonably well know application that relies on path 
congruency for proper operation, there are probably others.  

	Do you think we should provide a logical control-function 
"bridging" service for all such applications as a result of path 
divergences we introduce?  Should we conduct a research project
to determine what other "control protocols" we need to include in
TRILL?

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Monday, June 18, 2007 2:18 PM
> To: Eric Gray (LO/EUS)

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 18 Jun 2007 16:07:41 -0700

> Sent: Monday, June 18, 2007 11:43 AM
> To: Anoop Ghanwani
> 	I tend to view your response below as yet another 
> reason why RBridges MUST use a common path for unicast and 
> multicast (as well as broadcast and flooded) traffic.  In 
> fact, it is a very good reason to limit use of "multipathing" 
> in general.

If we do place those constraints then it would
cripple the technology and make it very uninteresting
(at least to me).

> 	It is not clear exactly what you mean by your reference 
> to differences between control and data paths.  Control 
> messages are from one RBridge to another and - presumably - 
> follow the same path as data addressed from RBridge to 
> RBridge.  That path may be different from data transitting an 
> RBridge campus, but there is no RBridge "control" traffic 
> that transits a campus.
>
> 	Are you suggesting that IGMP should be treated as a 
> control protocol within TRILL?

In this case, when I said control I meant IGMP (since
that is what is being used to effect pruning).  If we
snoop on the information at the edge of the trill
cloud and pass this information around in IS-IS, then we don't
need to worry about treating it as a separate control
protocol.

> 
> 	Nor is it very clear why this observation is specific 
> to our discussion of multicast optimization.  As a general 
> rule, if there is one reasonably well know application that 
> relies on path congruency for proper operation, there are 
> probably others.  
>
> 	Do you think we should provide a logical 
> control-function "bridging" service for all such applications 
> as a result of path divergences we introduce?  Should we 
> conduct a research project to determine what other "control 
> protocols" we need to include in TRILL?

We would need to make a list of everything that bridges
snoop on and make sure we have ways of sending that
around in IS-IS (if we care about those functions).
I'm not aware of anything other than IGMP that trill
would need to worry about, though.

Anoop

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Tue, 19 Jun 2007 07:27:25 -0500

Anoop,

	I think we strongly disagree on what it means to incorporate
something in the control protocol.  From there, it is likely that
we also disagree on how best to avoid doing so.

	Figuring out how to correctly carry IGMP-snooped information 
in TRILL protocol is effectively the same thing as incorporating 
IGMP in the control protocol.

	Making a list of everything that bridges snoop and ensuring
we can also include that information in IS-IS is exactly the sort 
of thing we should be trying to avoid.  The good news is that it 
also should be easy to avoid.

	Whatever protocols we might use, TRILL is essentially a layer
two forwarding technology.  The messages that layer two forwarding
technologies want to snoop are visible to the devices involved in
forwarding.  Unless devices actively interfere with "normal" layer 
two forwarding, "external" control messages should be no different 
than any other form of data - as far as RBridges are concerned - 
and should be forwarded in the same way.

	We know that we're expected to preserve forwarding symmetry
- at least for the layer two encapsulation of TRILL frames. In the 
same way, and for similar reasons, we may need to preserve path 
congruency.  This is implicit in the decision to learn from data 
in the unicast case.

	What we don't know is the complete list of things that depend
on our doing that.  But we can compose a partial list, and it seems
to me that "snooping" (in general) is one example, OA&M may well be 
another and there are bound to be more.

	As for the notion of "crippling the technology and making it 
very uninteresting" - well, to many people, technology becomes very
interesting when it is very complicated to make it work.  For the
users of any technology, it is only truly useful when it is not very
interesting.  

	Paraphrasing something a colleague once told me: a technology
is only really useful when the interesting thing in using it is not 
about the technology, but about its use.  Put another way, you know 
that transportation is useful when the interesting thing about using
it is arriving at the destination - rather than the trip itself.

	Uninteresting is good.  Very uninteresting is very good.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Monday, June 18, 2007 7:08 PM
> To: Eric Gray (LO/EUS)

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 19 Jun 2007 06:01:57 -0700

> Sent: Monday, June 18, 2007 4:08 PM
> To: Eric Gray (LO/EUS)

I AM IN VIOLENT AGREEMENT with Anoop on this point.

-- Silvano

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 19 Jun 2007 06:12:37 -0700

Eric,

You say: "we're expected to preserve forwarding symmetry".

WE ARE NOT.

Where does the current draft preserve forwarding symmetry?

In regard to your conclusions, many of us (Anoop , Dinesh and I for
sure) are participating because we are building real products. 

I don't buy your argument that "Very uninteresting (technology) is very
good."

-- Silvano

> Behalf Of Eric Gray (LO/EUS)
> Sent: Tuesday, June 19, 2007 5:27 AM
> To: Anoop Ghanwani

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Tue, 19 Jun 2007 09:13:34 -0500

Silvano,

	Your response is confusing.  If we are not expected to 
preserve forwarding symmetry, have we given up on presumed 
compatibility with standard bridges?

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, June 19, 2007 9:13 AM
> To: Eric Gray (LO/EUS); Anoop Ghanwani

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Tue, 19 Jun 2007 09:25:09 -0500

Silvano,

	Many people are building real products, so you needn't feel
that the fact that you are makes you somehow different from every
one else.

	As another 802 kind of guy said once, any time you deal with
customers, they want (at least) the following in your products:

o	A rich feature set
o	A low price
o	An early delivery date

Realistically, these factors push and pull each other.  In particular,
features work against both low price and early delivery.

	Apparently the customers for who you are building real products
are more interested in the first factor than they are in the others.

	That is not true for all customers.

--
Eric Gray
Principal Engineer
Ericsson

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 19 Jun 2007 10:49:40 -0400

What does "compatibility" mean?

I believe forwarding symmetry has to do with address learning at transit
bridges. But, with Rbridges, transit bridges don't learn the actual
source and destination of the data once it has been protected by a TRILL
Header. So forwarding symmetry is no longer of any significance.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Eric Gray (LO/EUS)
Sent: Tuesday, June 19, 2007 10:14 AM
To: Silvano Gai; Anoop Ghanwani
Cc: rbridge at postel.org; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

Silvano,

--
Eric Gray
Principal Engineer
Ericsson

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Tue, 19 Jun 2007 10:12:18 -0500

Donald,

	If you look at the entire statement (from which Silvano
excerpted a partial quote), it says:

"We know that we're expected to preserve forwarding symmetry
 - at least for the layer two encapsulation of TRILL frames."

This is necessary for "compatibility" with intermediate LAN
bridges.  This refers to the L2 encapsulation that "protects"
the TRILL header (which - as you say - protects the SA/DA of
the internal frames).

	I did not suppose that Silvano was being disingenuous 
in his partial quote, but - based on your comment - perhaps 
I should have re-inserted the actual context anyway.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, June 19, 2007 10:50 AM
> To: Eric Gray (LO/EUS)
> [mailto:rbridge-bounces at postel.org] On
> [mailto:rbridge-bounces at postel.org]
> > On

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 19 Jun 2007 11:21:53 -0700

Eric,

It depends on what we mean by compatibility.
One can always say that if one cares about
such and such compatibility then here's a way
to solve it.  

Even if trill were to impose the constraint 
you suggest, many things will break.  For
example, if I have a topology with a bridged
cloud between 2 trill devices, then the 
traffic going between the trill devices will
not be "snoopable" by the bridges because they
won't understand trill encapsulation.
Additionally, in the above scenario something
like MMRP would break because the ingress rBridge
would terminate the MMRP message and the
bridge cloud would never see them (that's only
logical since rBridges terminate spanning trees
and MMRP runs in the context of a spanning tree).

So rBridges aren't as transparent as we'd 
like them to be.

We have to decide what problem we are trying 
to solve and then find creative ways to work
around those issues, possibly constraining
the deployment, but without cripping the 
technology.

Anoop

> Sent: Tuesday, June 19, 2007 7:14 AM

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 19 Jun 2007 11:42:12 -0700

Eric,

What makes a technology interesting to me is
whether or not it is capable of satisfying the
needs of our customer.  If trill doesn't solve
that problem, it becomes uninteresting to me 
and I will have to find another way to solve it.

Anoop

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 19 Jun 2007 12:16:25 -0700

rbridge-bounces at postel.org wrote:
> One can always say that if one cares about such and such
> compatibility then here's a way to solve it.
> 
> Even if trill were to impose the constraint you suggest, many
> things will break.  For example, if I have a topology with a
> bridged cloud between 2 trill devices, then the traffic going
> between the trill devices will not be "snoopable" by the
> bridges because they won't understand trill encapsulation.
> 

Why are these intermediate bridges snooping?

The only service being requested of them is to relay Ethernet
frames from the ingress rbridge to the egress rbridge. Is that
not implied by their being a cloud *between* 2 trill devices?

How is this different from any tunnel? You have traffic that
a middlebox might have optimized had it been untunelled, but
that it does not see when tunneled. It cannot provide its service,
but it is not being asked to do so.

A non-rbridge bridge forwards packets without understanding that
they are rbridge encapsulated frames. I always thought that this
was a strength of the proposal, not a weakness. You can't be
snoopable and opaque. Opaque is better.

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 19 Jun 2007 15:51:08 -0400

In addition to what Caitlin says, I would point out that, if there are
multicast listeners or IP multicast routers in this bridged LAN (which
looks to the Rbridges pretty much like a single multi-access link), then
the Rbridges should have heard about them and the Designated Rbridge for
the VLAN in question for that cloud will also decapsulate appropriate
data/multicast-control and send it into the cloud as native (non-TRILL)
frames whose distribution within the cloud the bridges are welcome to
try to optimize as much as they like.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Caitlin Bestler
Sent: Tuesday, June 19, 2007 3:16 PM
To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
Cc: rbridge at postel.org; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 19 Jun 2007 13:31:13 -0700

> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
> Sent: Tuesday, June 19, 2007 12:16 PM

They're snooping because they too care about
pruning their trees for a given multicast group
and that would be one of the ways to achieve it.
Otherwise, all multicasts would have to be 
broadcast on the spanning tree interconnecting
the bridged network that sits between the two
rBridges.

> not implied by their being a cloud *between* 2 trill devices?

If we didn't care about multicast pruning,
we wouldn't need to worry about any of this.

> but it is not being asked to do so.

Most tunnels are point to point and that makes
life easy.  It's when you have multicast that
things start to get a bit tricky.

> snoopable and opaque. Opaque is better.

Opaque is best if you're not depending on
the inner stuff to tell you where to go.  The
current rbridge spec looks all over the inner
L2 header to figure out where to send the frame.
I wouldn't exactly call that opaque.

At that point, you have to use what the
same (or similar) controls to those used
by devices that forward using that header
(in this case bridges).

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 19 Jun 2007 17:05:01 -0400

Hi Eric,

Well, I read some of the earlier messages in this email thread and I'm
not sure if I'm more or less confused than I was.

I now assume that what you are talking about is bridge learning of MAC
addresses inside a bridged LAN that's between two or more Rbridges. If
my guess is right, then I don't see why it makes any difference whether
TRILL data frames do or do not pass through in such a
symmetric/congruent/whatever way that the learning you would want
happens. The periodic TRILL IS-IS Hellos will cause the learning you
need inside the bridged LAN for transit traffic between Rbridges.

If I'm wrong, perhaps you could be more explicit about what you are
saying and what you mean by "forwarding symmetry" and "congruent paths".

Donald

(some of thread below but earliest parts deleted)

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
Sent: Tuesday, June 19, 2007 11:12 AM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

--
Eric Gray
Principal Engineer
Ericsson

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 19 Jun 2007 14:05:16 -0700

...
> applications that enterprises deploy.  It's not just

IPv6 uses multicast for neighbor discovery too.

And, as Eric notes later, a common path between the two is needed at L2.

As to the pruning that Anoop later notes, I don't consider pruning an
issue for an L2 system. Although I appreciate pruning as an
optimization, I don't consider it a design requirement. If it were, we
would be talking about scalability beyond existing bridge capabilities,
which has been off the table from the start.

Joe

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070619/554dd7fb/signature.bin

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 19 Jun 2007 16:32:29 -0700

Donald,

What if there are no IP multicast routers or
listeners in the bridged LAN between the
rBridges?  Does that mean a copy of the trill
frame gets delivered to every station in that
LAN?

Anoop 

> Sent: Tuesday, June 19, 2007 12:51 PM
> To: Anoop Ghanwani
> Cc: rbridge at postel.org; Caitlin Bestler

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 19 Jun 2007 16:40:49 -0700

Joe,

> And, as Eric notes later, a common path between the two is 

Sorry, this thread is starting to get long and 
I'm losing context.  A common path between what two?
Control and data?  As I pointed out the control
packets (e.g. if MMRP were being used) do not
even make it into the LAN between the rbridges.
The rbridges would have to initiate such messages
and I don't know what would cause them to intiate
such messages.
 
> which has been off the table from the start.

Well, existing bridges do actually do
pruning today - and they have for years.
rBridges without multicast pruning would be
step (or perhaps two) back.

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 19 Jun 2007 22:15:52 -0400

Hi Anoop,

No, it shouldn't get delivered to every end station unless it is
broadcast or a layer 2 multicast not derived from an IP address.

If it is an layer 2 multicast address derived from an IP address, then
Rbridges should prune the distribution tree and the links they
decapsulate and forward onto to those with listeners for an IP multicast
address that corresponds to that layer 2 multicast address or with an IP
multicast router.

Donald

PS: All the above is scoped by VLAN as well.

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Tuesday, June 19, 2007 7:32 PM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org; Caitlin Bestler
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

Anoop

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 19 Jun 2007 20:37:08 -0700

> and I don't know what would cause them to intiate

I was presuming a common path for multicast at L3 and unicast at L3,
e.g., IPv6 neighbor discovery and unicast replies.

> step (or perhaps two) back.

There are bridges built into a variety of devices that are a lot simpler
than the typical COTS stand-alone device. Further, the extent to which
rbridges even benefit from pruning is different than regular bridges,
because there can be multiple paths for different traffic in rbridges.
I.e., this is still just an optimization, and one that may be less
important in this environment.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070619/86dd80d2/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 19 Jun 2007 20:38:58 -0700

We had this discussion on May 8th, 2007 on this mailing list.

In a nutshell: we do ECMP only in the core, but we don't learn in the
core, so I don't see the problem.

-- Silvano

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 20 Jun 2007 09:29:06 -0500

Silvano,

	Yes, that was probably discussed earlier in May.

	AFAIK, discussion != consensus.

	Possibly your customers need to explain to you that the
difference between "core" and "not core" is not always as clear 
cut as you apparently think it is.  Nor is it necessarily going
to be simple for a device to determine which of the available
equal cost paths only contain core elements.

	Also, ECMP - at least in the traditional sense - takes
place where equal costs exist in a "routing" domain.  That is
at least as likely to occur in locii containing one or more
edge components, as it is anywhere else.

	There are certainly limited applications - typically 
requiring careful configuration to restrict ECMP-like activity
to very specifically defined equal cost paths - where it will
be possible to say "we do ECMP only in the core."  I personally
wonder why link-bundling wouldn't be a better solution in those
cases, however.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, June 19, 2007 11:39 PM

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 20 Jun 2007 11:42:49 -0700

Personally, I would like the group to get to a
consensus on the ECMP issue fairly quickly.

I too, just like Silvano, thought it was going
to be done.

Anoop 

> Sent: Wednesday, June 20, 2007 7:29 AM
> difference between "core" and "not core" is not always as 
> clear cut as you apparently think it is.  Nor is it 
> necessarily going to be simple for a device to determine 
> which of the available equal cost paths only contain core elements.
> 
> requiring careful configuration to restrict ECMP-like 
> activity to very specifically defined equal cost paths - 
> where it will be possible to say "we do ECMP only in the 
> core."  I personally wonder why link-bundling wouldn't be a 
> better solution in those cases, however.
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > > 	Your response is confusing.  If we are not expected to preserve 
> > > forwarding symmetry, have we given up on presumed 
> compatibility with 
> > > standard bridges?
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > > to me that "snooping" (in general) is one example, 
> OA&M may well
> > be
> > > > > users of any technology, it is only truly useful when 
> it is not
> > very
> > > > > interesting.
> > > > >
> > > > > is only really useful when the interesting thing in 
> using it is
> > not
> > > > > > > why RBridges MUST use a common path for unicast and 
> > > > > > If we do place those constraints then it would cripple the 
> > > > > > technology and make it very uninteresting (at least to me).
> > > > > >
> > > > > > > differences between control and data paths.  Control 
> > > > > > In this case, when I said control I meant IGMP 
> (since that is 
> > > > > > what is being used to effect pruning).  If we snoop on the 
> > > > > > information at the edge of the trill cloud and pass this 
> > > > > > information around in IS-IS, then we don't need to 
> worry about 
> > > > > > treating it as a separate control protocol.
> > > > > >
> > > > > > >
> > > > > > > our discussion of multicast optimization.  As a general 
> control-function 
> > > > > > > "bridging" service for all such
> > applications
> > > > > > We would need to make a list of everything that 
> bridges snoop 
> > > > > > on and make sure we have ways of sending that 
> around in IS-IS 
> > > > > > I'm not aware of anything other than IGMP that trill would 
> > > > > > need to worry about, though.
> > > > > >
> > > > > > Anoop
> > > > > >
> > > > >

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 20 Jun 2007 11:52:35 -0700

Donald,

So then the bridges in the LAN between the
2 rbridges need some information to do their
pruning.   Where do they get it from?

Anoop 

> Sent: Tuesday, June 19, 2007 7:16 PM
> To: Anoop Ghanwani

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 20 Jun 2007 12:06:10 -0700

> From: Joe Touch [mailto:touch at ISI.EDU] 
> Sent: Tuesday, June 19, 2007 8:37 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); rbridge at postel.org; Radia Perlman

Why does this matter?

Somewhat unrelated to this discussion:
>From an L2 network standpoint, IPv6 ND
multicasts have to be treated similar to broadcasts
because there is no information that can tell how
to filter the frame as it propagates on the 
spanning tree (unless you have something like
MMRP enabled and the host does MMRP).

> important in this environment.

I disagree with respect to the importance of
multicast pruning in these networks.  But for a
moment let's say I agree with you and multicast
pruning becomes a non-goal.  Then there is no
function for which we need a per-VLAN instance
of IS-IS.

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 20 Jun 2007 15:11:01 -0400

Hi Anoop,

>From two places. They should see native IGMP/MLD/PIM/MRD from end
stations that are directly attached to them. And, to the extent that
they let any surrounding Rbridges see any PIM/MRD messages, the
Designated Rbridge will send IGMP/MLDs in native form into the bridged
LAN. I should think this would give the bridges enough information to
figure out how to do an optimized forwarding of IP derived multicast
address traffic.

Donald 

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Wednesday, June 20, 2007 2:53 PM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 20 Jun 2007 12:13:49 -0700

And we now go full circle back to...

What if we a bridged LAN between 2 rbridges
and there were no stations on this bridged LAN
(other than the rbridges) that were interested
in receiving that multicast?  You wouldn't
see any of the control packet that you mention.
The only control packets of that type would be
the ones which were going between the rBridges and
those would be trill encap'ed.  So the regular
bridges between these rbridges wouldn't 
understand them (for snooping).

Anoop 

> Sent: Wednesday, June 20, 2007 12:11 PM
> To: Anoop Ghanwani
> From two places. They should see native IGMP/MLD/PIM/MRD from 
> end stations that are directly attached to them. And, to the 
> extent that they let any surrounding Rbridges see any PIM/MRD 
> messages, the Designated Rbridge will send IGMP/MLDs in 
> native form into the bridged LAN. I should think this would 
> give the bridges enough information to figure out how to do 
> an optimized forwarding of IP derived multicast address traffic.
> 
> Donald 
> 
> > decapsulate and forward onto to those with listeners for an IP 
> > multicast address that corresponds to that layer 2 
> multicast address 
> > or with an IP multicast router.
> > 
> > Donald
> > 
> > What if there are no IP multicast routers or listeners in 
> the bridged 
> > LAN between the rBridges?  Does that mean a copy of the trill frame 
> > gets delivered to every station in that LAN?
> > 
> > Anoop
> > 
> > > looks to the Rbridges pretty much like a single 
> multi-access link), 
> > > then the Rbridges should have heard about them and the Designated 
> > > Rbridge for the VLAN in question for that cloud will also 
> > > decapsulate
> > appropriate
> > > [mailto:rbridge-bounces at postel.org] On Behalf Of Caitlin Bestler
> > > > between the trill devices will not be "snoopable" by 
> the bridges 
> > > > because they won't understand trill encapsulation.
> > > > 
> > > 
> > > The only service being requested of them is to relay 
> Ethernet frames 
> > > from the ingress rbridge to the egress rbridge. Is that 
> not implied 
> > > by their being a cloud *between* 2 trill devices?
> > > 
> > > How is this different from any tunnel? You have traffic that a 
> > > middlebox might have optimized had it been untunelled, 
> but that it 
> > > does not see when tunneled. It cannot provide its 
> service, but it is 
> > > not being asked to do so.
> > > 
> > > they are rbridge encapsulated frames. I always thought 
> that this was 
> > > a strength of the proposal, not a weakness. You can't be 
> snoopable

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 20 Jun 2007 15:22:58 -0400

Hi Anoop,

It seems to me that what you are saying is that the strategy in TRILL of
only sending IGMP/MLD to links that appear to have IP multicast routers
on them due to the detection of PIM/MRD messages doesn't work. That, at
least occasionally, IGMP/MLD have to be flooded to every link just in
case there might be an IP multicast router on it that has been silent.

If that's a problem, it has nothing to do with bridges or bridged LANs.
All it takes to demonstrate the problem is a silent IP multicast router
point-to-point connected to an Rbridge somewhere. If that IP multicast
router has never send an PIM or MRD message, then the Rbridge has no way
of knowing to send it IGMPs or MLDs (or multicast data traffic)...

Donald 

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Wednesday, June 20, 2007 3:14 PM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 20 Jun 2007 15:37:15 -0400

Anoop,

What exactly do you think we need to do and to get consensus on?

I think it is clear enough from the draft that an ingress Rbridge can
multipath multidestination traffic by selecting different tree roots for
different frames. So the only question is unicast. Other than a few
words saying that don't have to always send unicast traffic on the one
path selected by the tie breaker rule, but MAY multipath, what more is
needed?

Presumably the tricky thing is how best to determine flows, where frames
in a flow would follow only one of the multiple paths, except during
transients. I don't think the TRILL WG should get into defining flows...

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 20, 2007 2:43 PM
To: Eric Gray (LO/EUS); Silvano Gai
Cc: rbridge at postel.org; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

Anoop

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 20 Jun 2007 14:48:24 -0500

Anoop,

	I don't understand why you suppose that the control packets 
would not be seen.  With the usual VLAN scoping caveat, broadcast 
control frames would be seen by every station (within the VLAN).

	It sounds to me like you're assuming that - along with the
other control activities associated with IGMP that you would like
TRILL to take on - you're also assuming that control frames are
being inapproriately filtered...

--
Eric Gray
Principal Engineer
Ericsson

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 20 Jun 2007 12:56:32 -0700

As Anoop said, core RBridges need to look inside the tunneled
packet at the inner packet in order to do multicast pruning
as well as VLAN pruning on multicast packets.

Which is why Don was proposing moving both the VLAN tag and the
destination multicast address to the TRILL header. (and removing the 
VLAN tag
and DA from the
inner packet so that it wouldn't mean adding an extra 6 bytes to an 
encapsulated frame).

Seemed like people didn't like doing that, but I want to make sure if 
the WG really
is deciding not to do that, that they really understand what they are 
deciding against.
Often in the email threads so many different things are kind of 
discussed at the same time
that it's obvious that people (definitely including me) are getting 
confused.

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 20 Jun 2007 12:59:56 -0700

I'm also assuming we are doing multipathing, not just of unicast, but 
also multicast.

Radia

Anoop Ghanwani wrote:
>>> In a nutshell: we do ECMP only in the core, but we don't 
>>>       
>> learn in the 
>>     
>> compatibility with 
>>>> standard bridges?
>>>>> In regard to your conclusions, many of us (Anoop , Dinesh
>>>>>           
>>> and I for
>>>       
>>>>>> 	I think we strongly disagree on what it means
>>>>>>             
>>> to incorporate
>>>       
>>>>>> something in the control protocol.  From there, it is
>>>>>>             
>>> likely that
>>>       
>>>>>> 	Figuring out how to correctly carry
>>>>>>             
>>> IGMP-snooped information
>>>       
>>>>>> in TRILL protocol is effectively the same thing as 
>>>>>>             
>> incorporating 
>>     
>>>>>> 	Making a list of everything that bridges snoop
>>>>>>             
>>> and ensuring
>>>       
>>>>>> we can also include that information in IS-IS is
>>>>>>             
>>> exactly the sort
>>>       
>>>>>> of thing we should be trying to avoid.  The good news 
>>>>>>             
>> is that it 
>>     
>>>>>> 	Whatever protocols we might use, TRILL is
>>>>>>             
>>> essentially a layer
>>>       
>>>>>> two forwarding technology.  The messages that layer two
>>>>>>             
>>> forwarding
>>>       
>>>>>> technologies want to snoop are visible to the devices
>>>>>>             
>>> involved in
>>>       
>>>>>> forwarding.  Unless devices actively interfere with
>>>>>>             
>>> "normal" layer
>>>       
>>>>>> two forwarding, "external" control messages should be
>>>>>>             
>>> no different
>>>       
>>>>>> than any other form of data - as far as RBridges are 
>>>>>>             
>> concerned - 
>>     
>>>>>> 	We know that we're expected to preserve
>>>>>>             
>>> forwarding symmetry
>>>       
>>>>>> - at least for the layer two encapsulation of TRILL
>>>>>>             
>>> frames. In the
>>>       
>>>>>> same way, and for similar reasons, we may need to 
>>>>>>             
>> preserve path 
>>     
>>>>>> congruency.  This is implicit in the decision to 
>>>>>>             
>> learn from data 
>>     
>>>>>> in the unicast case.
>>>>>>
>>>>>> 	What we don't know is the complete list of
>>>>>>             
>>> things that depend
>>>       
>>>>>> on our doing that.  But we can compose a partial list, and it
>>>>>>             
>>> seems
>>>       
>>>>>> 	As for the notion of "crippling the technology
>>>>>>             
>>> and making it
>>>       
>>>>>> very uninteresting" - well, to many people, technology becomes
>>>>>>             
>>> very
>>>       
>>>>>> interesting when it is very complicated to make it
>>>>>>             
>>> work.  For the
>>>       
>>>>>> 	Paraphrasing something a colleague once told
>>>>>>             
>>> me: a technology
>>>       
>>>>>> about the technology, but about its use.  Put another way, you
>>>>>>             
>>> know
>>>       
>>>>>> that transportation is useful when the interesting thing about
>>>>>>             
>>> using
>>>       
>>>>>> it is arriving at the destination - rather than the 
>>>>>>             
>> trip itself.
>>     
>>>>>>>> 	I tend to view your response below as yet 
>>>>>>>>                 
>> another reason 
>>     
>>>>>>>> fact, it is a very good reason to limit use of
>>>>>>>>                 
>>> "multipathing"
>>>       
>>>>>>>> in general.
>>>>>>>>                 
>>>>>>>> 	It is not clear exactly what you mean by your 
>>>>>>>>                 
>> reference to 
>>     
>>>>>>>> messages are from one RBridge to another and - 
>>>>>>>>                 
>> presumably - 
>>     
>>>>>>>> RBridge.  That path may be different from data
>>>>>>>>                 
>>> transitting an
>>>       
>>>>>>>> 	Are you suggesting that IGMP should be treated 
>>>>>>>>                 
>> as a control 
>>     
>>>>>>>> protocol within TRILL?
>>>>>>>>                 
>>>>>>>> 	Nor is it very clear why this observation is 
>>>>>>>>                 
>> specific to 
>>     
>>>>>>>> rule, if there is one reasonably well know 
>>>>>>>>                 
>> application that 
>>     
>>>>>>>> conduct a research project to determine what 
>>>>>>>>                 
>> other "control 
>>     
>> around in IS-IS 
>>>>>>> (if we care about those functions).

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 20 Jun 2007 15:21:44 -0500

Radia, et al,

	I was not challenging consensus on multi-pathing, for either
unicast or multicast.  What I was objecting to was the assertion
that we ONLY do ECMP in "core" RBridges - which Silvano had stated
as if a WG decision.  Since I seriously doubt that we could ever
arrive at a consensus as to exactly what sort of real-world device
would be a "core" RBridge, I don't think we have concluded that we
ONLY do <anything you choose to talk about> in such a beasty.

	See Silvano's original comments toward the very end of this
(snipped) message.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, June 20, 2007 4:00 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); Silvano Gai; rbridge at postel.org
--- SNIP ---

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 20 Jun 2007 13:33:19 -0700

We need to convince Eric that we have
consensus.  He doesn't seem to think so.

Anoop

> Sent: Wednesday, June 20, 2007 12:37 PM
> To: Anoop Ghanwani
> cripple the

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 20 Jun 2007 15:46:26 -0500

Anoop,

	Apparently, our mail crossed.  I had already replied on this 
comment prior to receiving your mail.

	To repeat, what I felt we had no consensus on was the notion
that ECMP only occurs in "core" RBridges.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, June 20, 2007 4:33 PM

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 20 Jun 2007 14:54:53 -0700

This thread was started because of the assertion
that the current rbridge proposal is "opaque" and
is completely compatible with bridges.

I pointed out that it breaks snooping once the
frames are trill encap'ed and this snooping is
required if you have 2 rbridges interconnected
by a regular LAN that doesn't have any end nodes
that are interested in seeing that multicast.

To which Donald responded saying that the DRB
for the bridged LAN would be sending a decap'ed
version of the control packets to the LAN 
anyway, and so snooping would continue to work.

I still don't think it works.  Consider
the following network.

  Multicast router
   |
   Rb1 (DRB for the LAN)
   |
 bridged LAN with 10 bridges and hosts
 in some random configuration
   |
   Rb2
   |
   B

In the above example, B is the only
participant in a multicast.  No one
on the intermediate LAN is interested
in receiving the multicast.

When B sends a join, it gets trill encap'ed
by Rb2 and forwarded to Rb1.  The bridges
in the LAN can't snoop that because they
don't understand the trill etype.

When multicast data are forwarded from Rb1
to Rb2 it is encap'ed as trill and sent
to the all-rbridges address.  The bridges
on the LAN (all 10 of them) will see this
frame and copy it to all stations on that
LAN.

That the bridges on the LAN see a 
decap'ed version of the Join doesn't
mean anything, because the multicast
traffic between the routers goes has the
all-rbridges address as the MAC DA.
In this way, we have broken "compatibility"
with bridges.

With something like MMRP (a native 802.1
protocol), things are even worse.  Rb1 
would terminate any MMRPDUs (just as
it would STP BPDUs).

We cannot says we are backwards compatible
with bridges just because we restrict traffic 
flow to a single symmetric tree within the trill 
network.  We are breaking compatibility in
other ways.  We need to be explicit about 
what compatibility we are trying to preserve.

Anoop

> Sent: Wednesday, June 20, 2007 12:23 PM
> To: Anoop Ghanwani
> It seems to me that what you are saying is that the strategy 
> in TRILL of only sending IGMP/MLD to links that appear to 
> have IP multicast routers on them due to the detection of 
> PIM/MRD messages doesn't work. That, at least occasionally, 
> IGMP/MLD have to be flooded to every link just in case there 
> might be an IP multicast router on it that has been silent.
> 
> All it takes to demonstrate the problem is a silent IP 
> multicast router point-to-point connected to an Rbridge 
> somewhere. If that IP multicast router has never send an PIM 
> or MRD message, then the Rbridge has no way of knowing to 
> send it IGMPs or MLDs (or multicast data traffic)...
> 
> Donald 
>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 20 Jun 2007 23:53:15 -0400

Hi Anoop,

See below at @@@ 

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Wednesday, June 20, 2007 5:55 PM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] per-VLAN instances of IS-IS

@@@ Of course, that depends on what "completely compatible" means. The
protocol specification just says "compatible", not "completely
compatible" :-)

@@@ You may have found a problem, but I really don't think it is the
problem you believe it is, as I will try to explain below. Furthermore,
I can't see why the bridges in the bridged LAN need to snoop if there
are no multicast listeners or IP multicast routers inside the bridged
LAN.

@@@ Well, I was trying to say something more like the DRB would send in
any traffic that nodes inside the bridged LAN had indicated any interest
in.

  Multicast router
   |
   Rb1 (DRB for the LAN)
   |

@@@ Right, stuff with a TRILL Header is opaque to boxes which don't
understand how to parse it. So boxes that are not Rbridges, including
the bridges on this bridged LAN, will be in the dark.

@@@ That is correct with the current protocol spec. But I would point
out that at the expense of slightly more complex conditionals, the
protocol could notice that there is only one IS-IS adjacency on that
link out of RB1 and unicast the TRILL data frames even if the
encapsulated frame had a multicast destination. (Of course, it would
want to keep multicasting the TRILL IS-IS frames in case another Rbridge
shows up.) There is nothing peculiar about a unicast TRILL data frame.
If there is unicast data being forwarded from RB1 to RB2, it would be
unicast. But I am digressing.

@@@ Just above is where you lose me. The TRILL encapsulated data has
nothing to do with the  problem... If any listener inside the bridge LAN
had spoken up, the native form of the multicast data would be getting
forwarded into the bridged LAN also...

@@@ It seems to me there are four possibilities for what is in the
bridged LAN between RB1 and RB2: (1) There are no IP multicast routers
or multicast listeners; (2) There are one or more listeners but no IP
multicast router; (3) there is an IP multicast router but no listeners;
and (4) there is both an IP multicast router and one or more listeners.

@@@ In case 1, we are obviously fine. B joins the group, the IP
multicast router at the top send multicast to B, everything is fine and
it doesn't matter that stuff is encapsulated because there is no reason
for any box in the bridged LAN to care.

@@@ In case 2, we have a listener inside the bridged LAN. It will send
an IGMP (I'll ignore IPv6 for this discussion for simplicity.) Either
RB1 or RB2 will be the Designated Rbridge (DRB) for the bridged LAN
(which looks to the Rbridges like a multi-access link). Whichever is the
DRB receives and processes the frame. It will then forward it in native
form on any local links that seem to have an IP multicast router on them
and for which it is DRB. So if RB1 is the DRB for the bridged LAN and
the DRB for the link at the top with the IP multicast router (which it
would obviously be if it was the only Rbridge on that link), it would
forward it in native form to that IP multicast router. The DRB receiving
the original native IGMP will also encapsulate this IGMP and forward it
over a distribution tree to all other Rbridges that advertise they are
DRB for some local link with an IP multicast router on that link. And
those Rbridges will decapsulate it and deliver it to those IP multicast
routers on those link.
@@@ For example, if RB2 is the DRB for the bridged LAN, it would receive
the native IGMP from the listener inside the bridged LAN, encapsulate
it, and send it to RB1 which would decapsulate it and deliver it to the
IP multicast router at the top.
@@@ In any case, we have a listener inside the bridged LAN; its IGMP
gets to all IP multicast routers as described above. Furthermore, the
Rbridge that is DRB for the bridged LAN also remembers and advertises
that it saw this IGMP and there is a Listener inside the bridge LAN so
it will get and decapsulate appropriate multicast data and send it in
native form into the bridge LAN.
@@@ In other words, everything works fine in this case.

@@@ OK, on to case 3. There is an IP multicast router inside the bridged
LAN but no Listeners. If this IP multicast router ever sends a PIM or
MRD, it will be noticed by the DRB for the bridged LAN which will
remember this and advertise in the link state that it has an IP
multicast router attached. This advertisement will cause it to start
receiving all IGMPs and multicast data, if it wasn't already receiving
that traffic, and it will decapsulate that traffic and send it into the
bridged LAN.
@@@ The possible problem is if the IP multicast router inside the
bridged LAN is silent. Then the DRB doesn't know to hook things up and
start decapsulating the relevant frames and sending them into the
bridged LAN.

@@@ It doesn't seem worth going through case 4, which is kind of a
combination of cases 2 and 3.

@@@ All right, now that I have gone through all that, consider the
following:

@@@   Multicast router
@@@   |
@@@   Rb1 (DRB for the LAN)
@@@   |
@@@   RB3---X
@@@   |
@@@   Rb2
@@@   |
@@@   B

@@@ Now consider what if X is, possibly, a multicast listener for the
group in question or an IP multicast router, or neither, or both.
Exactly the same questions occur as to whether or not RB3, assuming it
is the only Rbridge on the link to X and thus DRB, sends IGMPs and/or
multicast data to X in native form after decapsulating it. (Since, other
than X, RB3 is shown as only connected to other Rbridges, it would never
get a native IGMP or multicast frame it could just forward to X in
native form, as well as encapsulating and sending to other Rbridges...)
@@@ The situation for X is, as far as I can see, exactly the same as it
was for assorted end stations/bridges inside the bridged LAN in your
diagram except that X can't get at stuff not sent to it even if it
understands TRILL frames which boxes inside the bridged LAN could be
haired up to understand TRILL frames, although that is not necessary.

@@@ For the above reasons, the only problem I see is the silent IP
multicast router. Everything else works fine and in the same way
regardless of whether or not one or more bridges and/or a bridge LAN are
involved.

@@@ Sure. I assume MMRP is some form of GMRP made more complex to work
with MSTP. As I recall, GMRP is optional for 802.1 bridges. Is MMRP
mandatory? Anyway, I'm sure with enough work you could add almost any
additional bridge related protocols to Rbridges, but would it be worth
the effort?

@@@ I don't think "we restrict traffic flow to a single symmetric tree
within" and Rbridge network. But maybe we are interpreting something
differently.

@@@ Sure, feel free to suggest text clarifying this.

@@@ One assertion is that you can incrementally replace unconfigured
bridges with unconfigured Rbridges and the network will still operate
"correctly", although some topologies may be inefficient.

@@@ Generally speaking, the most efficient topologies in incremental
replacement is to maximally partition the remnant bridged LAN, splitting
it with Rbridges into pieces that are as small as possible.

Anoop

@@@ Thanks,
@@@ Donald

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 21 Jun 2007 08:16:02 -0500

Anoop,

	I agree with Donald, and I am still having difficulty in seeing
why you think this doesn't work.  See specific comments in line (after
your diagram) below.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> don't understand the trill etype.

Here is - IMO - where your argument breaks down.

In this case, assuming that Rb1 and Rb2 are the only two 
RBridges attached to the LAN between them, either Rb1 or
Rb2 will be the designated RBridge for that LAN.

One of the small inefficiencies of the way that the TRILL
design works, is that - in this situation - if Rb1 is the
designated RBridge, the join frame will traverse the LAN
once (as a TRILL encapsulated frame) from Rb2 to Rb1, and
then will be decapsulated and forwarded "in the raw" to
the stations on the LAN.

That is precisely why I said that - unless you expect us
to perform some kind of inappropriate filtering - control
frames will be seen throughout a (V)LAN.

The reason why this occurs is that Rb1 - as the desginated
RBridge in this case - is required to ensure that the IGMP
join (which it MUST treat as an external data frame in any
case) is delivered throughout the broadcast domain.  This
is because - without special knowledge (such as might be
configured) - Rb1 has no reason to believe that the target
for the join message is not on the local LAN.

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 21 Jun 2007 07:07:45 -0700

Anoop,

I agree with Donald,

I think the draft is fine, it does not prevent ECMP.
No protocol that I know specify how "to determine flows".

I don't see any action needed.

-- Silvano

> Behalf Of Eastlake III Donald-LDE008
> preserve

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 21 Jun 2007 07:09:28 -0700

Radia,

This information was known at the time of the consensus.
I still remain in favor of the header we selected.
If somebody wants to change his/her mind they can email this list
(SOON).

-- Silvano

> Sent: Wednesday, June 20, 2007 12:57 PM
> To: Anoop Ghanwani
> Cc: Caitlin Bestler; Eric Gray (LO/EUS); Silvano Gai;
rbridge at postel.org

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 21 Jun 2007 07:09:42 -0700

Sure

-- Silvano

> Sent: Wednesday, June 20, 2007 1:00 PM
> To: Anoop Ghanwani

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 21 Jun 2007 07:11:40 -0700

Anoop,

If the language in my email is the problem, I take it back.
I am happy with the language in the draft.

-- Silvano

> Sent: Wednesday, June 20, 2007 1:22 PM
> To: Radia Perlman; Anoop Ghanwani
> Cc: Silvano Gai; rbridge at postel.org

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 21 Jun 2007 07:14:18 -0700

Anoop,

It is OK to agree to disagree with Eric.
 
The current draft says:
"ECMP (Equal Cost MultiPath) may be supported, but it may introduce
frame reordering."

Donald has offered to add some additional wording.

I think we are fine

-- Silvano

> Sent: Wednesday, June 20, 2007 1:33 PM

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 21 Jun 2007 09:33:05 -0700

I was just responding to Eric's comment about
lack of consensus for ECMP.  It looks like we
have that.

I didn't mention anything about flows, so
that's not a concern for me.

Anoop 

> Sent: Thursday, June 21, 2007 7:08 AM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> > Personally, I would like the group to get to a consensus on 
> the ECMP 
> > issue fairly quickly.
> > 
> > I too, just like Silvano, thought it was going to be done.
> > 
> > Anoop
> > 
> difference 
> > > between "core" and "not core" is not always as clear cut as you 
> > > apparently think it is.  Nor is it necessarily going to be simple 
> > > for a device to determine which of the available equal cost paths 
> > > only contain core elements.
> > >
> place where 
> > > equal costs exist in a "routing" domain.  That is at 
> least as likely 
> > > to occur in locii containing one or more edge components, 
> as it is 
> > > anywhere else.
> > >
> > > 	There are certainly limited applications - typically requiring 
> > > careful configuration to restrict ECMP-like activity to very 
> > > specifically defined equal cost paths - where it will be 
> possible to 
> > > say "we do ECMP only in the core."  I personally wonder why 
> > > link-bundling wouldn't be a better solution in those 
> cases, however.
> > >
> > > Thanks!
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Thu, 21 Jun 2007 10:31:33 -0700

rbridge-bounces at postel.org wrote:
> This thread was started because of the assertion that the
> current rbridge proposal is "opaque" and is completely
> compatible with bridges.
> 
> @@@ Of course, that depends on what "completely compatible"
> means. The protocol specification just says "compatible", not
> "completely compatible" :-) 
> 
> I pointed out that it breaks snooping once the frames are
> trill encap'ed and this snooping is required if you have 2
> rbridges interconnected by a regular LAN that doesn't have
> any end nodes that are interested in seeing that multicast.
> 
> @@@ You may have found a problem, but I really don't think it
> is the problem you believe it is, as I will try to explain
> below. Furthermore, I can't see why the bridges in the
> bridged LAN need to snoop if there are no multicast listeners
> or IP multicast routers inside the bridged LAN.
> 
> To which Donald responded saying that the DRB for the bridged
> LAN would be sending a decap'ed version of the control
> packets to the LAN anyway, and so snooping would continue to work.
> 
> @@@ Well, I was trying to say something more like the DRB
> would send in any traffic that nodes inside the bridged LAN
> had indicated any interest in.
> 
> When B sends a join, it gets trill encap'ed by Rb2 and
> forwarded to Rb1.  The bridges in the LAN can't snoop that
> because they don't understand the trill etype.
> 
> @@@ Right, stuff with a TRILL Header is opaque to boxes which
> don't understand how to parse it. So boxes that are not
> Rbridges, including the bridges on this bridged LAN, will be
> in the dark.
> 
> When multicast data are forwarded from Rb1 to Rb2 it is
> encap'ed as trill and sent to the all-rbridges address.  The
> bridges on the LAN (all 10 of them) will see this frame and
> copy it to all stations on that LAN.
> 
> @@@ That is correct with the current protocol spec. But I
> would point out that at the expense of slightly more complex
> conditionals, the protocol could notice that there is only
> one IS-IS adjacency on that link out of RB1 and unicast the
> TRILL data frames even if the encapsulated frame had a
> multicast destination. (Of course, it would want to keep
> multicasting the TRILL IS-IS frames in case another Rbridge
> If there is unicast data being forwarded from RB1 to RB2, it
> would be unicast. But I am digressing.
> 

I would actually consider that a local implementation optimization.
If there is any language that might seem to forbid this it would
be nice to rephrase it.

So the "missed optimization" here is when:

a) there is a single cloud that connects multiple RBridges.
b) More than one of these RBridges should receive an encapsulated
   multicast frame, but the remaining RBridges have no use for it.
c) Because it will be multicast to "all rbridges" some rbridges
   will receive the frame, and then determine that they have no
   local target, and the won't deliver it.
d) because of encapsulation, a non-RBRidge bridge that did
   transparent IGMP snooping would not be able to optimize
   the forwarding of this message through the cloud.

Aren't *all* of the following scenarios far more common?

- There is snooping Bridge in the cloud.
- The traffic is relevant to *all* RBridges attached to the cloud,
  especially when "all" is really "both".
- The traffic is relevant only to a single RBridge.

Further, aren't RBridges capable of providing this optimization
themselves rather than relying on the snooping bridges?

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 21 Jun 2007 14:59:42 -0400

Hi Caitlin,

See below at @@@

-----Original Message-----
From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
Sent: Thursday, June 21, 2007 1:32 PM
To: Eastlake III Donald-LDE008; Anoop Ghanwani
Cc: rbridge at postel.org
Subject: RE: [rbridge] per-VLAN instances of IS-IS

...

@@@ I agree that it is a relatively minor optimization and should be a
MAY, but it is not quite local. It means that an Rbridge about to
forward a multi-destination frame out a particular port to send it down
a branch of the pruned distribution tree notices that there is only one
intended next hop receiver. It then sticks the MAC address of that
Rbridge into the Outer DA rather than the All Rbridges multicast
address. I think the specification should be modified to say this
behavior is a MAY.

@@@ But, a change is also needed at the receiver. A unicast TRILL
Ethertype frame with the multi-destination bit on in the TRILL Header
never occurs currently and so might well be discarded as an erroneous
frame. Alternatively, an Rbridge might conclude, since the only unicast
TRILL data frames currently are known unicast, that the frame must be a
known unicast data frame, ignore the multi-destination bit, and treat
the egress Rbridge nickname as the destination rather than the tree
root! So I believe you would also have to say that all Rbridges MUST
accept such frame and process them the same they would if it had been
addressed to the All Rbridge multicast address.

@@@ Note that if an Rbridge is sending some multi-destination frame out
several ports, it might be able to do this optimization on some ports
and not others. So you would have one multicast version of the frame and
possible several slightly different (just Outer DA and FCS) unicast
versions of the frame going out, which might be inconvenient for some
Rbridge architectures. So it shouldn't be mandatory to do this
optimization.

@@@ If the path between these Rbridges is a bridged LAN, then all the
bridges and any end stations will also get it, in general, because the
bridges will flood it on their spanning tree.

@@@ Well, actually, since the All Rbridges multicast address is not an
IP derived multicast, it is not clear that IGMP snooping bridges can
optimize such frames.

@@@ Sure, whether this optimization helps is highly dependent on network
topology. But it is quite possible, if you have several Rbridges on a
multi-access link, that broadcast traffic being sent by one on a
distribution tree, after that tree is pruned for VLAN, would only be
destined for one of the Rbridges attached to that link. This seems even
more likely if the traffic is multicast and the tree is pruned by not
just VLAN but also for multicast listeners and IP multicast routers. On
the other hand, if you have a network with just Rbridges and endstations
connected entirely by point-to-point links, notice that there is always
exactly one receiver out any particular port and it generally makes no
difference whether you use a unicast or the All Rbridge multicast
address for TRILL frames between Rbridges in such a network.

@@@ Yes, the optimization I have been talking about, at least, which is,
when appropriate, sending an encapsulated multi-destination TRILL frame
out a particular port unicast rather than multicast, would be
implemented just in Rbridges and doesn't have any particular
relationship to bridges.

@@@ Thanks,
@@@ Donald

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 21 Jun 2007 17:30:21 -0700

Caitlin,

All of your points are valid.  All I'm trying to
point out is that things as defined break how
bridges currently operate.  They still work, just
not as well as they do without RBridges.

What is likely, what is not likely, what can
be optimized, etc. are all valid points/concerns.
We just have to be clear that regardless of
what we do, we can't pretend that the effect
of using RBridges in a network will not have
an impact on operation of existing bridges.

Anoop 

> Sent: Thursday, June 21, 2007 10:32 AM
> > This thread was started because of the assertion that the current 
> > rbridge proposal is "opaque" and is completely compatible with 
> > bridges.
> > 
> > I pointed out that it breaks snooping once the frames are trill 
> > encap'ed and this snooping is required if you have 2 rbridges 
> > interconnected by a regular LAN that doesn't have any end 
> nodes that 
> > are interested in seeing that multicast.
> > 
> > problem you believe it is, as I will try to explain below. 
> > Furthermore, I can't see why the bridges in the bridged LAN need to 
> > snoop if there are no multicast listeners or IP multicast routers 
> > inside the bridged LAN.
> > 
> > To which Donald responded saying that the DRB for the bridged LAN 
> > would be sending a decap'ed version of the control packets 
> to the LAN 
> would send 
> > in any traffic that nodes inside the bridged LAN had indicated any 
> > interest in.
> > 
> > I still don't think it works.  Consider the following network.
> > 
> > 
> >   Multicast router
> >    |
> >    Rb1 (DRB for the LAN)
> >    |
> >  bridged LAN with 10 bridges and hosts  in some random configuration
> >    |
> >    Rb2
> >    |
> >    B
> > 
> > When B sends a join, it gets trill encap'ed by Rb2 and forwarded to 
> > Rb1.  The bridges in the LAN can't snoop that because they don't 
> > understand the trill etype.
> > 
> > When multicast data are forwarded from Rb1 to Rb2 it is encap'ed as 
> > trill and sent to the all-rbridges address.  The bridges on the LAN 
> > (all 10 of them) will see this frame and copy it to all stations on 
> > that LAN.
> > 
> would point 
> > want to keep multicasting the TRILL IS-IS frames in case another 
> > Rbridge shows up.) There is nothing peculiar about a unicast TRILL 
> > data frame.
> If there is any language that might seem to forbid this it 
> would be nice to rephrase it.
> 
> Further, aren't RBridges capable of providing this 
> optimization themselves rather than relying on the snooping bridges?
>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 21 Jun 2007 17:51:15 -0700

> Sent: Wednesday, June 20, 2007 8:53 PM
> To: Anoop Ghanwani
> Furthermore,

If they could actually snoop, the flow of 
multicast data within that bridged LAN would
have been limited to only those parties
interested in the multicast.

> would send in

What happens if you have 10 rbridges attached
to that bridged LAN and only 2 of them were
interested in the multicast.  The other 8
would see it too.

> forwarded into the bridged LAN also...

Yes, I was a bit confused there.  Please
ignore the stuff about the decap'ed frames
for now.  But we still have a problem...

> for any box in the bridged LAN to care.

Except that it does in fact get delivered
to all of the rbridges in the LAN.

> additional bridge related protocols to Rbridges, but would it be worth

GMRP already worked with MSTP.  MMRP runs
on top of MRP which replaces GARP.

> "correctly", although some topologies may be inefficient.

Yes, that some topologies will be inefficient
is key.  In that respect we don't really have to
be 100% backwards compatible with bridges.
 
> it with Rbridges into pieces that are as small as possible.

And in the limit, making the "core" consist of
only rBridges.  That is what would be most efficient
from a forwarding standpoint.

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 22 Jun 2007 00:23:56 -0400

Hi Anoop,

These bridged systems with 4K VLANs... It is my impression that they
don't usually have 4K different communities that need to be isolated
from each other. Rather, they are multiplying VLANs to use various
configured mechanisms to try to get around the problems of spanning
tree.

What you say below gives me an image of a bridged LAN directly connected
to an Rbridge campus. This is probably not the best arrangement. If they
are multiply connected, all the traffic will end up going through one
Designated Rbridge unless you set the different Rbridges that connect to
the bridged LAN to different priorities for becoming DRB for different
VLANs or the like.

Anyway, just because the "core" bridges in this hypothetical case are
carrying traffic tagged for 4K VLANs does not imply much of anything
about the attached Rbridge campus. As I say, there is a per VLAN
instance of IS-IS running in an RBridge ONLY if that Rbridge is DRB for
one or more end stations in that VLAN and it is configured to accept
that VLAN.

To be more specific, we need to make some numeric assumptions. Let's
assume that, although this big bridged LAN has 4K VLANs in it, the
attached Rbridge campus only uses 100 of them. Then, if there was only
one Rbridge connecting to the bridged LAN, that one Rbridge would end up
with 100 per VLAN instances of IS-IS running in it. But this seems kind
of implausible. With such a large network, it seems like you would want
some load spreading. So lets say there were 4 Rbridges at the "edge" of
the campus connected to the bridged LAN and they divide up the VLANs
through priority configuration. Then each might have 25 per VLAN IS-IS
instances.

Looking at the rest of the Rbridge campus in question, no "core
Rbridge", that is Rbridges that only connect to other Rbridges, would
have any per VLAN IS-IS instances. Per VLAN IS-IS instances are only
needed in the "edge Rbridges", that is, ones with end stations attached
in that VLAN for which they are DRB. I would guess that most of them
would have, at most, a handful of per VLAN IS-IS instances. Of course
the "edge Rbridges" that connect to the bridged LAN are actually see it
as one big multi-access link with, under the assumptions above, end
stations in 100 VLANs.

In any case, the per VLAN instances of IS-IS are optional anyway, so you
don't have to have them

Thanks,
Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Friday, June 15, 2007 4:47 PM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org; Radia Perlman
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Anoop

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 22 Jun 2007 14:49:04 -0700

Donald,

> Sent: Thursday, June 21, 2007 9:24 PM
> To: Anoop Ghanwani

Not true in general, hosting companies have exactly this problem

Cheers

-- Silvano

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 22 Jun 2007 15:43:32 -0700

I don't see much of an advantage to changing things because 
it doesn't change the fact that rBridges rely on the 
"inner frame" to get correct pruning behavior for multicasts.

However, I agree with Silvano.  _If_ something is going 
to change, let's try and settle it as soon as we possibly can.

Anoop 

> Sent: Thursday, June 21, 2007 7:09 AM
> Cc: Caitlin Bestler; Eric Gray (LO/EUS); rbridge at postel.org
> If somebody wants to change his/her mind they can email this 
> list (SOON).
> 
> 
> -- Silvano
> 
> > As Anoop said, core RBridges need to look inside the 
> tunneled packet 
> > at the inner packet in order to do multicast pruning as 
> well as VLAN 
> > pruning on multicast packets.
> > 
> > VLAN tag and DA from the inner packet so that it wouldn't 
> mean adding 
> > an extra 6 bytes to an encapsulated frame).
> > 
> > the WG really is deciding not to do that, that they really 
> understand 
> > what they are deciding against.
> > discussed at the same time that it's obvious that people 
> (definitely 
> > including me) are getting confused.
> > 
> > Radia
> > 
> > 
> > 
> > 
> > Anoop Ghanwani wrote:
> > >
> > > They're snooping because they too care about pruning 
> their trees for 
> > > a given multicast group and that would be one of the ways 
> to achieve 
> > > it.
> > > Otherwise, all multicasts would have to be broadcast on 
> the spanning 
> > > tree interconnecting the bridged network that sits 
> between the two 
> > > rBridges.
> > >
> > >
> > > If we didn't care about multicast pruning, we wouldn't 
> need to worry 
> > > about any of this.
> > >
> > >
>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 22 Jun 2007 16:18:20 -0700

> In any case, the per VLAN instances of IS-IS are optional 

That this feature will be optional is good to know.  
I don't see it being applicable for the problem I'm
trying to solve.

Thanks,
Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 25 Jun 2007 14:08:52 -0400

Hi,

The current TRILL data frame on an 802.3 link looks like this (the Outer
VLAN Tag is not always present):

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                  Outer Destination MAC Address                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Outer Destination MAC Address | Outer Source MAC Address      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Outer Source MAC Address                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Start "TRILL Header":
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Ethertype = TRILL             |  V  |M|R|Op-Length| Hop Count | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Egress (RB2) Nickname      |    Ingress (RB1) Nickname     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:End "TRILL Header"
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |               Inner Destination MAC Address                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Inner Destination MAC Address |  Inner Source MAC Address     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Inner Source MAC Address                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Ethertype = IEEE 802.1Q       |  Inner.VLAN Tag Information   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Payload Ethertype       |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Payload                 | 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      FCS (Frame CheckSum)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Where the V field is two zero bits, for Version 0, followed by another
zero bit for a TRILL data frame (or a 1 bit for a TRILL IS-IS frame).
That is, V=0 (or V=1). See draft-ietf-trill-rbridge-protocol-04.txt.

(Side note: there should be a separate discussion about Q-tags
versus/and/or S-tags but I think that is pretty orthogonal to what I
want to talk about here.)

There is no question that this format "works". But I don't see that as
the point. After all, 803.3 Ethernet would "work" if you moved the
Destination Address to the end of the frame. But it wouldn't be good
engineering, because cut through switching or similar optimizations
would be impossible.

What I am primarily worried about is the fast path at transit Rbridges.
There doesn't seem to be any way to avoid a fair amount of work at the
ingress Rbridge. And it could be that there would be some
implementations that wouldn't mind having to grovel deep into a frame at
every transit Rbridge. But I think most implementations will want
transit Rbridge processing of TRILL data frames to be as simple as
possible. And I should think that anyone who is worrying about Rbridging
10Gbps Ethernet or even fast optical channels should be having problems
looking at the current TRILL protocol specification.

First, lets look at unicast. Seems really nice and efficient, even with
the present design. You just decrement the hop count and, if it is
non-zero, use the egress Rbridge nickname to look up the next hop
destination MAC address, output port, and Outer VLAN ID if any, and off
you go. Well, I think it is just a little more complex than that. In
particular, what do you do about the Outer VLAN Tag priority field? An
Outer VLAN Tag added by the previous Rbridge could have been stripped or
changed by bridges. You could imagine wanting to configure various
strategies but I think the right zero configuration default is to simply
get the priority from the Inner VLAN Tag. (Of course, if that turns out
to be the default priority and no Outer VLAN is needed for connectivity
to the next hop Rbridge, no Outer VLAN Tag may be needed at all.) And
then there are options. They start right after ingress nickname and,
even if you can get around the priority problem, if there are options
present, you probably have to look at the first bit or two of the
options area to determine that none of them apply to you...

So unicast isn't too bad, but even there I think you have to check a
couple of bits beyond the header if options are present and the best
default strategy requires you to delve into the inner frame to check the
data priority.

It's multi-destination frames that are the real problem with the current
design for a high speed transit Rbridge that wants to prune the
distribution tree. And, based on comments on this working group mailing
list, many developers will want to prune.

So, say we receive a multi-destination data frame. You know the
distribution tree from the "egress" nickname field. But if you want to
do any pruning, you have to look beyond the TRILL Header. Getting the
information for pruning by VLAN, you need to look at the Inner VLAN ID
which may require skipping over options.

Then we get to multicast pruning. To do that, you might first look at
the Destination MAC Address. That comes even before the Inner VLAN Tag
that you had to look at for VLAN pruning, so this doesn't sound too
hard. But it also turns out that it is not adequate. RFC 4541 on IGMP
snooping and the like is now out and it points out that there are ranges
of special IPv4 and IPv6 multicast addresses for which hosts don't, or
at least can not be depended on to, issue IGMPs (or MLDs or IPv6).
Therefore, frames sent to those IP multicast addresses have to be
treated as broadcast and distribution can't be pruned. But, these IP
multicast addresses are translated ambiguously to MAC multicast
addresses just like other IP multicast addresses. So, if we look at the
Destination MAC address and find it is an IP derived multicast, we are
not done.

For IPv4 derived multicast MAC addresses, there is a range of such
multicast addresses for which you have to dig even deeper into the frame
and look at the actual IPv4 address to see if you can prune or have to
broadcast. True, for IPv4 it is only a small fraction of the possible IP
derived multicast addresses, and an alternative might be to always
broadcast frames to those IPv4 derived MAC multicast addresses; but if
some group just happens to be sending their streaming video over a
multicast group that just happens to map into this area, it may not work
out so well for your network that those frames are getting broadcast
everywhere in that VLAN.

The situation it much worse for IPv6. In the case of IPv6 derived MAC
multicast addresses, 100% are potentially for special IPv6 multicast
addresses that you must broadcast. As a result, if you are going to
prune IPv6 derived multicast, you *always* have to go look at the actual
IPv6 destination address deeper in the frame to decide whether or not to
prune.

Finally, we come to the worst case, detecting IGMP, MLD, etc. messages.
Here you have to go beyond the IPv4 or IPv6 destination address, delve
deeper into the IP header and, in some cases, into the IP packet content
just to figure out whether you need to prune the distribution tree to
branches with IP multicast routers on them for IGMP and MLD (and RFC
4541 specifically recommends, due to confusions that can happen between
IGMPv3 and earlier version of IGMP, not sending such message to links
unless they have an IP multicast router on the).

I really don't think you want to have to look into the content of IP
packets to make forwarding decisions at transit Rbridges.

So, what I suggest is something more like the following:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                  Outer Destination MAC Address                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Outer Destination MAC Address | Outer Source MAC Address      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          Outer Source MAC Address  (last four bytes)          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Ethertype = IEEE 802.1Q       |  Outer.VLAN Tag Information   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Start "TRILL Tag":
 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = |         TRILL Ethertype       |   V   |M|Op-Length| Hop Count |
 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = |   Egress RBridge Nickname     |  Inner VLAN Tag information   |
 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = |        Inner Destination MAC Address (first four bytes)       |
 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 = |   Inner Dest MAC Adr          |  Ingress RBridge Nickname     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Inner Source MAC Address (first four bytes)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Rest of Inner Src MAC Adr   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
End "TRILL Tag":                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |       Payload Ethertype       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Payload ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Final Checksum:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Frame Check Sum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
   V = 0 for TRILL IS-IS frames
   V = 1 for TRILL data pruned only on VLAN
   V = 2 for TRILL data pruned on VLAN and IP multicast MAC address
   V = 3 for TRILL data pruned on VLAN and IP multicast routers location

This puts everything that is needed for a transit Rbridge to forward
frames in the first 128 bits of what I have labeled the TRILL Tag (see
"=" in left margin). Why did I label it "Tag" rather than "Header"?
Well, the header paradigm seems to connote that we are adding a header
in front of an almost complete Ethernet frame. Tag seems like a better
word if we are constructing a block that goes in front of a frame
contents, not a frame. In some ways, it just depends on how you look at
it. 

For multicast optimization, the investigation into the frame as to
whether the distribution tree should be (1) only VLAN pruned, (2) pruned
on VLAN and based on multicast destination address, or (3) pruned on
VLAN and branches that have multicast routers, needs to be made only
once, at the ingress Rbridge, and is then encoded into V.

The current header is 64-bits and 64-bit aligned (starting after the
Outer VLAN tag) which is nice, but you always have to look beyond it for
every frame. Sometimes way beyond it, including skipping over any TRILL
options and IP options, to look into the content of IP packets.

The suggested TRILL tag is 176 bits long but, unless you are an egress
Rbridge, you only have to look at the first 128 bits which is 128-bit
aligned (ignoring the outer VLAN tag like I did for the current header).
But since fields are mostly just being moved around, at worst you gain
or lose two bytes total length over previous proposals. Options would
start after the destination MAC address so, even if options are present,
you can check the first few bits of the options area without going
outside this 128-bit area.

This proposal does suppress the Ethertype for the inner VLAN Tag
information but there is some precedent for that sort of thing. For
example, 802.16 has a header suppression feature where you can set some
flag bits and then leave out Q-tag and/or IPv4 or IPv6 Ethertypes.

So, while various minor changes could be made, the above is my
suggestion for significantly improving the simplicity and cut through
switching latency of handling TRILL data frames at transit Rbridges.

Since there was a consensus determination in favor of the current TRILL
Header, there needs to be a consensus to re-open the question. If there
isn't, my fall back position would be to suggest expanding the values of
V in the TRILL Header to encode the correct pruning strategy for a
frame, as listed with the TRILL Tag proposal above. This would not
eliminate the need to delve into the inner frame whenever a TRILL frame
is handled by a transit Rbridge, but would reduce to depth and
complexity of such delving...

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 22, 2007 6:44 PM
To: Silvano Gai; Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] per-VLAN instances of IS-IS

Anoop

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 27 Jun 2007 08:17:33 -0700

Donald,

The information contained in your email was known and discussed at the
time of the consensus on the header format. I don't see any reason to
change and I remain strongly in favor of the current format.

-- Silvano

> Sent: Monday, June 25, 2007 11:09 AM
> Subject: [rbridge] TRILL Header/Tag
> 
> Hi,
>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 27 Jun 2007 12:16:34 -0400

Hi Silvano,

It is true that most of the information was know.

However I didn't know, and I don't recall it being discussed, that an IP
derived multicast destination MAC address is insufficient to tell
whether or not you can multicast prune the distribution tree.  I don't
know about other people, but I didn't know that until I looked at RFC
4541.

Do you object to changing from 2 message types to 4 message types so
that the type of distribution tree pruning that would be advisable is
encoded into the message type?

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Wednesday, June 27, 2007 11:18 AM
To: Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

-- Silvano

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 27 Jun 2007 12:38:10 -0400

Sorry, a point I left out in my message below:

At the time of the previous discussion, I believed, and I think most
people believed, that there was no reason for a transit Rbridge to look
beyond the TRILL Header for unicast traffic. However, that may not be
true because the transit Rbridge may have to dig down to the inner VLAN
tag to find the priority.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Eastlake III Donald-LDE008
Sent: Wednesday, June 27, 2007 12:17 PM
To: Silvano Gai
Cc: rbridge at postel.org
Subject: Re: [rbridge] TRILL Header/Tag

Hi Silvano,

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Wednesday, June 27, 2007 11:18 AM
To: Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

-- Silvano

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 28 Jun 2007 07:26:12 -0700

I'm with Silvano on this; I'd rather not
see the fields moved around.

I'm also skeptical about the need for the
several flavors of the V-bits.  I think
the Rbridge nickname, inner MAC address, and 
inner VLAN combo should be enough to tell
one how to forward the frame.

Anoop

> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> Sent: Wednesday, June 27, 2007 8:18 AM
> > implementations that wouldn't mind having to grovel deep 
> into a frame
> at
> > Outer VLAN Tag added by the previous Rbridge could have 
> been stripped
> or
> > broadcast. True, for IPv4 it is only a small fraction of 
> the possible
> IP
> > IPv6 destination address deeper in the frame to decide 
> whether or not
> to
> > prune.
> > 
> > isn't, my fall back position would be to suggest expanding 
> the values
> of

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 28 Jun 2007 13:53:05 -0400

Hi Anoop,

If you want to prune IP multicast and you believe RFC 4541, then the
fields you enumerated are inadequate to determine how to forward a frame
at a transit Rbridge.

Although, on re-reading the stuff in RFC 4541, things may not be as bad
as I thought they were for IPv6, nevertheless there are IP derived MAC
multicast addresses for both IPv4 and IPv6 where you should prune for
some values of the original IP address and must broadcast for other
values.

For example, both 224.0.0.42 and 225.128.0.42 are valid IPv4 multicast
addresses from which the same MAC address, namely 01-00-5E-00-00-2A,
would be derived. You would want to prune traffic to 225.128.0.42 but
you can't validly prune traffic to 224.0.0.42 because, according to RFC
4541, hosts do not consistently issue IGMPs for IPv4 addresses in the
224.0.0.0/24 range.

I haven't studied all the IGMP stuff for different versions but, for
IGMP (and MLD), at best you have the problem in the paragraph above and
at worst even the IP multicast address would be inadequate and you would
have to look deeper into the frame to check the IP protocol, etc., in
order to decide whether to prune just to branches with IP multicast
routers.

So I believe the very simple change of adding a few more V values would
vastly simplify processing at transit Rbridges. This change is
independent of whether or not fields are moved.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Thursday, June 28, 2007 10:26 AM
To: Silvano Gai; Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] TRILL Header/Tag

Anoop

---

From: james.d.carlson at sun.com (James Carlson)
Date: Thu, 28 Jun 2007 14:49:19 -0400

> 4541, hosts do not consistently issue IGMPs for IPv4 addresses in the

Yep; exactly.  224.0.0.0/24 is both "link-local" and "well-known" and
thus expected to work right without the help or interference of
multicast routers.  (Where, "right" means that all stations on the
link can receive it.)

> order to decide whether to prune just to branches with IP multicast

For IGMPv2, you'll need to look deeper, because the IGMP Report
messages from hosts themselves are sent on the group address (RFC 2236
section 9).  With IGMPv3, the Report messages are directed to a common
multicast address (224.0.0.22; RFC 3376 section 4.2.14).

-- 
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: jrrivers at nuovasystems.com (J. R. Rivers)
Date: Thu, 28 Jun 2007 13:23:47 -0700

With IP multicast pruning in bridges, the traditional mode of operation
has been... if you don't know for sure, don't prune.  This is what
allows various implementations to be deployed in the face of no real
specification covering the functionality (and changes in IGMP versions
along the way).

JR

> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
> Sent: Thursday, June 28, 2007 11:49 AM

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 29 Jun 2007 01:11:29 -0700

Donald,

I can see some value in this, but given that
existing bridges wouldn't do any better than
the coarse pruning based on the fields that
I mentioned, I think this functionality should
be listed in the draft as a SHOULD/MAY rather 
than as a MUST.

Anoop

> Sent: Thursday, June 28, 2007 10:53 AM
> To: Anoop Ghanwani
> > >    |                      FCS (Frame CheckSum)            
> > > That is, V=0 (or V=1). See 
> draft-ietf-trill-rbridge-protocol-04.txt.
> > > 
> > > destination MAC address, output port, and Outer VLAN ID 
> if any, and
> > off
> > > get the priority from the Inner VLAN Tag. (Of course, if 
> that turns
> > out
> > > default strategy requires you to delve into the inner 
> frame to check
> > the
> > > data priority.
> > > 
> > > addresses just like other IP multicast addresses. So, if 
> we look at
> > the
> > > multicast group that just happens to map into this area, 
> it may not
> > work
> > >  = 
> > >  = 
> > >  = 
> > >  = 
> > >                                    |       Payload 
> Ethertype       |
> > >    |                       Frame Check Sum                
> > > contents, not a frame. In some ways, it just depends on 
> how you look
> > at
> > > it.
> > > 
> > > Outer VLAN tag) which is nice, but you always have to 
> look beyond it
> > for

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 30 Jun 2007 21:53:38 -0400

Hi,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Friday, June 29, 2007 4:11 AM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

@@@ If you say so, I'm sure some bridges prune based on the fields you
list. In any case, both types of pruning, VLAN and multicast, are only
"SHOULD" in the current protocol draft. However, I think the draft needs
to be fixed up to describe correctly how to implement state-of-the-art
multicast pruning, taking into account James Carlson's comments and
further taking account of RFC 4541. It also needs to describe how to
correctly not do multicast pruning. Of course, an Rbridge could do
something between these two points. You may have a campus with some
Rbridges doing all of RFC 4541 multicast pruning things and some doing
none and some doing the "coarse grained pruning" you describe. If you
are not careful, some multicast traffic or IGMP/MLDs from Rbridges which
are pruning may not get to the links connected to the Rbridges ignoring
multicast pruning.

Anoop 

-----Original Message-----
From: J. R. Rivers [mailto:jrrivers at nuovasystems.com] 
Sent: Thursday, June 28, 2007 4:24 PM
To: James Carlson; Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] TRILL Header/Tag

@@@ I'm not sure what you mean by "real specification" but RFC 4541
seems reasonably close to me. Sure, you can always not optimize by
flooding something. But it seems to me that TRILL should make it
possible for Rbridges to do the best job they reasonably can on IP
derived multicast pruning.

JR

@@@ All I'm aiming for in this case it to make it possible for Rbridges
that want to prune IP derived multicast according to the only
comprehensive document on the subject (RFC 4541) to be able to do so
efficiently. To me, that means that if there are Rbridges (perhaps
including the ingress Rbridge but possibly starting at a transit
Rbridge) doing full IP derived multicast pruning, only the first one
that sees a frame should have to do the complete analysis. The results
of that analysis can be encoded by selecting one of the three values of
the V field and used by any subsequent Rbridges that wish to do so. An
Rbridge that doesn't want to do IP multicast pruning can just ignore V
as long as it's in the range indicating the current version of TRILL.

@@@ In this scheme, to accommodate Rbridges that don't want to do
multicast optimization, there probably has to be one additional V value
to indicate that analysis of the frame has not been done from the point
of view of RFC 4541 IP multicast pruning.
	
@@@ Thanks,
@@@ Donald

> multicast address (224.0.0.22; RFC 3376 section 4.2.14).

Content-class: urn:content-classes:message
Date: Sat, 30 Jun 2007 21:53:38 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 5237

Hi,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 4:11 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

@@@ If you say so, I'm sure some bridges prune based on the fields you
list. In any case, both types of pruning, VLAN and multicast, are only
"SHOULD" in the current protocol draft. However, I think the draft needs
to be fixed up to describe correctly how to implement state-of-the-art
multicast pruning, taking into account James Carlson's comments and
further taking account of RFC 4541. It also needs to describe how to
correctly not do multicast pruning. Of course, an Rbridge could do
something between these two points. You may have a campus with some
Rbridges doing all of RFC 4541 multicast pruning things and some doing
none and some doing the "coarse grained pruning" you describe. If you
are not careful, some multicast traffic or IGMP/MLDs from Rbridges which
are pruning may not get to the links connected to the Rbridges ignoring
multicast pruning.

Anoop 

-----Original Message-----
From: J. R. Rivers [mailto:[email-masked]] 
Sent: Thursday, June 28, 2007 4:24 PM
To: James Carlson; Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] TRILL Header/Tag

@@@ I'm not sure what you mean by "real specification" but RFC 4541
seems reasonably close to me. Sure, you can always not optimize by
flooding something. But it seems to me that TRILL should make it
possible for Rbridges to do the best job they reasonably can on IP
derived multicast pruning.

JR

@@@ All I'm aiming for in this case it to make it possible for Rbridges
that want to prune IP derived multicast according to the only
comprehensive document on the subject (RFC 4541) to be able to do so
efficiently. To me, that means that if there are Rbridges (perhaps
including the ingress Rbridge but possibly starting at a transit
Rbridge) doing full IP derived multicast pruning, only the first one
that sees a frame should have to do the complete analysis. The results
of that analysis can be encoded by selecting one of the three values of
the V field and used by any subsequent Rbridges that wish to do so. An
Rbridge that doesn't want to do IP multicast pruning can just ignore V
as long as it's in the range indicating the current version of TRILL.

@@@ In this scheme, to accommodate Rbridges that don't want to do
multicast optimization, there probably has to be one additional V value
to indicate that analysis of the frame has not been done from the point
of view of RFC 4541 IP multicast pruning.
	
@@@ Thanks,
@@@ Donald

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James Carlson
> Cc: [email-masked]
> James Carlson, Solaris Networking              
> <[email-masked]>
> [email-masked]

Date: Fri, 29 Jun 2007 22:49:44 -0700
From: Radia Perlman <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 8751

I think your analysis is correct.

Radia

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

Date: Fri, 29 Jun 2007 22:26:44 -0700
From: Radia Perlman <[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: 7089

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
>> 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
>>     
>>> 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
>>> 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
>>>
>>>       
>>>> [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
>>>> 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
>>>>
>>>>         
>>>>> [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: Fri, 29 Jun 2007 15:55:43 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 7988

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

-----Original Message-----
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
> 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
> > 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
> > 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
> > 
> > > [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
> > > 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
> > >
> > > > [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]

Content-class: urn:content-classes:message
Date: Fri, 29 Jun 2007 12:10:21 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 6156

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

Content-class: urn:content-classes:message
Date: Fri, 29 Jun 2007 01:11:29 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 21653

Donald,

Anoop

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: Anoop Ghanwani [mailto:[email-masked]] 
> To: Silvano Gai; Eastlake III Donald-LDE008; [email-masked]
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Silvano Gai
> > To: Eastlake III Donald-LDE008; [email-masked]
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > To: [email-masked]
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Behalf Of Anoop Ghanwani
> > > Cc: [email-masked]
> > > > From: Silvano Gai [mailto:[email-masked]]
> > > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); [email-masked]
> > > > > From: Radia Perlman [mailto:[email-masked]]
> > > > [email-masked]
> > > [email-masked]
> > [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 29 Jun 2007 01:02:47 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 5139

Donald,

Yes, I kind of got that after sending this note.
I guess it would be needed if someone intended
to use the per VLAN IS-IS instances.

Anoop 

> [mailto:[email-masked]] 
> 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
> 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 
> 
> > [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
> > 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
> > 
> > > [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
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 13:53:49 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 5286

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
> 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?
> From: Anoop Ghanwani [mailto:[email-masked]]
> Sent: Thursday, June 28, 2007 10:34 AM
> 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
> 
> > [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
> > 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
> >
> > > [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]

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 13:23:47 -0700
From: "J. R. Rivers" <[email-masked]>
To: "James Carlson" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 2321

JR

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James Carlson
> Cc: [email-masked]
> James Carlson, Solaris Networking              
> <[email-masked]>
> [email-masked]

Date: Thu, 28 Jun 2007 14:49:19 -0400
From: James Carlson <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 1505

-- 
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: Thu, 28 Jun 2007 13:53:05 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 19909

Hi Anoop,

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Thursday, June 28, 2007 10:26 AM
To: Silvano Gai; Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] TRILL Header/Tag

Anoop

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> To: Eastlake III Donald-LDE008; [email-masked]
> > From: [email-masked] [mailto:[email-masked]]
> On
> > To: [email-masked]
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Anoop Ghanwani
> > Cc: [email-masked]
> > > From: Silvano Gai [mailto:[email-masked]]
> > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); [email-masked]
> > > > From: Radia Perlman [mailto:[email-masked]]
> > > [email-masked]
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 11:45:53 -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: 4435

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

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

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

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 07:46:25 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 3495

If we want to use the "inner.vlan = not present" to distinguish the core
instance from the per VLAN instance, we must specify that all TRILL
frames MUST have an explicit inner.vlan unless they are the ISIS core
instance.

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Anoop Ghanwani
> Sent: Thursday, June 28, 2007 7:00 AM
> 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
> 
> > [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]

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 07:33:42 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 3950

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 

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

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 10:29:30 -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: 3283

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

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

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

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 07:26:12 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 18297

Anoop

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> To: Eastlake III Donald-LDE008; [email-masked]
> > From: [email-masked] [mailto:[email-masked]]
> On
> > To: [email-masked]
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Anoop Ghanwani
> > Cc: [email-masked]
> > > From: Silvano Gai [mailto:[email-masked]]
> > > Cc: Caitlin Bestler; Eric Gray (LO/EUS); [email-masked]
> > > > From: Radia Perlman [mailto:[email-masked]]
> > > [email-masked]
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 07:00:10 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 2688

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

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

Content-class: urn:content-classes:message
Date: Thu, 28 Jun 2007 00:08:34 -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: 1443

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

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

Content-class: urn:content-classes:message
Date: Wed, 27 Jun 2007 18:41:42 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] a clarification about the core IS-IS instance
Status: RO
Content-Length: 488

>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

Content-class: urn:content-classes:message
Date: Wed, 27 Jun 2007 12:38:10 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Silvano Gai" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 1733

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Wednesday, June 27, 2007 12:17 PM
To: Silvano Gai
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header/Tag

Hi Silvano,

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2007 11:18 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

-- Silvano

[email-masked]

Content-class: urn:content-classes:message
Date: Wed, 27 Jun 2007 12:16:34 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Silvano Gai" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 971

Hi Silvano,

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2007 11:18 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] TRILL Header/Tag

Donald,

-- Silvano

Content-class: urn:content-classes:message
Date: Wed, 27 Jun 2007 08:17:33 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 16739

Donald,

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> To: [email-masked]
> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]
> > From: Silvano Gai [mailto:[email-masked]]
> > Cc: Caitlin Bestler; Eric Gray (LO/EUS); [email-masked]
> > > From: Radia Perlman [mailto:[email-masked]]
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 25 Jun 2007 23:14:48 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "James Carlson" <[email-masked]>, "TRILL/RBridge Working Group" <[email-masked]>
Subject: Re: [rbridge] multicast router discovery: what's PIM got to do with it?
Status: RO
Content-Length: 3552

You may be right. The provisions in the current draft were developed
based on earlier discussions in the working group and IETF meeting
hallways before RFC 4541 came out.

Donald 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Carlson
Sent: Monday, June 25, 2007 12:44 PM
To: TRILL/RBridge Working Group
Subject: [rbridge] multicast router discovery: what's PIM got to do with
it?

I've read through the list archives, and I'd like some clarification
on the mechanism chosen for detecting multicast routers in the latest
(*-protocol-04) draft.

Section 4.5.1.2 has this text:

   If the frame is a PIM or MRD [RFC4286] message, RB1 learns that there
   is an IP multicast router (for the specified VLAN) on its link, and
   adds that information for the appropriate VLAN in its IS-IS link
   state.

and 4.7 has this:

   Until Multicast Router Discovery (MRD) [RFC4286] is universally
   deployed, RBridges discover IP multicast routers through their
   transmission of PIM messages. So an RBridge concludes there is an IP
   multicast router on its port if it either receives an MRD message or
   a PIM message on that port. A PIM message is recognized because the
   protocol type in the IP header is decimal 103.

This seems odd to me.  RFC 4541 (also referenced) doesn't talk at all
about listening to PIM as part of an IGMP snooping strategy, or any
need to tie IGMP L2 forwarding behavior to any particular multicast
routing protocol.

IGMPv0 (RFC 988) didn't have 'queries', but it also didn't have the
suppression logic that later versions have, and it seems to be dead,
so it shouldn't be an issue.

IGMPv1 (RFC 1112) requires multicast routers (regardless of what
higher-level routing protocol they're using -- PIM or otherwise) to
send periodic IGMP Host Membership Query messages.  You'll know that
they're present by seeing these messages.

Similarly, IGMPv2 (RFC 2236) and MLDv1 (RFC 2710) require routers to
send periodic IGMP Membership Query and MLD Multicast Listener Query
messages.

IGMPv3 (RFC 3376) and MLDv2 (RFC 3810) do the same.  It seems likely
that future versions will be similar.

IGMP and MLD version compatibility depends on having periodic queries
present on the link, so if there's any functioning multicast routing
at all, these messages will be available.  Perhaps more importantly,
listing to PIM "correctly" would mean paying attention not just to the
presence of PIM, but to PIM's DR election, so that IGMP/MLD Report
messages are sent to the right router for the network to make upstream
Joins happen -- sending to the wrong LANs if you misinterpret PIM DR
selection produces the same unintended result as not paying any
attention and forwarding IGMP everywhere.

I don't think it should be necessary to tie RBridge behavior to any
particular multicast routing protocol.  In fact, I don't see an
interoperability issue here at all in simply saying that bridges
SHOULD NOT send IGMP/MLD Report messages to host-only networks, MUST
set the link-state bit appropriately, and leaving it as an
implementation matter to determine how (and if) that's done in any
given implementation.

-- 
James Carlson, Solaris Networking              <[email-masked]>
[email-masked]

Content-class: urn:content-classes:message
Date: Mon, 25 Jun 2007 14:08:52 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL Header/Tag
Status: RO
Content-Length: 15565

Hi,

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 22, 2007 6:44 PM
To: Silvano Gai; Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS

Anoop 

> From: Silvano Gai [mailto:[email-masked]] 
> Cc: Caitlin Bestler; Eric Gray (LO/EUS); [email-masked]
> > From: Radia Perlman [mailto:[email-masked]]
> [email-masked]

Date: Mon, 25 Jun 2007 12:43:43 -0400
From: James Carlson <[email-masked]>
To: TRILL/RBridge Working Group <[email-masked]>
Subject: [rbridge] multicast router discovery: what's PIM got to do with it?
Status: RO
Content-Length: 2961

I've read through the list archives, and I'd like some clarification
on the mechanism chosen for detecting multicast routers in the latest
(*-protocol-04) draft.

Section 4.5.1.2 has this text:

   If the frame is a PIM or MRD [RFC4286] message, RB1 learns that there
   is an IP multicast router (for the specified VLAN) on its link, and
   adds that information for the appropriate VLAN in its IS-IS link
   state.

and 4.7 has this:

   Until Multicast Router Discovery (MRD) [RFC4286] is universally
   deployed, RBridges discover IP multicast routers through their
   transmission of PIM messages. So an RBridge concludes there is an IP
   multicast router on its port if it either receives an MRD message or
   a PIM message on that port. A PIM message is recognized because the
   protocol type in the IP header is decimal 103.

This seems odd to me.  RFC 4541 (also referenced) doesn't talk at all
about listening to PIM as part of an IGMP snooping strategy, or any
need to tie IGMP L2 forwarding behavior to any particular multicast
routing protocol.

IGMPv0 (RFC 988) didn't have 'queries', but it also didn't have the
suppression logic that later versions have, and it seems to be dead,
so it shouldn't be an issue.

IGMPv1 (RFC 1112) requires multicast routers (regardless of what
higher-level routing protocol they're using -- PIM or otherwise) to
send periodic IGMP Host Membership Query messages.  You'll know that
they're present by seeing these messages.

Similarly, IGMPv2 (RFC 2236) and MLDv1 (RFC 2710) require routers to
send periodic IGMP Membership Query and MLD Multicast Listener Query
messages.

IGMPv3 (RFC 3376) and MLDv2 (RFC 3810) do the same.  It seems likely
that future versions will be similar.

IGMP and MLD version compatibility depends on having periodic queries
present on the link, so if there's any functioning multicast routing
at all, these messages will be available.  Perhaps more importantly,
listing to PIM "correctly" would mean paying attention not just to the
presence of PIM, but to PIM's DR election, so that IGMP/MLD Report
messages are sent to the right router for the network to make upstream
Joins happen -- sending to the wrong LANs if you misinterpret PIM DR
selection produces the same unintended result as not paying any
attention and forwarding IGMP everywhere.

I don't think it should be necessary to tie RBridge behavior to any
particular multicast routing protocol.  In fact, I don't see an
interoperability issue here at all in simply saying that bridges
SHOULD NOT send IGMP/MLD Report messages to host-only networks, MUST
set the link-state bit appropriately, and leaving it as an
implementation matter to determine how (and if) that's done in any
given implementation.

-- 
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: Fri, 22 Jun 2007 16:18:20 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1099

> [mailto:[email-masked]] 
> Cc: [email-masked]

Thanks,
Anoop

Content-class: urn:content-classes:message
Date: Fri, 22 Jun 2007 15:43:32 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2487

Anoop 

> From: Silvano Gai [mailto:[email-masked]] 
> Cc: Caitlin Bestler; Eric Gray (LO/EUS); [email-masked]
> > From: Radia Perlman [mailto:[email-masked]]
> [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 22 Jun 2007 14:49:04 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4043

Donald,

> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]

Cheers

-- Silvano

> From: Anoop Ghanwani [mailto:[email-masked]]
> Cc: [email-masked]; Radia Perlman
> > [mailto:[email-masked]]
> > Cc: [email-masked]; Radia Perlman
> [email-masked]

To: [email-masked]
From: [email-masked]
Date: Fri, 22 Jun 2007 15:50:02 -0400
Cc: [email-masked]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-04.txt
Status: RO
Content-Length: 3401

--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-04.txt
	Pages		: 68
	Date		: 2007-6-22
	
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 endnodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design also supports VLANs, and allows forwarding tables to be
   based on RBridge destinations (rather than endnode 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-04.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-04.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-04.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-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-protocol-04.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: Fri, 22 Jun 2007 00:23:56 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 3361

Hi Anoop,

Thanks,
Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Friday, June 15, 2007 4:47 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]; Radia Perlman
Subject: RE: [rbridge] per-VLAN instances of IS-IS

> [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman

Anoop

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 17:51:15 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 18717

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: [email-masked]

 

Anoop

> > [mailto:[email-masked]] 
> > Cc: [email-masked]
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]
> > > [mailto:[email-masked]] 
> > > Cc: [email-masked]
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]
> > > > [mailto:[email-masked]]
> > > > Cc: [email-masked]
> > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > Cc: [email-masked]; Caitlin Bestler
> > > > > [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Caitlin Bestler
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of 
> Caitlin Bestler
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > [email-masked] wrote:
> > > > > > Eric,
> > > > > > 
> > > > > [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 17:30:21 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 5225

Caitlin,

Anoop 

> From: Caitlin Bestler [mailto:[email-masked]] 
> Cc: [email-masked]
> [email-masked] wrote:
> > Hi Anoop,
> > 
> > See below at @@@
> > 
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 14:59:42 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4509

Hi Caitlin,

See below at @@@

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 1:32 PM
To: Eastlake III Donald-LDE008; Anoop Ghanwani
Cc: [email-masked]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

...

@@@ Thanks,
@@@ Donald

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 10:31:33 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4223

[email-masked] wrote:
> From: Anoop Ghanwani [mailto:[email-masked]]
> Cc: [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 09:33:05 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 13586

Anoop 

> From: Silvano Gai [mailto:[email-masked]] 
> Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Anoop Ghanwani
> > Cc: [email-masked]; Radia Perlman
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Silvano Gai [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > > From: Silvano Gai [mailto:[email-masked]]
> > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > From: [email-masked]
> > > > [mailto:[email-masked]]
> > > > > > On
> > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > > > From: Eric Gray (LO/EUS) 
> [mailto:[email-masked]]
> > > > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > [email-masked]
> > [email-masked]
> > [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 07:14:18 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 13475

Anoop,

The current draft says:

I think we are fine

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]
> > [mailto:[email-masked]]
> > Cc: [email-masked]
> > From: [email-masked]
> > [mailto:[email-masked]] On
> > Behalf Of Anoop Ghanwani
> > Cc: [email-masked]; Radia Perlman
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Silvano Gai [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > > From: Silvano Gai [mailto:[email-masked]]
> > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > From: [email-masked]
> > > > [mailto:[email-masked]]
> > > > > > On
> > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > > > From: Eric Gray (LO/EUS)
[mailto:[email-masked]]
> > > > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > [email-masked]
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 07:11:40 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 3727

Anoop,

-- Silvano

> From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> Cc: Silvano Gai; [email-masked]
> > From: Radia Perlman [mailto:[email-masked]]
> > Cc: Eric Gray (LO/EUS); Silvano Gai; [email-masked]
> > >> From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > >> Cc: [email-masked]; Radia Perlman
> > >>> From: Silvano Gai [mailto:[email-masked]]
> > >>> Cc: [email-masked]; Radia Perlman

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 07:09:42 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 11280

Sure

-- Silvano

> From: Radia Perlman [mailto:[email-masked]]
> Cc: Eric Gray (LO/EUS); Silvano Gai; [email-masked]
> >> From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> >> Cc: [email-masked]; Radia Perlman
> >>> From: Silvano Gai [mailto:[email-masked]]
> >>> Cc: [email-masked]; Radia Perlman
> >>>> From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> >>>> Cc: [email-masked]; Radia Perlman
> >>>>> From: Silvano Gai [mailto:[email-masked]]
> >>>>> Cc: [email-masked]; Radia Perlman
> >>>>>> From: [email-masked]
> >>>>>>
> >>> [mailto:[email-masked]]
> >>>
> >>>>> On
> >>>>>
> >>>>>> Cc: [email-masked]; Radia Perlman
> >>>>>>> From: Anoop Ghanwani [mailto:[email-masked]]
> >>>>>>> Cc: [email-masked]; Radia Perlman
> >>>>>>>> From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> >>>>>>>> Cc: [email-masked]; Radia Perlman
> >>>>>> [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 07:09:28 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1757

Radia,

-- Silvano

> From: Radia Perlman [mailto:[email-masked]]
[email-masked]
> > we wouldn't need to worry about any of this.

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 07:07:45 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 12352

Anoop,

I agree with Donald,

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]
> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]; Radia Perlman
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > Cc: [email-masked]; Radia Perlman
> > > From: Silvano Gai [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Silvano Gai [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > > > On
> > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > [email-masked]
> [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 21 Jun 2007 08:16:02 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 11772

Anoop,

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
> Cc: [email-masked]

> > [mailto:[email-masked]] 
> > Cc: [email-masked]
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]
> > > [mailto:[email-masked]] 
> > > Cc: [email-masked]
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]
> > > > [mailto:[email-masked]]
> > > > Cc: [email-masked]
> > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > Cc: [email-masked]; Caitlin Bestler
> > > > > [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Caitlin Bestler
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of 
> Caitlin Bestler
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > [email-masked] wrote:
> > > > > > Eric,
> > > > > > 
> > > > > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 23:53:15 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 16681

Hi Anoop,

See below at @@@ 

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Wednesday, June 20, 2007 5:55 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

  Multicast router
   |
   Rb1 (DRB for the LAN)
   |

@@@   Multicast router
@@@   |

Anoop

@@@ Thanks,
@@@ Donald

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: Anoop Ghanwani [mailto:[email-masked]]
> Cc: [email-masked]
> > [mailto:[email-masked]] 
> > Cc: [email-masked]
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]
> > > [mailto:[email-masked]]
> > > Cc: [email-masked]
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]; Caitlin Bestler
> > > > [mailto:[email-masked]]
> > > > Cc: [email-masked]; Caitlin Bestler
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> > > > Cc: [email-masked]; Radia Perlman
> > > > [email-masked] wrote:
> > > > > Eric,
> > > > > 
> > > > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 14:54:53 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 9448

  Multicast router
   |
   Rb1 (DRB for the LAN)
   |

Anoop

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: Anoop Ghanwani [mailto:[email-masked]]
> Cc: [email-masked]
> > [mailto:[email-masked]] 
> > Cc: [email-masked]
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]
> > > [mailto:[email-masked]]
> > > Cc: [email-masked]
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]; Caitlin Bestler
> > > > [mailto:[email-masked]]
> > > > Cc: [email-masked]; Caitlin Bestler
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> > > > Cc: [email-masked]; Radia Perlman
> > > > [email-masked] wrote:
> > > > > Eric,
> > > > > 
> > > > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 15:46:26 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 13647

Anoop,

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
> Cc: [email-masked]
> > [mailto:[email-masked]] 
> > Cc: [email-masked]
> > From: [email-masked] 
> > [mailto:[email-masked]] On
> > Behalf Of Anoop Ghanwani
> > Cc: [email-masked]; Radia Perlman
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Silvano Gai [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > > From: Silvano Gai [mailto:[email-masked]]
> > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > From: [email-masked]
> > > > [mailto:[email-masked]]
> > > > > > On
> > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > > > From: Eric Gray (LO/EUS) 
> [mailto:[email-masked]]
> > > > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > [email-masked]
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 13:33:19 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 12209

Anoop

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: [email-masked] 
> [mailto:[email-masked]] On
> Behalf Of Anoop Ghanwani
> Cc: [email-masked]; Radia Perlman
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Cc: [email-masked]; Radia Perlman
> > > From: Silvano Gai [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Silvano Gai [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > > > On
> > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 15:21:44 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 3190

Radia, et al,

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: Radia Perlman [mailto:[email-masked]] 
> Cc: Eric Gray (LO/EUS); Silvano Gai; [email-masked]
> >> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> >> Cc: [email-masked]; Radia Perlman
> >>> From: Silvano Gai [mailto:[email-masked]]
> >>> Cc: [email-masked]; Radia Perlman
--- SNIP ---

Date: Wed, 20 Jun 2007 12:59:56 -0700
From: Radia Perlman <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 11427

Radia

Anoop Ghanwani wrote:
>> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
>> Cc: [email-masked]; Radia Perlman
>>> From: Silvano Gai [mailto:[email-masked]]
>>> Cc: [email-masked]; Radia Perlman
>>>> From: Eric Gray (LO/EUS) [mailto:[email-masked]]
>>>> Cc: [email-masked]; Radia Perlman
>>>>> From: Silvano Gai [mailto:[email-masked]]
>>>>> Cc: [email-masked]; Radia Perlman
>>>>>> From: [email-masked]
>>>>>>             
>>> [mailto:[email-masked]]
>>>       
>>>>> On
>>>>>           
>>>>>> Cc: [email-masked]; Radia Perlman
>>>>>>> From: Anoop Ghanwani [mailto:[email-masked]]
>>>>>>> Cc: [email-masked]; Radia Perlman
>>>>>>>> From: Eric Gray (LO/EUS) [mailto:[email-masked]]
>>>>>>>> Cc: [email-masked]; Radia Perlman
>>>>>> [email-masked]

Date: Wed, 20 Jun 2007 12:56:32 -0700
From: Radia Perlman <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1209

Radia

> we wouldn't need to worry about any of this.

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 15:51:06 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 5380

Anoop,

It just isn't the case that all Rbridges will be in networks that
strictly follow a division into edge and core Rbridges. Rbridges are
well suited to much more general meshes. So it takes a lot more than you
think to secure things. Although IS-IS messages can be secured by
existing IS-Is features, what's to stop some station, possibly on a
multi-access link, from injecting a TRILL data frame to pollute the
database of the egress Rbridge when it is decapsulated? There are other,
more complex scenarios.

You should also keep in mind that some people just plain would prefer to
learn via IS-IS messages than via decapsulated data, regardless of
security issues. It's partly a layer 3 versus layer 2 point of view
conflict.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 20, 2007 3:17 PM
To: Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list

Radia,

I don't see what this has to do with security.
If "secure enrolment" is a requirement, then
the edge rBridge won't transmit any frames
from an end node until it has completed secure
enrolment.  It won't learn the address, and 
nor will the egress rbridge.

I still don't get what the per-VLAN IS-IS 
instance would buy us.

Anoop

> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Wednesday, June 20, 2007 12:14 PM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> What I am referring to as "per-VLAN instance of IS-IS" consists of 
> announcing attached
> endnodes and includes only attached endnodes in a particular VLAN.
> 
> It's optional to announce, and it's optional to learn from it.
> 
> I think it would be valuable for R1 to use to proactively announce 
> endnodes that have
> explicitly enrolled with R1 through a procedure more secure 
> than simply 
> sending a data
> packet with a (claimed) source address.
> 
> Radia
> 
> 
> 
> 
> Anoop Ghanwani wrote:
> > Radia,
> >
> > Using learning at the edge Rbridges definitely
> > addresses the scaling issue for unicast.
> >
> > From your note below it's not clear if we're
> > still going to have per-VLAN instances of
> > IS-IS.  If we do, I still think we would 
> > have problems with it.
> >
> > One can always make an argument that a 
> > 802.1Q bridge doesn't realistically need
> > to support 2K or 4K or whatever number 
> > of VLANs.  However, they do support it, 
> > and there are customers out there that 
> > configure that many VLANs.
> >
> > If TRILL is even moderately successful,
> > we will likely encounter networks where
> > an rBridge needs to participate in 1000s
> > of VLANs.
> >
> > Anoop
> >
> >   
> >> From: [email-masked] 
> >> [mailto:[email-masked]] On Behalf Of Radia Perlman
> >> Sent: Friday, June 15, 2007 9:12 PM
> >> To: [email-masked]
> >> Subject: [rbridge] I got some answers from the IS-IS mailing list
> >>
> >> 1) They have deployed a variant of IS-IS, and the way they 
> >> distinguish their instances is based on having a new 
> >> multicast address. I wrongly remembered IS-IS, and thought 
> >> that PSNPs got unicast, but even those are multicast (and I 
> >> remember the reasoning at the time this was decided 100 years 
> >> ago, which was to suppress lots of routers sending the same 
> >> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
> >> from layer 3 IS-IS by having a different multicast address. 
> >> The bit in the header works too, however.
> >>
> >> 2) I checked to make sure that "0" would be OK to use as an 
> >> area address, and it is.
> >>
> >> 3) The solution I proposed to the scalability issue of having 
> >> a zillion pseudonodes on a LAN (having the DR give the same 
> >> name to all the pseudonodes that get spawned by running the 
> >> Hello protocol on a link according to each VLAN the DR 
> >> supports) works. 
> >> I was worried
> >> about nontransitive connectivity (R1, the DR, names the 
> >> pseudonode R1.1, and issues an LSP on behalf of the 
> >> pseudonode claiming to be attached to all the RBridges on the 
> >> link that can talk to R1 via any of the VLAN tags. But even 
> >> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
> >> to R1 (using VLAN Tab B) does not mean that
> >> R2 and R3
> >> can talk to each other.)
> >>
> >> Interestingly, way back when IS-IS was DECnet phase V, and we 
> >> were worried about weird hardware problems creating 
> >> nontransitive connectivity, we put in what R2 should do when 
> >> the link state database implies R2 can talk to R3 through the 
> >> pseudonode, but
> >> R2 can't really talk to R3 -- R2 sends to the DR).
> >>
> >> So we can use this solution. So does that (and learning from 
> >> data packets rather than announcing all endnodes in per-VLAN 
> >> instances of IS-IS) answer everyone's scalability concerns?
> >>
> >> Radia
> >> [email-masked]

[email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 14:48:24 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 7133

Anoop,

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
> Cc: [email-masked]
> > [mailto:[email-masked]] 
> > Cc: [email-masked]
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]
> > > [mailto:[email-masked]]
> > > Cc: [email-masked]
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]; Caitlin Bestler
> > > > [mailto:[email-masked]]
> > > > Cc: [email-masked]; Caitlin Bestler
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> > > > Cc: [email-masked]; Radia Perlman
> > > > [email-masked] wrote:
> > > > > Eric,
> > > > > 
> > > > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 15:37:15 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 11176

Anoop,

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 20, 2007 2:43 PM
To: Eric Gray (LO/EUS); Silvano Gai
Cc: [email-masked]; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

Anoop 

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: Silvano Gai [mailto:[email-masked]]
> > Cc: [email-masked]; Radia Perlman
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Silvano Gai [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: [email-masked]
> > [mailto:[email-masked]]
> > > > On
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > [email-masked]

[email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 15:22:58 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 6822

Hi Anoop,

Donald 

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Wednesday, June 20, 2007 3:14 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Anoop 

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: Anoop Ghanwani [mailto:[email-masked]]
> Cc: [email-masked]
> > [mailto:[email-masked]]
> > Cc: [email-masked]
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]; Caitlin Bestler
> > > [mailto:[email-masked]]
> > > Cc: [email-masked]; Caitlin Bestler
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> > > Cc: [email-masked]; Radia Perlman
> > > [email-masked] wrote:
> > > > Eric,
> > > > 
> > > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 12:17:15 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 4222

Radia,

I don't see what this has to do with security.
If "secure enrolment" is a requirement, then
the edge rBridge won't transmit any frames
from an end node until it has completed secure
enrolment.  It won't learn the address, and 
nor will the egress rbridge.

I still don't get what the per-VLAN IS-IS 
instance would buy us.

Anoop

> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Wednesday, June 20, 2007 12:14 PM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> What I am referring to as "per-VLAN instance of IS-IS" consists of 
> announcing attached
> endnodes and includes only attached endnodes in a particular VLAN.
> 
> It's optional to announce, and it's optional to learn from it.
> 
> I think it would be valuable for R1 to use to proactively announce 
> endnodes that have
> explicitly enrolled with R1 through a procedure more secure 
> than simply 
> sending a data
> packet with a (claimed) source address.
> 
> Radia
> 
> 
> 
> 
> Anoop Ghanwani wrote:
> > Radia,
> >
> > Using learning at the edge Rbridges definitely
> > addresses the scaling issue for unicast.
> >
> > From your note below it's not clear if we're
> > still going to have per-VLAN instances of
> > IS-IS.  If we do, I still think we would 
> > have problems with it.
> >
> > One can always make an argument that a 
> > 802.1Q bridge doesn't realistically need
> > to support 2K or 4K or whatever number 
> > of VLANs.  However, they do support it, 
> > and there are customers out there that 
> > configure that many VLANs.
> >
> > If TRILL is even moderately successful,
> > we will likely encounter networks where
> > an rBridge needs to participate in 1000s
> > of VLANs.
> >
> > Anoop
> >
> >   
> >> From: [email-masked] 
> >> [mailto:[email-masked]] On Behalf Of Radia Perlman
> >> Sent: Friday, June 15, 2007 9:12 PM
> >> To: [email-masked]
> >> Subject: [rbridge] I got some answers from the IS-IS mailing list
> >>
> >> 1) They have deployed a variant of IS-IS, and the way they 
> >> distinguish their instances is based on having a new 
> >> multicast address. I wrongly remembered IS-IS, and thought 
> >> that PSNPs got unicast, but even those are multicast (and I 
> >> remember the reasoning at the time this was decided 100 years 
> >> ago, which was to suppress lots of routers sending the same 
> >> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
> >> from layer 3 IS-IS by having a different multicast address. 
> >> The bit in the header works too, however.
> >>
> >> 2) I checked to make sure that "0" would be OK to use as an 
> >> area address, and it is.
> >>
> >> 3) The solution I proposed to the scalability issue of having 
> >> a zillion pseudonodes on a LAN (having the DR give the same 
> >> name to all the pseudonodes that get spawned by running the 
> >> Hello protocol on a link according to each VLAN the DR 
> >> supports) works. 
> >> I was worried
> >> about nontransitive connectivity (R1, the DR, names the 
> >> pseudonode R1.1, and issues an LSP on behalf of the 
> >> pseudonode claiming to be attached to all the RBridges on the 
> >> link that can talk to R1 via any of the VLAN tags. But even 
> >> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
> >> to R1 (using VLAN Tab B) does not mean that
> >> R2 and R3
> >> can talk to each other.)
> >>
> >> Interestingly, way back when IS-IS was DECnet phase V, and we 
> >> were worried about weird hardware problems creating 
> >> nontransitive connectivity, we put in what R2 should do when 
> >> the link state database implies R2 can talk to R3 through the 
> >> pseudonode, but
> >> R2 can't really talk to R3 -- R2 sends to the DR).
> >>
> >> So we can use this solution. So does that (and learning from 
> >> data packets rather than announcing all endnodes in per-VLAN 
> >> instances of IS-IS) answer everyone's scalability concerns?
> >>
> >> Radia
> >> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 12:13:49 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 5866

Anoop 

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: Anoop Ghanwani [mailto:[email-masked]]
> Cc: [email-masked]
> > [mailto:[email-masked]]
> > Cc: [email-masked]
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]; Caitlin Bestler
> > > [mailto:[email-masked]]
> > > Cc: [email-masked]; Caitlin Bestler
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> > > Cc: [email-masked]; Radia Perlman
> > > [email-masked] wrote:
> > > > Eric,
> > > > 
> > > [email-masked]

Date: Wed, 20 Jun 2007 12:14:27 -0700
From: Radia Perlman <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 3440

What I am referring to as "per-VLAN instance of IS-IS" consists of 
announcing attached
endnodes and includes only attached endnodes in a particular VLAN.

It's optional to announce, and it's optional to learn from it.

I think it would be valuable for R1 to use to proactively announce 
endnodes that have
explicitly enrolled with R1 through a procedure more secure than simply 
sending a data
packet with a (claimed) source address.

Radia

Anoop Ghanwani wrote:
> Radia,
>
> Using learning at the edge Rbridges definitely
> addresses the scaling issue for unicast.
>
> From your note below it's not clear if we're
> still going to have per-VLAN instances of
> IS-IS.  If we do, I still think we would 
> have problems with it.
>
> One can always make an argument that a 
> 802.1Q bridge doesn't realistically need
> to support 2K or 4K or whatever number 
> of VLANs.  However, they do support it, 
> and there are customers out there that 
> configure that many VLANs.
>
> If TRILL is even moderately successful,
> we will likely encounter networks where
> an rBridge needs to participate in 1000s
> of VLANs.
>
> Anoop
>
>   
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>> Sent: Friday, June 15, 2007 9:12 PM
>> To: [email-masked]
>> Subject: [rbridge] I got some answers from the IS-IS mailing list
>>
>> 1) They have deployed a variant of IS-IS, and the way they 
>> distinguish their instances is based on having a new 
>> multicast address. I wrongly remembered IS-IS, and thought 
>> that PSNPs got unicast, but even those are multicast (and I 
>> remember the reasoning at the time this was decided 100 years 
>> ago, which was to suppress lots of routers sending the same 
>> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
>> from layer 3 IS-IS by having a different multicast address. 
>> The bit in the header works too, however.
>>
>> 2) I checked to make sure that "0" would be OK to use as an 
>> area address, and it is.
>>
>> 3) The solution I proposed to the scalability issue of having 
>> a zillion pseudonodes on a LAN (having the DR give the same 
>> name to all the pseudonodes that get spawned by running the 
>> Hello protocol on a link according to each VLAN the DR 
>> supports) works. 
>> I was worried
>> about nontransitive connectivity (R1, the DR, names the 
>> pseudonode R1.1, and issues an LSP on behalf of the 
>> pseudonode claiming to be attached to all the RBridges on the 
>> link that can talk to R1 via any of the VLAN tags. But even 
>> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
>> to R1 (using VLAN Tab B) does not mean that
>> R2 and R3
>> can talk to each other.)
>>
>> Interestingly, way back when IS-IS was DECnet phase V, and we 
>> were worried about weird hardware problems creating 
>> nontransitive connectivity, we put in what R2 should do when 
>> the link state database implies R2 can talk to R3 through the 
>> pseudonode, but
>> R2 can't really talk to R3 -- R2 sends to the DR).
>>
>> So we can use this solution. So does that (and learning from 
>> data packets rather than announcing all endnodes in per-VLAN 
>> instances of IS-IS) answer everyone's scalability concerns?
>>
>> Radia
>> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 15:11:01 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4814

Hi Anoop,

Donald 

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Wednesday, June 20, 2007 2:53 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

Anoop 

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: [email-masked]; Caitlin Bestler
> > [mailto:[email-masked]] 
> > Cc: [email-masked]; Caitlin Bestler
> > From: [email-masked] 
> > [mailto:[email-masked]] On
> > Cc: [email-masked]; Radia Perlman
> > [email-masked] wrote:
> > > Eric,
> > > 
> > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 12:06:10 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2416

> From: Joe Touch [mailto:[email-masked]] 
> Cc: Eric Gray (LO/EUS); [email-masked]; Radia Perlman

Why does this matter?

Anoop

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 11:52:35 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4145

Donald,

Anoop 

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: [email-masked]; Caitlin Bestler
> > [mailto:[email-masked]] 
> > Cc: [email-masked]; Caitlin Bestler
> > From: [email-masked] 
> > [mailto:[email-masked]] On
> > Cc: [email-masked]; Radia Perlman
> > [email-masked] wrote:
> > > Eric,
> > > 
> > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 11:42:49 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 10088

Anoop 

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: Silvano Gai [mailto:[email-masked]]
> > Cc: [email-masked]; Radia Perlman
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Silvano Gai [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: [email-masked]
> > [mailto:[email-masked]]
> > > > On
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > > > Cc: [email-masked]; Radia Perlman
> > > > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > > > Cc: [email-masked]; Radia Perlman
> > > > > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 09:29:06 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 9090

Silvano,

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: Silvano Gai [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > Cc: [email-masked]; Radia Perlman
> > > From: Silvano Gai [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: [email-masked]
> [mailto:[email-masked]]
> > > On
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > > Cc: [email-masked]; Radia Perlman
> > > > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Jun 2007 00:20:13 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 6490

Hi Anoop,

See below at ### 

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 5:51 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

Donald,

By "trill core", I meant an rBridge that is connected
only to other rBridges (i.e. a device that has only 
"trill" ports).

### OK. I have the impression that, to at least some extent, people
organize bridges that way because of the nature of spanning tree.
Rbridges are much better at doing good forwarding in a more general
mesh, so their should be at least a little less reason to organize
things into "core" and "non-core". But perhaps this effect will be
small.

I think there's another notion of port state
for rBridges in the trill core - they drop
multicast frames that are received on a port
if that port is not in the tree as indicated
by the egress rBridge address.

### That seems closer to Link State than port state, which I've always
thought of as binary. In spanning tree, a port is either forwarding or
not. In Rbridges, a port is either DRB or not. The test you mention is
useful for any Rbridge that is directly connected to two other Rbridges.
The utility of the test has nothing to do with whether or not there are
end stations connected to the Rbridge, that is to say whether or not it
is "core". Furthermore, since TRILL Ethertype frames get through to an
Rbridge regardless of the "port state" in the sense that I'm using port
state, using my vocabulary, that check has nothing to do with "port
state".

                                However, this
behavior cannot be applied to IS-IS frames.

### The behavior does not make sense for "core instance" (a different
use of "core") TRILL IS-IS frames because they only ever go one hop. But
it makes perfect sense and should be applied to per VLAN instance TRILL
IS-IS frames which are multicast and, in general, multi-hop.

So while edge rBridges have DRB state, 
core rBridges need to have tree state for
all of the trees on all of their trill ports.

### Unless you do some configuration or the link medium is
point-to-point, every Rbridge port has a DRB state. As I say, any
Rbridge that is connected to two or more other Rbridges will usefully do
tree checks. So, unless your "edge Rbridges" are only singly connected
to other Rbridges, they need to do the check also.

Since unicast frames never get filtered, if the

### That's not the case anymore. The WG favored adding a check to
discard any TRILL data frames, including unicast TRILL data frames, that
arrive on a port that has no IS-IS adjacency on it.

core IS-IS instance used a special multicast
address, that would be enough for achieving 
the above function.

### Sorry, you've lost me above.

### Thanks,
### Donald

Ethertype can also be used as you point out.

Anoop

> [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 2:32 PM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Anoop,
> 
> See below at @@@
> 
> From: Anoop Ghanwani [mailto:[email-masked]]
> Sent: Monday, June 18, 2007 4:51 PM
> Cc: [email-masked]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Donald,
> 
> I think Silvano mentioned it is better to use a multicast MAC 
> address to identify IS-IS frames.
> I assume this refers to the core IS-IS instance.
> 
> @@ I may be wrong but I thought he wanted to use a different 
> multicast address for all TRILL IS-IS frames because they are 
> control messages and thus should get through when an Rbridge 
> port is "blocked" (not DRB). But TRILL data frames should get 
> through also.
> 
> Then you mentioned that we wouldn't really need to do 
> filtering in the trill core based on port state.
> 
> @@2 What is the "trill core"? If you are not DRB for some 
> port/VLAN, you need to discard incoming native data frames 
> and not emit native data frames no matter where in the campus you are.
> 
> At which point I clarified that in the trill core, when an 
> rBridge receives a frame it is required to filter multicast 
> frames if they are received on a port which is not part of 
> the tree indicated by the egress rBridge address.
> 
> @@@ Sorry, but I find you use of "filter" a little confusing. 
> Yes, that check and others are performed on multicast TRILL 
> frames when they are received by any Rbridge. I still don't 
> know what you mean by "trill core". There are no "trill core 
> Rbridges" as opposed to "peripheral trill Rbridges" or something...
> 
> Thus there is some dependence on port state even in the TRILL 
> core and the kind of frames that the rBridge would be willing 
> to accept and process from a port.
> 
> @@@ To me, "port state" for an Rbridge is whether it is 
> Designated Rbridge for a particular port/VLAN. Sure, this 
> affects whether or not it will accept or emit native data 
> frames. But this "port state" has no effect on whether it 
> will process any TRILL Ethertype frame. Nor does the "port 
> state" have any effect on whether that TRILL frame meets any 
> of the various tests such as, if it is multicast, the tree 
> test you mention.
> 
> We could use the Ethertype or the MAC address for this 
> filtering, but right now, with the MAC address for all 
> multicast frames being set to all-rbridges, it looks like the 
> only option we have is to use the Ethertype.
> That's fine too.
> 
> @@@ All frames sent to the All-Rbridges multicast address are 
> TRILL Ethertype. There are also unicast TRILL data frames. 
> How a frame is affected by port state corresponds to whether 
> or not it is TRILL Ethertype. How a frame is affected by port 
> state does not correspond with whether or not it is sent to 
> the All-Rbridges multicast address.
> The filtering on port state has nothing to do with whether a 
> frame is "TRILL IS-IS" versus "TRILL data".  I do not see how 
> port filtering would be helped by having a different TRILL 
> IS-IS multicast address.
> Whether there are one or two multicast addresses, it is still 
> the case that trying to filter based on a combination of port 
> state and multicast
> address(es) will be incorrect but filtering based on port 
> state and Ethertype will be correct.
> 
> Anoop
> 
> @@@ Donald
> 

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 20:38:58 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 7375

-- Silvano

> From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> Cc: [email-masked]; Radia Perlman
> > From: Silvano Gai [mailto:[email-masked]]
> > Cc: [email-masked]; Radia Perlman
> > > From: [email-masked]
[mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
seems
very
know
using
> > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > [email-masked]

Date: Tue, 19 Jun 2007 20:37:08 -0700
From: Joe Touch <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2326

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

Anoop Ghanwani wrote:
> =20
> Joe,
>=20
>> And, as Eric notes later, a common path between the two is=20
>> needed at L2.
>=20
> Sorry, this thread is starting to get long and=20

>> optimization, I don't consider it a design requirement. If it were, we=

>> would be talking about scalability beyond existing bridge=20
>> capabilities,
>=20

Joe

--=20

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

--------------enig5FF19A71A7494599F06547D0--

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 22:15:52 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 3529

Hi Anoop,

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2007 7:32 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]; Caitlin Bestler
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

Anoop 

> [mailto:[email-masked]] 
> Cc: [email-masked]; Caitlin Bestler
> From: [email-masked] 
> [mailto:[email-masked]] On
> Cc: [email-masked]; Radia Perlman
> [email-masked] wrote:
> > Eric,
> > 
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 16:40:49 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 938

Joe,

 

Anoop

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 16:32:29 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2798

Donald,

Anoop 

> [mailto:[email-masked]] 
> Cc: [email-masked]; Caitlin Bestler
> From: [email-masked] 
> [mailto:[email-masked]] On
> Cc: [email-masked]; Radia Perlman
> [email-masked] wrote:
> > Eric,
> > 
> [email-masked]

Date: Tue, 19 Jun 2007 14:05:16 -0700
From: Joe Touch <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1715

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

Anoop Ghanwani wrote:
> =20
>=20
>> From: Eric Gray (LO/EUS) [mailto:[email-masked]]=20
=2E..
>> In fact, I believe it is the case that most networks use IP=20
>> multicast almost exclusively for routing protocols (for which=20
>=20

Joe

--=20

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

--------------enigDAA30FA3CA606D0A59A50451--

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 17:05:01 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 3562

Hi Eric,

Donald

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2007 11:12 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

--
Eric Gray
Principal Engineer
Ericsson  

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

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 13:31:13 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Eric Gray (LO/EUS)" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2421

> From: Caitlin Bestler [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> [email-masked] wrote:
> > Eric,
> > 

Anoop

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 15:51:08 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2203

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Caitlin Bestler
Sent: Tuesday, June 19, 2007 3:16 PM
To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
Cc: [email-masked]; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 15:21:48 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Rbridge/TRILL Related Terminology
Status: RO
Content-Length: 333

Hi,

The terminology used in the different TRILL working group drafts has
been inconsistent. As a step towards fixing this, the listed authors of
the working group drafts have come up with proposed common terminology.
This is now available at
<http://www.postel.org/rbridge/terminology.html>.

Comments are welcome.

Thanks,
Donald

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 12:16:25 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eric Gray (LO/EUS)" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1212

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 11:42:12 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 5577

Eric,

Anoop 

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: Anoop Ghanwani [mailto:[email-masked]] 
> > Cc: [email-masked]; Radia Perlman
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > Cc: [email-masked]; Radia Perlman

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 11:21:53 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 8254

Eric,

Anoop

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: Silvano Gai [mailto:[email-masked]] 
> > Cc: [email-masked]; Radia Perlman
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 10:12:18 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 8717

Donald,

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] 
> Cc: [email-masked]
> From: [email-masked] 
> [mailto:[email-masked]] On
> Cc: [email-masked]; Radia Perlman
> > From: Silvano Gai [mailto:[email-masked]] 
> > Cc: [email-masked]; Radia Perlman
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > Cc: [email-masked]; Radia Perlman
> > > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 10:49:40 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 7373

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Gray (LO/EUS)
Sent: Tuesday, June 19, 2007 10:14 AM
To: Silvano Gai; Anoop Ghanwani
Cc: [email-masked]; Radia Perlman
Subject: Re: [rbridge] per-VLAN instances of IS-IS

Silvano,

--
Eric Gray
Principal Engineer
Ericsson  

> From: Silvano Gai [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Cc: [email-masked]; Radia Perlman
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > [email-masked]

[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 09:25:09 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Simplicity verses Interesting Features (was per-VLAN instances of IS-IS)
Status: RO
Content-Length: 7097

Silvano,

o	A rich feature set
o	A low price
o	An early delivery date

--
Eric Gray
Principal Engineer
Ericsson  

> From: Silvano Gai [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Cc: [email-masked]; Radia Perlman
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 09:13:34 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 6624

Silvano,

--
Eric Gray
Principal Engineer
Ericsson  

> From: Silvano Gai [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Cc: [email-masked]; Radia Perlman
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > Cc: [email-masked]; Radia Perlman
> > [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 06:12:37 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 5831

Eric,

WE ARE NOT.

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]; Radia Perlman
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]; Radia Perlman
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > Cc: [email-masked]; Radia Perlman
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 06:01:57 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eric Gray \(LO/EUS\)" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1025

> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]; Radia Perlman
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > Cc: [email-masked]; Radia Perlman

-- Silvano

Content-class: urn:content-classes:message
Date: Tue, 19 Jun 2007 07:27:25 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4838

Anoop,

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Cc: [email-masked]; Radia Perlman

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 16:07:41 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2207

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman

Anoop

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 14:51:28 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 4347

Donald,

By "trill core", I meant an rBridge that is connected
only to other rBridges (i.e. a device that has only 
"trill" ports).

I think there's another notion of port state
for rBridges in the trill core - they drop
multicast frames that are received on a port
if that port is not in the tree as indicated
by the egress rBridge address.  However, this
behavior cannot be applied to IS-IS frames.
So while edge rBridges have DRB state, 
core rBridges need to have tree state for
all of the trees on all of their trill ports.

Since unicast frames never get filtered, if the
core IS-IS instance used a special multicast
address, that would be enough for achieving 
the above function.

Ethertype can also be used as you point out.

Anoop

> [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 2:32 PM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Anoop,
> 
> See below at @@@
> 
> From: Anoop Ghanwani [mailto:[email-masked]]
> Sent: Monday, June 18, 2007 4:51 PM
> Cc: [email-masked]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Donald,
> 
> I think Silvano mentioned it is better to use a multicast MAC 
> address to identify IS-IS frames.
> I assume this refers to the core IS-IS instance.
> 
> @@ I may be wrong but I thought he wanted to use a different 
> multicast address for all TRILL IS-IS frames because they are 
> control messages and thus should get through when an Rbridge 
> port is "blocked" (not DRB). But TRILL data frames should get 
> through also.
> 
> Then you mentioned that we wouldn't really need to do 
> filtering in the trill core based on port state.
> 
> @@2 What is the "trill core"? If you are not DRB for some 
> port/VLAN, you need to discard incoming native data frames 
> and not emit native data frames no matter where in the campus you are.
> 
> At which point I clarified that in the trill core, when an 
> rBridge receives a frame it is required to filter multicast 
> frames if they are received on a port which is not part of 
> the tree indicated by the egress rBridge address.
> 
> @@@ Sorry, but I find you use of "filter" a little confusing. 
> Yes, that check and others are performed on multicast TRILL 
> frames when they are received by any Rbridge. I still don't 
> know what you mean by "trill core". There are no "trill core 
> Rbridges" as opposed to "peripheral trill Rbridges" or something...
> 
> Thus there is some dependence on port state even in the TRILL 
> core and the kind of frames that the rBridge would be willing 
> to accept and process from a port.
> 
> @@@ To me, "port state" for an Rbridge is whether it is 
> Designated Rbridge for a particular port/VLAN. Sure, this 
> affects whether or not it will accept or emit native data 
> frames. But this "port state" has no effect on whether it 
> will process any TRILL Ethertype frame. Nor does the "port 
> state" have any effect on whether that TRILL frame meets any 
> of the various tests such as, if it is multicast, the tree 
> test you mention.
> 
> We could use the Ethertype or the MAC address for this 
> filtering, but right now, with the MAC address for all 
> multicast frames being set to all-rbridges, it looks like the 
> only option we have is to use the Ethertype.
> That's fine too.
> 
> @@@ All frames sent to the All-Rbridges multicast address are 
> TRILL Ethertype. There are also unicast TRILL data frames. 
> How a frame is affected by port state corresponds to whether 
> or not it is TRILL Ethertype. How a frame is affected by port 
> state does not correspond with whether or not it is sent to 
> the All-Rbridges multicast address.
> The filtering on port state has nothing to do with whether a 
> frame is "TRILL IS-IS" versus "TRILL data".  I do not see how 
> port filtering would be helped by having a different TRILL 
> IS-IS multicast address.
> Whether there are one or two multicast addresses, it is still 
> the case that trying to filter based on a combination of port 
> state and multicast
> address(es) will be incorrect but filtering based on port 
> state and Ethertype will be correct.
> 
> Anoop
> 
> @@@ Donald
> 

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 14:40:47 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 2874

Radia,

Using learning at the edge Rbridges definitely
addresses the scaling issue for unicast.

>From your note below it's not clear if we're
still going to have per-VLAN instances of
IS-IS.  If we do, I still think we would 
have problems with it.

One can always make an argument that a 
802.1Q bridge doesn't realistically need
to support 2K or 4K or whatever number 
of VLANs.  However, they do support it, 
and there are customers out there that 
configure that many VLANs.

If TRILL is even moderately successful,
we will likely encounter networks where
an rBridge needs to participate in 1000s
of VLANs.

Anoop

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Friday, June 15, 2007 9:12 PM
> To: [email-masked]
> Subject: [rbridge] I got some answers from the IS-IS mailing list
> 
> 1) They have deployed a variant of IS-IS, and the way they 
> distinguish their instances is based on having a new 
> multicast address. I wrongly remembered IS-IS, and thought 
> that PSNPs got unicast, but even those are multicast (and I 
> remember the reasoning at the time this was decided 100 years 
> ago, which was to suppress lots of routers sending the same 
> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
> from layer 3 IS-IS by having a different multicast address. 
> The bit in the header works too, however.
> 
> 2) I checked to make sure that "0" would be OK to use as an 
> area address, and it is.
> 
> 3) The solution I proposed to the scalability issue of having 
> a zillion pseudonodes on a LAN (having the DR give the same 
> name to all the pseudonodes that get spawned by running the 
> Hello protocol on a link according to each VLAN the DR 
> supports) works. 
> I was worried
> about nontransitive connectivity (R1, the DR, names the 
> pseudonode R1.1, and issues an LSP on behalf of the 
> pseudonode claiming to be attached to all the RBridges on the 
> link that can talk to R1 via any of the VLAN tags. But even 
> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
> to R1 (using VLAN Tab B) does not mean that
> R2 and R3
> can talk to each other.)
> 
> Interestingly, way back when IS-IS was DECnet phase V, and we 
> were worried about weird hardware problems creating 
> nontransitive connectivity, we put in what R2 should do when 
> the link state database implies R2 can talk to R3 through the 
> pseudonode, but
> R2 can't really talk to R3 -- R2 sends to the DR).
> 
> So we can use this solution. So does that (and learning from 
> data packets rather than announcing all endnodes in per-VLAN 
> instances of IS-IS) answer everyone's scalability concerns?
> 
> Radia
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 17:31:36 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 3148

Anoop,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 4:51 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

Donald,

I think Silvano mentioned it is better to use
a multicast MAC address to identify IS-IS frames.
I assume this refers to the core IS-IS instance.

@@ I may be wrong but I thought he wanted to use a different multicast
address for all TRILL IS-IS frames because they are control messages and
thus should get through when an Rbridge port is "blocked" (not DRB). But
TRILL data frames should get through also.

Then you mentioned that we wouldn't really need
to do filtering in the trill core based on 
port state.

@@2 What is the "trill core"? If you are not DRB for some port/VLAN, you
need to discard incoming native data frames and not emit native data
frames no matter where in the campus you are.

At which point I clarified that in the trill 
core, when an rBridge receives a frame 
it is required to filter multicast frames 
if they are received on a port which is not
part of the tree indicated by the egress
rBridge address.

@@@ Sorry, but I find you use of "filter" a little confusing. Yes, that
check and others are performed on multicast TRILL frames when they are
received by any Rbridge. I still don't know what you mean by "trill
core". There are no "trill core Rbridges" as opposed to "peripheral
trill Rbridges" or something...

Thus there is some dependence on port state
even in the TRILL core and the kind of frames
that the rBridge would be willing to accept
and process from a port.

@@@ To me, "port state" for an Rbridge is whether it is Designated
Rbridge for a particular port/VLAN. Sure, this affects whether or not it
will accept or emit native data frames. But this "port state" has no
effect on whether it will process any TRILL Ethertype frame. Nor does
the "port state" have any effect on whether that TRILL frame meets any
of the various tests such as, if it is multicast, the tree test you
mention.

We could use the Ethertype or the MAC address
for this filtering, but right now, with the 
MAC address for all multicast frames being 
set to all-rbridges, it looks like the only
option we have is to use the Ethertype.
That's fine too.

@@@ All frames sent to the All-Rbridges multicast address are TRILL
Ethertype. There are also unicast TRILL data frames. How a frame is
affected by port state corresponds to whether or not it is TRILL
Ethertype. How a frame is affected by port state does not correspond
with whether or not it is sent to the All-Rbridges multicast address.
The filtering on port state has nothing to do with whether a frame is
"TRILL IS-IS" versus "TRILL data".  I do not see how port filtering
would be helped by having a different TRILL IS-IS multicast address.
Whether there are one or two multicast addresses, it is still the case
that trying to filter based on a combination of port state and multicast
address(es) will be incorrect but filtering based on port state and
Ethertype will be correct.

Anoop

@@@ Donald

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 13:51:10 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 10161

Donald,

I think Silvano mentioned it is better to use
a multicast MAC address to identify IS-IS frames.
I assume this refers to the core IS-IS instance.

Then you mentioned that we wouldn't really need
to do filtering in the trill core based on 
port state.

At which point I clarified that in the trill 
core, when an rBridge receives a frame 
it is required to filter multicast frames 
if they are received on a port which is not
part of the tree indicated by the egress
rBridge address.

Thus there is some dependence on port state
even in the TRILL core and the kind of frames
that the rBridge would be willing to accept
and process from a port.

We could use the Ethertype or the MAC address
for this filtering, but right now, with the 
MAC address for all multicast frames being 
set to all-rbridges, it looks like the only
option we have is to use the Ethertype.
That's fine too.

Anoop

> [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 12:36 PM
> To: Anoop Ghanwani
> Cc: [email-masked]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Anoop,
> 
> Sure, but I was interpreting "blocking" to be the sort of things that
> 802.1 bridge ports do in any state other than the Forwarding 
> state. That
> is, data doesn't go through and is not processed (except possibly to
> learn addresses). However, when blocked, 802.1 bridges still receive,
> process, and send BPDUs. (I'm ignoring all the various possible
> "port-to-port" things like 802.1AB and 802.1AE etc.)
> 
> The corresponding thing for Rbridges is to not be the 
> Designated Rbridge
> (DRB) on a port/VLAN pair. When you are not the DRB, native 
> data doesn't
> go through and is not processed. However, any TRILL Ethertype frame is
> fine to receive, process, and, if appropriate, send. That 
> processing may
> cause the frame to be discarded, as you point out below, but I just
> don't think of that as the same thing as throwing away a frame as soon
> as you notice that it is a native data frame received from a port/VLAN
> where you are not DRB or not emitting the native data frame inside a
> TRILL data frame you have received onto any port/VLAN pair because you
> are not DRB.
> 
> Maybe we are just arguing about what words to use.
> 
> In any case, my point was that in connection with "blocking" as I mean
> it above, I don't see any difference between TRILL IS-IS frames and
> TRILL data frames. So there is no particular reason to have two
> multicast addresses. In fact, depending just on the multicast 
> address to
> by-pass blocking isn't right, because unicast TRILL data 
> frames need to
> get through and, if there were any unicast TRILL IS-IS frames, they
> would need to get through also. Looking for the TRILL Ethertype seems
> like the best way to determine if a frame gets through "blocking".
> 
> Donald
> 
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 2:10 PM
> To: Eastlake III Donald-LDE008; Silvano Gai; [email-masked]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> Donald,
> 
> Even in the TRILL network, you have to block frames 
> with the all-rbridges address if the come in on a 
> port that is not part of the tree identified by the 
> egress rbridge address in the frame.
> 
> Anoop 
> 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Sunday, June 17, 2007 8:57 PM
> > To: Silvano Gai; [email-masked]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > I've got no problem with using destination address to bypass 
> > blocked port state but the only thing you need to block are 
> > native data frames.
> > Once a frame has been admitted by a DRB and converted into a 
> > TRILL data frame, there is no reason to port block it. So 
> > anything to the All Rbridges multicast address is fine.
> > 
> > Donald 
> > 
> > From: Silvano Gai [mailto:[email-masked]]
> > Sent: Sunday, June 17, 2007 1:22 AM
> > To: Eastlake III Donald-LDE008; [email-masked]
> > Subject: RE: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > I disagree; current bridges distinguish control frames 
> > (BPDUs, CDP, LLDP, GARP, etc) on reserved MAC addresses.
> > 
> > Remember that these control frames need to bypass the blocked 
> > port state (due to ST or DRB election). 
> > 
> > Today we have port logic that checks a set of registers for 
> > MAC addresses of frames that need to bypass the port state. 
> > 
> > It is much more difficult to parse a frame to understand if 
> > applying or not the port state.
> > 
> > -- Silvano
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Sent: Saturday, June 16, 2007 8:11 PM
> > > To: [email-masked]
> > > Subject: Re: [rbridge] I got some answers from the IS-IS 
> > mailing list
> > > 
> > > While I think that multicast addresses are cheap, so we could
> > certainly
> > > get two, I don't see any advantage to having two: presumably 
> > > "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast 
> addresses.
> > You
> > > definitely want different multicast addresses if you have 
> different 
> > > listeners, but in this case all Rbridges would have to list 
> > for both 
> > > multicast addresses.
> > > 
> > > Both TRILL Data and TRILL IS-IS messages have the same 
> structure of 
> > > TRILL header and it seems easier to figure things out from 
> > that header 
> > > rather than having to keep track of one extra bit from 
> > earlier in the 
> > > frame from the multicast address.
> > > 
> > > The variant of IS-IS that the IS-IS working group deployed 
> > did use a 
> > > different multicast address from the one used for level one IS-IS 
> > > routers, the multicast address "All-Level-1-ISs". We are 
> > already using
> > a
> > > different multicast address from that, just like they 
> did, by using
> > the
> > > multicast address "All-Rbridges".
> > > 
> > > Thanks,
> > > Donald
> > > 
> > > PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
> > which
> > > isn't relevant as the TRILL usage of IS-IS is Level 1.
> > > 
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Behalf Of Silvano Gai
> > > Sent: Saturday, June 16, 2007 11:24 AM
> > > To: Radia Perlman; [email-masked]
> > > Subject: Re: [rbridge] I got some answers from the IS-IS 
> > mailing list
> > > 
> > > 
> > > If this is the case I will use the multicast address to 
> distinguish 
> > > TRILL ISIS not an extra bit in the header.
> > > 
> > > -- Silvano
> > > 
> > > > From: [email-masked] 
> > [mailto:[email-masked]]
> > > On
> > > > Behalf Of Radia Perlman
> > > > Sent: Friday, June 15, 2007 9:12 PM
> > > > To: [email-masked]
> > > > Subject: [rbridge] I got some answers from the IS-IS 
> mailing list
> > > >
> > > > 1) They have deployed a variant of IS-IS, and the way they
> > distinguish
> > > > their instances
> > > > is based on having a new multicast address. I wrongly remembered
> > > IS-IS,
> > > > and thought that
> > > > PSNPs got unicast, but even those are multicast (and I 
> > remember the 
> > > > reasoning at the time this was decided 100 years ago, 
> > which was to 
> > > > suppress lots of routers sending the same PSNP). So, 
> for encoding 
> > > > TRILL IS-IS, it can be differentiated
> > > from
> > > > layer 3 IS-IS
> > > > by having a different multicast address. The bit in the 
> > header works 
> > > > too, however.
> > > >
> > > > 2) I checked to make sure that "0" would be OK to use 
> as an area 
> > > > address, and it is.
> > > >
> > > > 3) The solution I proposed to the scalability issue of having a
> > > zillion
> > > > pseudonodes on a LAN
> > > > (having the DR give the same name to all the 
> pseudonodes that get 
> > > > spawned by running the Hello protocol on a link 
> according to each 
> > > > VLAN the DR supports)
> > > works.
> > > > I was worried
> > > > about nontransitive connectivity (R1, the DR, names the 
> pseudonode
> > > R1.1,
> > > > and issues
> > > > an LSP on behalf of the pseudonode claiming to be 
> attached to all
> > the
> > > > RBridges on the
> > > > link that can talk to R1 via any of the VLAN tags. But 
> even though
> > R2
> > > > can talk to R1 (using
> > > > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) 
> does not mean
> > > that
> > > > R2 and R3
> > > > can talk to each other.)
> > > >
> > > > Interestingly, way back when IS-IS was DECnet phase V, 
> > and we were 
> > > > worried about weird hardware problems creating nontransitive 
> > > > connectivity, we put
> > in
> > > > what R2 should
> > > > do when the link state database implies R2 can talk to 
> R3 through
> > the
> > > > pseudonode, but
> > > > R2 can't really talk to R3 -- R2 sends to the DR).
> > > >
> > > > So we can use this solution. So does that (and learning 
> from data 
> > > > packets rather than announcing all endnodes in per-VLAN 
> > instances of 
> > > > IS-IS) answer
> > > everyone's
> > > > scalability concerns?
> > > >
> > > > Radia
> > > > [email-masked]
> > > [email-masked]
> > > [email-masked]
> > [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 15:36:25 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 8450

Anoop,

Sure, but I was interpreting "blocking" to be the sort of things that
802.1 bridge ports do in any state other than the Forwarding state. That
is, data doesn't go through and is not processed (except possibly to
learn addresses). However, when blocked, 802.1 bridges still receive,
process, and send BPDUs. (I'm ignoring all the various possible
"port-to-port" things like 802.1AB and 802.1AE etc.)

The corresponding thing for Rbridges is to not be the Designated Rbridge
(DRB) on a port/VLAN pair. When you are not the DRB, native data doesn't
go through and is not processed. However, any TRILL Ethertype frame is
fine to receive, process, and, if appropriate, send. That processing may
cause the frame to be discarded, as you point out below, but I just
don't think of that as the same thing as throwing away a frame as soon
as you notice that it is a native data frame received from a port/VLAN
where you are not DRB or not emitting the native data frame inside a
TRILL data frame you have received onto any port/VLAN pair because you
are not DRB.

Maybe we are just arguing about what words to use.

In any case, my point was that in connection with "blocking" as I mean
it above, I don't see any difference between TRILL IS-IS frames and
TRILL data frames. So there is no particular reason to have two
multicast addresses. In fact, depending just on the multicast address to
by-pass blocking isn't right, because unicast TRILL data frames need to
get through and, if there were any unicast TRILL IS-IS frames, they
would need to get through also. Looking for the TRILL Ethertype seems
like the best way to determine if a frame gets through "blocking".

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 2:10 PM
To: Eastlake III Donald-LDE008; Silvano Gai; [email-masked]
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

Donald,

Even in the TRILL network, you have to block frames 
with the all-rbridges address if the come in on a 
port that is not part of the tree identified by the 
egress rbridge address in the frame.

Anoop 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Sunday, June 17, 2007 8:57 PM
> To: Silvano Gai; [email-masked]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> I've got no problem with using destination address to bypass 
> blocked port state but the only thing you need to block are 
> native data frames.
> Once a frame has been admitted by a DRB and converted into a 
> TRILL data frame, there is no reason to port block it. So 
> anything to the All Rbridges multicast address is fine.
> 
> Donald 
> 
> From: Silvano Gai [mailto:[email-masked]]
> Sent: Sunday, June 17, 2007 1:22 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> I disagree; current bridges distinguish control frames 
> (BPDUs, CDP, LLDP, GARP, etc) on reserved MAC addresses.
> 
> Remember that these control frames need to bypass the blocked 
> port state (due to ST or DRB election). 
> 
> Today we have port logic that checks a set of registers for 
> MAC addresses of frames that need to bypass the port state. 
> 
> It is much more difficult to parse a frame to understand if 
> applying or not the port state.
> 
> -- Silvano
> 
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Sent: Saturday, June 16, 2007 8:11 PM
> > To: [email-masked]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > While I think that multicast addresses are cheap, so we could
> certainly
> > get two, I don't see any advantage to having two: presumably 
> > "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses.
> You
> > definitely want different multicast addresses if you have different 
> > listeners, but in this case all Rbridges would have to list 
> for both 
> > multicast addresses.
> > 
> > Both TRILL Data and TRILL IS-IS messages have the same structure of 
> > TRILL header and it seems easier to figure things out from 
> that header 
> > rather than having to keep track of one extra bit from 
> earlier in the 
> > frame from the multicast address.
> > 
> > The variant of IS-IS that the IS-IS working group deployed 
> did use a 
> > different multicast address from the one used for level one IS-IS 
> > routers, the multicast address "All-Level-1-ISs". We are 
> already using
> a
> > different multicast address from that, just like they did, by using
> the
> > multicast address "All-Rbridges".
> > 
> > Thanks,
> > Donald
> > 
> > PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
> which
> > isn't relevant as the TRILL usage of IS-IS is Level 1.
> > 
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Silvano Gai
> > Sent: Saturday, June 16, 2007 11:24 AM
> > To: Radia Perlman; [email-masked]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > 
> > If this is the case I will use the multicast address to distinguish 
> > TRILL ISIS not an extra bit in the header.
> > 
> > -- Silvano
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Behalf Of Radia Perlman
> > > Sent: Friday, June 15, 2007 9:12 PM
> > > To: [email-masked]
> > > Subject: [rbridge] I got some answers from the IS-IS mailing list
> > >
> > > 1) They have deployed a variant of IS-IS, and the way they
> distinguish
> > > their instances
> > > is based on having a new multicast address. I wrongly remembered
> > IS-IS,
> > > and thought that
> > > PSNPs got unicast, but even those are multicast (and I 
> remember the 
> > > reasoning at the time this was decided 100 years ago, 
> which was to 
> > > suppress lots of routers sending the same PSNP). So, for encoding 
> > > TRILL IS-IS, it can be differentiated
> > from
> > > layer 3 IS-IS
> > > by having a different multicast address. The bit in the 
> header works 
> > > too, however.
> > >
> > > 2) I checked to make sure that "0" would be OK to use as an area 
> > > address, and it is.
> > >
> > > 3) The solution I proposed to the scalability issue of having a
> > zillion
> > > pseudonodes on a LAN
> > > (having the DR give the same name to all the pseudonodes that get 
> > > spawned by running the Hello protocol on a link according to each 
> > > VLAN the DR supports)
> > works.
> > > I was worried
> > > about nontransitive connectivity (R1, the DR, names the pseudonode
> > R1.1,
> > > and issues
> > > an LSP on behalf of the pseudonode claiming to be attached to all
> the
> > > RBridges on the
> > > link that can talk to R1 via any of the VLAN tags. But even though
> R2
> > > can talk to R1 (using
> > > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
> > that
> > > R2 and R3
> > > can talk to each other.)
> > >
> > > Interestingly, way back when IS-IS was DECnet phase V, 
> and we were 
> > > worried about weird hardware problems creating nontransitive 
> > > connectivity, we put
> in
> > > what R2 should
> > > do when the link state database implies R2 can talk to R3 through
> the
> > > pseudonode, but
> > > R2 can't really talk to R3 -- R2 sends to the DR).
> > >
> > > So we can use this solution. So does that (and learning from data 
> > > packets rather than announcing all endnodes in per-VLAN 
> instances of 
> > > IS-IS) answer
> > everyone's
> > > scalability concerns?
> > >
> > > Radia
> > > [email-masked]
> > [email-masked]
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 13:42:41 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4137

Anoop,

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Cc: [email-masked]; Radia Perlman

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 11:36:25 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1744

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman

And I just don't get it.

Anoop

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 11:17:49 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2468

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman

 

Anoop

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 11:09:47 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Silvano Gai" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 6528

Donald,

Even in the TRILL network, you have to block frames 
with the all-rbridges address if the come in on a 
port that is not part of the tree identified by the 
egress rbridge address in the frame.

Anoop 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Sunday, June 17, 2007 8:57 PM
> To: Silvano Gai; [email-masked]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> I've got not problem with using destination address to bypass 
> blocked port state but the only thing you need to block are 
> native data frames.
> Once a frame has been admitted by a DRB and converted into a 
> TRILL data frame, there is no reason to port block it. So 
> anything to the All Rbridges multicast address is fine.
> 
> Donald 
> 
> From: Silvano Gai [mailto:[email-masked]]
> Sent: Sunday, June 17, 2007 1:22 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
> 
> I disagree; current bridges distinguish control frames 
> (BPDUs, CDP, LLDP, GARP, etc) on reserved MAC addresses.
> 
> Remember that these control frames need to bypass the blocked 
> port state (due to ST or DRB election). 
> 
> Today we have port logic that checks a set of registers for 
> MAC addresses of frames that need to bypass the port state. 
> 
> It is much more difficult to parse a frame to understand if 
> applying or not the port state.
> 
> -- Silvano
> 
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Sent: Saturday, June 16, 2007 8:11 PM
> > To: [email-masked]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > While I think that multicast addresses are cheap, so we could
> certainly
> > get two, I don't see any advantage to having two: presumably 
> > "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses.
> You
> > definitely want different multicast addresses if you have different 
> > listeners, but in this case all Rbridges would have to list 
> for both 
> > multicast addresses.
> > 
> > Both TRILL Data and TRILL IS-IS messages have the same structure of 
> > TRILL header and it seems easier to figure things out from 
> that header 
> > rather than having to keep track of one extra bit from 
> earlier in the 
> > frame from the multicast address.
> > 
> > The variant of IS-IS that the IS-IS working group deployed 
> did use a 
> > different multicast address from the one used for level one IS-IS 
> > routers, the multicast address "All-Level-1-ISs". We are 
> already using
> a
> > different multicast address from that, just like they did, by using
> the
> > multicast address "All-Rbridges".
> > 
> > Thanks,
> > Donald
> > 
> > PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
> which
> > isn't relevant as the TRILL usage of IS-IS is Level 1.
> > 
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Silvano Gai
> > Sent: Saturday, June 16, 2007 11:24 AM
> > To: Radia Perlman; [email-masked]
> > Subject: Re: [rbridge] I got some answers from the IS-IS 
> mailing list
> > 
> > 
> > If this is the case I will use the multicast address to distinguish 
> > TRILL ISIS not an extra bit in the header.
> > 
> > -- Silvano
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > Behalf Of Radia Perlman
> > > Sent: Friday, June 15, 2007 9:12 PM
> > > To: [email-masked]
> > > Subject: [rbridge] I got some answers from the IS-IS mailing list
> > >
> > > 1) They have deployed a variant of IS-IS, and the way they
> distinguish
> > > their instances
> > > is based on having a new multicast address. I wrongly remembered
> > IS-IS,
> > > and thought that
> > > PSNPs got unicast, but even those are multicast (and I 
> remember the 
> > > reasoning at the time this was decided 100 years ago, 
> which was to 
> > > suppress lots of routers sending the same PSNP). So, for encoding 
> > > TRILL IS-IS, it can be differentiated
> > from
> > > layer 3 IS-IS
> > > by having a different multicast address. The bit in the 
> header works 
> > > too, however.
> > >
> > > 2) I checked to make sure that "0" would be OK to use as an area 
> > > address, and it is.
> > >
> > > 3) The solution I proposed to the scalability issue of having a
> > zillion
> > > pseudonodes on a LAN
> > > (having the DR give the same name to all the pseudonodes that get 
> > > spawned by running the Hello protocol on a link according to each 
> > > VLAN the DR supports)
> > works.
> > > I was worried
> > > about nontransitive connectivity (R1, the DR, names the pseudonode
> > R1.1,
> > > and issues
> > > an LSP on behalf of the pseudonode claiming to be attached to all
> the
> > > RBridges on the
> > > link that can talk to R1 via any of the VLAN tags. But even though
> R2
> > > can talk to R1 (using
> > > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
> > that
> > > R2 and R3
> > > can talk to each other.)
> > >
> > > Interestingly, way back when IS-IS was DECnet phase V, 
> and we were 
> > > worried about weird hardware problems creating nontransitive 
> > > connectivity, we put
> in
> > > what R2 should
> > > do when the link state database implies R2 can talk to R3 through
> the
> > > pseudonode, but
> > > R2 can't really talk to R3 -- R2 sends to the DR).
> > >
> > > So we can use this solution. So does that (and learning from data 
> > > packets rather than announcing all endnodes in per-VLAN 
> instances of 
> > > IS-IS) answer
> > everyone's
> > > scalability concerns?
> > >
> > > Radia
> > > [email-masked]
> > [email-masked]
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 12:52:14 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] IS-IS Consensus Call, Routing Requirements Document
Status: RO
Content-Length: 1242

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

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 08:59:01 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2264

Anoop,

--
Eric Gray
Principal Engineer
Ericsson  

Prove it. 

--
E

Content-class: urn:content-classes:message
Date: Mon, 18 Jun 2007 08:35:27 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 3207

Anoop,

	Please see below...

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Cc: [email-masked]; Radia Perlman

--
E

Content-class: urn:content-classes:message
Date: Sun, 17 Jun 2007 23:57:13 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 5486

I've got not problem with using destination address to bypass blocked
port state but the only thing you need to block are native data frames.
Once a frame has been admitted by a DRB and converted into a TRILL data
frame, there is no reason to port block it. So anything to the All
Rbridges multicast address is fine.

Donald 

-----Original Message-----
From: Silvano Gai [mailto:[email-masked]] 
Sent: Sunday, June 17, 2007 1:22 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

I disagree; current bridges distinguish control frames (BPDUs, CDP,
LLDP, GARP, etc) on reserved MAC addresses.

Remember that these control frames need to bypass the blocked port state
(due to ST or DRB election). 

Today we have port logic that checks a set of registers for MAC
addresses of frames that need to bypass the port state. 

It is much more difficult to parse a frame to understand if applying or
not the port state.

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Sent: Saturday, June 16, 2007 8:11 PM
> To: [email-masked]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> While I think that multicast addresses are cheap, so we could
certainly
> get two, I don't see any advantage to having two: presumably
> "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses.
You
> definitely want different multicast addresses if you have different
> listeners, but in this case all Rbridges would have to list for both
> multicast addresses.
> 
> Both TRILL Data and TRILL IS-IS messages have the same structure of
> TRILL header and it seems easier to figure things out from that header
> rather than having to keep track of one extra bit from earlier in the
> frame from the multicast address.
> 
> The variant of IS-IS that the IS-IS working group deployed did use a
> different multicast address from the one used for level one IS-IS
> routers, the multicast address "All-Level-1-ISs". We are already using
a
> different multicast address from that, just like they did, by using
the
> multicast address "All-Rbridges".
> 
> Thanks,
> Donald
> 
> PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
which
> isn't relevant as the TRILL usage of IS-IS is Level 1.
> 
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Silvano Gai
> Sent: Saturday, June 16, 2007 11:24 AM
> To: Radia Perlman; [email-masked]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> 
> If this is the case I will use the multicast address to distinguish
> TRILL ISIS not an extra bit in the header.
> 
> -- Silvano
> 
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Radia Perlman
> > Sent: Friday, June 15, 2007 9:12 PM
> > To: [email-masked]
> > Subject: [rbridge] I got some answers from the IS-IS mailing list
> >
> > 1) They have deployed a variant of IS-IS, and the way they
distinguish
> > their instances
> > is based on having a new multicast address. I wrongly remembered
> IS-IS,
> > and thought that
> > PSNPs got unicast, but even those are multicast (and I remember the
> > reasoning at the
> > time this was decided 100 years ago, which was to suppress lots of
> > routers sending the
> > same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
> from
> > layer 3 IS-IS
> > by having a different multicast address. The bit in the header works
> > too, however.
> >
> > 2) I checked to make sure that "0" would be OK to use as an area
> > address, and it is.
> >
> > 3) The solution I proposed to the scalability issue of having a
> zillion
> > pseudonodes on a LAN
> > (having the DR give the same name to all the pseudonodes that get
> > spawned by running the
> > Hello protocol on a link according to each VLAN the DR supports)
> works.
> > I was worried
> > about nontransitive connectivity (R1, the DR, names the pseudonode
> R1.1,
> > and issues
> > an LSP on behalf of the pseudonode claiming to be attached to all
the
> > RBridges on the
> > link that can talk to R1 via any of the VLAN tags. But even though
R2
> > can talk to R1 (using
> > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
> that
> > R2 and R3
> > can talk to each other.)
> >
> > Interestingly, way back when IS-IS was DECnet phase V, and we were
> > worried about
> > weird hardware problems creating nontransitive connectivity, we put
in
> > what R2 should
> > do when the link state database implies R2 can talk to R3 through
the
> > pseudonode, but
> > R2 can't really talk to R3 -- R2 sends to the DR).
> >
> > So we can use this solution. So does that (and learning from data
> > packets rather than
> > announcing all endnodes in per-VLAN instances of IS-IS) answer
> everyone's
> > scalability concerns?
> >
> > Radia
> > [email-masked]
> [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Sat, 16 Jun 2007 22:21:47 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 4925

I disagree; current bridges distinguish control frames (BPDUs, CDP,
LLDP, GARP, etc) on reserved MAC addresses.

Remember that these control frames need to bypass the blocked port state
(due to ST or DRB election). 

Today we have port logic that checks a set of registers for MAC
addresses of frames that need to bypass the port state. 

It is much more difficult to parse a frame to understand if applying or
not the port state.

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Sent: Saturday, June 16, 2007 8:11 PM
> To: [email-masked]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> While I think that multicast addresses are cheap, so we could
certainly
> get two, I don't see any advantage to having two: presumably
> "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses.
You
> definitely want different multicast addresses if you have different
> listeners, but in this case all Rbridges would have to list for both
> multicast addresses.
> 
> Both TRILL Data and TRILL IS-IS messages have the same structure of
> TRILL header and it seems easier to figure things out from that header
> rather than having to keep track of one extra bit from earlier in the
> frame from the multicast address.
> 
> The variant of IS-IS that the IS-IS working group deployed did use a
> different multicast address from the one used for level one IS-IS
> routers, the multicast address "All-Level-1-ISs". We are already using
a
> different multicast address from that, just like they did, by using
the
> multicast address "All-Rbridges".
> 
> Thanks,
> Donald
> 
> PS: There is also an "All-Level-2-ISs" multicast address in IS-IS
which
> isn't relevant as the TRILL usage of IS-IS is Level 1.
> 
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Silvano Gai
> Sent: Saturday, June 16, 2007 11:24 AM
> To: Radia Perlman; [email-masked]
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> 
> If this is the case I will use the multicast address to distinguish
> TRILL ISIS not an extra bit in the header.
> 
> -- Silvano
> 
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Radia Perlman
> > Sent: Friday, June 15, 2007 9:12 PM
> > To: [email-masked]
> > Subject: [rbridge] I got some answers from the IS-IS mailing list
> >
> > 1) They have deployed a variant of IS-IS, and the way they
distinguish
> > their instances
> > is based on having a new multicast address. I wrongly remembered
> IS-IS,
> > and thought that
> > PSNPs got unicast, but even those are multicast (and I remember the
> > reasoning at the
> > time this was decided 100 years ago, which was to suppress lots of
> > routers sending the
> > same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
> from
> > layer 3 IS-IS
> > by having a different multicast address. The bit in the header works
> > too, however.
> >
> > 2) I checked to make sure that "0" would be OK to use as an area
> > address, and it is.
> >
> > 3) The solution I proposed to the scalability issue of having a
> zillion
> > pseudonodes on a LAN
> > (having the DR give the same name to all the pseudonodes that get
> > spawned by running the
> > Hello protocol on a link according to each VLAN the DR supports)
> works.
> > I was worried
> > about nontransitive connectivity (R1, the DR, names the pseudonode
> R1.1,
> > and issues
> > an LSP on behalf of the pseudonode claiming to be attached to all
the
> > RBridges on the
> > link that can talk to R1 via any of the VLAN tags. But even though
R2
> > can talk to R1 (using
> > VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
> that
> > R2 and R3
> > can talk to each other.)
> >
> > Interestingly, way back when IS-IS was DECnet phase V, and we were
> > worried about
> > weird hardware problems creating nontransitive connectivity, we put
in
> > what R2 should
> > do when the link state database implies R2 can talk to R3 through
the
> > pseudonode, but
> > R2 can't really talk to R3 -- R2 sends to the DR).
> >
> > So we can use this solution. So does that (and learning from data
> > packets rather than
> > announcing all endnodes in per-VLAN instances of IS-IS) answer
> everyone's
> > scalability concerns?
> >
> > Radia
> > [email-masked]
> [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Sat, 16 Jun 2007 23:11:02 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 3840

While I think that multicast addresses are cheap, so we could certainly
get two, I don't see any advantage to having two: presumably
"All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses. You
definitely want different multicast addresses if you have different
listeners, but in this case all Rbridges would have to list for both
multicast addresses.

Both TRILL Data and TRILL IS-IS messages have the same structure of
TRILL header and it seems easier to figure things out from that header
rather than having to keep track of one extra bit from earlier in the
frame from the multicast address.

The variant of IS-IS that the IS-IS working group deployed did use a
different multicast address from the one used for level one IS-IS
routers, the multicast address "All-Level-1-ISs". We are already using a
different multicast address from that, just like they did, by using the
multicast address "All-Rbridges".

Thanks,
Donald

PS: There is also an "All-Level-2-ISs" multicast address in IS-IS which
isn't relevant as the TRILL usage of IS-IS is Level 1.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Silvano Gai
Sent: Saturday, June 16, 2007 11:24 AM
To: Radia Perlman; [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list

If this is the case I will use the multicast address to distinguish
TRILL ISIS not an extra bit in the header.

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Friday, June 15, 2007 9:12 PM
> To: [email-masked]
> Subject: [rbridge] I got some answers from the IS-IS mailing list
> 
> 1) They have deployed a variant of IS-IS, and the way they distinguish
> their instances
> is based on having a new multicast address. I wrongly remembered
IS-IS,
> and thought that
> PSNPs got unicast, but even those are multicast (and I remember the
> reasoning at the
> time this was decided 100 years ago, which was to suppress lots of
> routers sending the
> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
from
> layer 3 IS-IS
> by having a different multicast address. The bit in the header works
> too, however.
> 
> 2) I checked to make sure that "0" would be OK to use as an area
> address, and it is.
> 
> 3) The solution I proposed to the scalability issue of having a
zillion
> pseudonodes on a LAN
> (having the DR give the same name to all the pseudonodes that get
> spawned by running the
> Hello protocol on a link according to each VLAN the DR supports)
works.
> I was worried
> about nontransitive connectivity (R1, the DR, names the pseudonode
R1.1,
> and issues
> an LSP on behalf of the pseudonode claiming to be attached to all the
> RBridges on the
> link that can talk to R1 via any of the VLAN tags. But even though R2
> can talk to R1 (using
> VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
that
> R2 and R3
> can talk to each other.)
> 
> Interestingly, way back when IS-IS was DECnet phase V, and we were
> worried about
> weird hardware problems creating nontransitive connectivity, we put in
> what R2 should
> do when the link state database implies R2 can talk to R3 through the
> pseudonode, but
> R2 can't really talk to R3 -- R2 sends to the DR).
> 
> So we can use this solution. So does that (and learning from data
> packets rather than
> announcing all endnodes in per-VLAN instances of IS-IS) answer
everyone's
> scalability concerns?
> [email-masked]

[email-masked]

Date: Sat, 16 Jun 2007 19:35:07 -0700
From: Radia Perlman <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 1164

Oh definitely. We need both (putting 0 into the area address, and either 
a multicast
address or a bit in the header).

Radia

Dinesh G Dutt wrote:
> Hi Radia,
>
> Radia Perlman wrote:
>> 1) They have deployed a variant of IS-IS, and the way they 
>> distinguish their instances
>> is based on having a new multicast address. I wrongly remembered 
>> IS-IS, and thought that
>> PSNPs got unicast, but even those are multicast (and I remember the 
>> reasoning at the
>> time this was decided 100 years ago, which was to suppress lots of 
>> routers sending the
>> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
>> from layer 3 IS-IS
>> by having a different multicast address. The bit in the header works 
>> too, however.
>>
>> 2) I checked to make sure that "0" would be OK to use as an area 
>> address, and it is.
>>   
> My reading of what they recommended is that we use a different 
> multicast address since it was not guaranteed that all implementations 
> would support a 0 in the area address.
>
> Here is a pointer to the email from Mike Shand: 
> http://www1.ietf.org/mail-archive/web/isis-wg/current/msg01746.html
>
> Dinesh
>

Date: Sat, 16 Jun 2007 10:10:22 -0700
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 1121

Hi Radia,

Radia Perlman wrote:
> 1) They have deployed a variant of IS-IS, and the way they distinguish 
> their instances
> is based on having a new multicast address. I wrongly remembered IS-IS, 
> and thought that
> PSNPs got unicast, but even those are multicast (and I remember the 
> reasoning at the
> time this was decided 100 years ago, which was to suppress lots of 
> routers sending the
> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated from 
> layer 3 IS-IS
> by having a different multicast address. The bit in the header works 
> too, however.
>
> 2) I checked to make sure that "0" would be OK to use as an area 
> address, and it is.
>   
My reading of what they recommended is that we use a different multicast 
address since it was not guaranteed that all implementations would 
support a 0 in the area address.

Here is a pointer to the email from Mike Shand: 
http://www1.ietf.org/mail-archive/web/isis-wg/current/msg01746.html

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: Sat, 16 Jun 2007 08:24:12 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 2364

If this is the case I will use the multicast address to distinguish
TRILL ISIS not an extra bit in the header.

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Friday, June 15, 2007 9:12 PM
> To: [email-masked]
> Subject: [rbridge] I got some answers from the IS-IS mailing list
> 
> 1) They have deployed a variant of IS-IS, and the way they distinguish
> their instances
> is based on having a new multicast address. I wrongly remembered
IS-IS,
> and thought that
> PSNPs got unicast, but even those are multicast (and I remember the
> reasoning at the
> time this was decided 100 years ago, which was to suppress lots of
> routers sending the
> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
from
> layer 3 IS-IS
> by having a different multicast address. The bit in the header works
> too, however.
> 
> 2) I checked to make sure that "0" would be OK to use as an area
> address, and it is.
> 
> 3) The solution I proposed to the scalability issue of having a
zillion
> pseudonodes on a LAN
> (having the DR give the same name to all the pseudonodes that get
> spawned by running the
> Hello protocol on a link according to each VLAN the DR supports)
works.
> I was worried
> about nontransitive connectivity (R1, the DR, names the pseudonode
R1.1,
> and issues
> an LSP on behalf of the pseudonode claiming to be attached to all the
> RBridges on the
> link that can talk to R1 via any of the VLAN tags. But even though R2
> can talk to R1 (using
> VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean
that
> R2 and R3
> can talk to each other.)
> 
> Interestingly, way back when IS-IS was DECnet phase V, and we were
> worried about
> weird hardware problems creating nontransitive connectivity, we put in
> what R2 should
> do when the link state database implies R2 can talk to R3 through the
> pseudonode, but
> R2 can't really talk to R3 -- R2 sends to the DR).
> 
> So we can use this solution. So does that (and learning from data
> packets rather than
> announcing all endnodes in per-VLAN instances of IS-IS) answer
everyone's
> scalability concerns?
> [email-masked]

Date: Fri, 15 Jun 2007 21:11:31 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] I got some answers from the IS-IS mailing list
Status: RO
Content-Length: 1754

1) They have deployed a variant of IS-IS, and the way they distinguish 
their instances
is based on having a new multicast address. I wrongly remembered IS-IS, 
and thought that
PSNPs got unicast, but even those are multicast (and I remember the 
reasoning at the
time this was decided 100 years ago, which was to suppress lots of 
routers sending the
same PSNP). So, for encoding TRILL IS-IS, it can be differentiated from 
layer 3 IS-IS
by having a different multicast address. The bit in the header works 
too, however.

2) I checked to make sure that "0" would be OK to use as an area 
address, and it is.

3) The solution I proposed to the scalability issue of having a zillion 
pseudonodes on a LAN
(having the DR give the same name to all the pseudonodes that get 
spawned by running the
Hello protocol on a link according to each VLAN the DR supports) works. 
I was worried
about nontransitive connectivity (R1, the DR, names the pseudonode R1.1, 
and issues
an LSP on behalf of the pseudonode claiming to be attached to all the 
RBridges on the
link that can talk to R1 via any of the VLAN tags. But even though R2 
can talk to R1 (using
VLAN tag A) and R3 can talk to R1 (using VLAN Tab B) does not mean that 
R2 and R3
can talk to each other.)

Interestingly, way back when IS-IS was DECnet phase V, and we were 
worried about
weird hardware problems creating nontransitive connectivity, we put in 
what R2 should
do when the link state database implies R2 can talk to R3 through the 
pseudonode, but
R2 can't really talk to R3 -- R2 sends to the DR).

So we can use this solution. So does that (and learning from data 
packets rather than
announcing all endnodes in per-VLAN instances of IS-IS) answer everyone's
scalability concerns?

Radia

Content-class: urn:content-classes:message
Date: Fri, 15 Jun 2007 13:51:48 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1856

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman

Anoop

Content-class: urn:content-classes:message
Date: Fri, 15 Jun 2007 13:46:36 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 762

> [mailto:[email-masked]] 
> Cc: [email-masked]; Radia Perlman

Anoop

Content-class: urn:content-classes:message
Date: Fri, 15 Jun 2007 15:10:09 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1857

Donald,

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Cc: [email-masked]; Radia Perlman
> From: [email-masked] 
> [mailto:[email-masked]] On
> Behalf Of Anoop Ghanwani
> Cc: [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 15 Jun 2007 15:04:46 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4496

Anoop,

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: Eric Gray (LO/EUS); [email-masked]
> > From: Radia Perlman [mailto:[email-masked]] 
> > Cc: Eric Gray (LO/EUS); [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 15 Jun 2007 15:40:36 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 750

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 15, 2007 2:15 PM
To: Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS

...

Anoop

Content-class: urn:content-classes:message
Date: Fri, 15 Jun 2007 11:14:43 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2961

> From: Radia Perlman [mailto:[email-masked]] 
> Cc: Eric Gray (LO/EUS); [email-masked]

Anoop

Date: Fri, 15 Jun 2007 04:43:57 -0700
From: Joe Touch <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL header format, understanding the pros and cons (was "multicastpruning")
Status: RO
Content-Length: 4093

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

I'll add some info in the spirit of summarizing the reasons for a
decision already made.

Radia Perlman wrote:
=2E..
> Moving the VLAN tag into the TRILL header (as a fixed field
> rather than an option) makes the packet 2 bytes longer when there is no=
=20
> inner VLAN,
> but makes the packet 2 bytes shorter when there was an inner VLAN=20
> (because the
> VLAN can be deleted from the inner frame).

I disagree that TRILL operations should ever modify their payload. Even
when done only at the ingress/egress, and only as an optimization, this
means that separate code is needed to parse headers inside vs. outside,
rather than just adding code to parse TRILL headers. Such code would be
used by trace debuggers, as well as by TRILL devices supporting other
fields that "should have been copied" into the TRILL header had we known
about them.

Any existing ethernet header that can be parsed now (or in the future)
in its original place can be parsed by TRILL using a fixed offset.
There's zero utility in copying or moving data - it presents
opportunities for more bugs and complexity.

> Signalling that the packet is an IGMP reply (so should be pruned to onl=
y=20
> send to
> links with IP multicast routers) can be done with a single bit in the=20
> TRILL header.

The same issue applies here.

=2E..
> So the cost of moving these into the TRILL header are 2 bytes +1 bit, a=
nd
> actually the 2 byte cost is only a cost when there was no VLAN tag in=20
> the inner header.
>=20
> I'd think the advantages of doing so would be

I disagree that the following are agreed...

> a) easier for transit RBridges to make a forwarding decision

It is irrelevant where a header value is so long as it is in a fixed
location. There could be minor efficiencies in grabbing data in large
chunks, but such chunks are just as likely to grab both TRILL and the
inner ethernet headers in their entirety.

> b) in a sense more "architecturally pure" since the transit RBridges=20
> would not
> need to look at anything more than the TRILL header

This is a fallacy. It is not architecturally "pure" to move a header;
it's still a field of the inner header, and moving it - if anything -
adds pollutes the architecture because it gives the misimpression that
TRILL is making decisions on only _its_ information.

> c) if 802 invented a new kind of tag, since tags are not TLV encoded,=20
> transit RBridges
> would not need to be upgraded to understand the new tag in order to fin=
d the
> fields in the inner packet.

If 802 invented a new kind of tag, it's possible it wouldn't fit in the
current TRILL header, which means everything in TRILL would need to be
updated anyway.

Also, I don't believe there will be devices that support only transit or
only ingress/egress; ethernet plug-and-play compatibility means that
every device ought to support both functions (albeit with different
efficiency or scale in different devices).

> I'm not saying we have to change the TRILL format...I just want to=20
> carefully understand
> the pros and cons. What arguments have I missed? (either more arguments=
=20
> for moving
> everything necessary for forwarding into the TRILL header, or against i=
t).

I think you missed the pros, and omitted the cons (most of which you
posed as pros anyway).

Joe

--=20

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

--------------enig310861EA015486A0B1180507--

Date: Thu, 14 Jun 2007 22:30:42 -0700
From: Radia Perlman <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] TRILL header format, understanding the pros and cons (was "multicastpruning")
Status: RO
Content-Length: 6737

Sorry, Silvano,

I do believe it is worthwhile to calmly list all points for and against 
something even if the
issue has been decided. I understand the problem of a committee being 
like the
proverbial donkey starving because it is equidistant between two bales 
of hay and
can't decide which one to go to. And I understand also how at some 
point, unless
something is really broken, it's better to just go off in the original 
direction rather than
never converging.

However, I believe it is also always a useful exercise to summarize all 
the arguments
in one place. And sometimes when doing so, it might make sense to change 
the decision.

So...the way the TRILL header is now, intermediate RBridges have to find the
inner frame and look for:
a) VLAN tag (to do VLAN pruning)
b) the original destination address (in case it's an IP multicast, in 
order to do
IP multicast pruning)
c) the IP protocol type (for IGMP), and parsing enough of the IGMP 
message to
know that this is an IGMP reply (in order for it to get sent only to 
links with IP multicast
routers)

Moving the VLAN tag into the TRILL header (as a fixed field
rather than an option) makes the packet 2 bytes longer when there is no 
inner VLAN,
but makes the packet 2 bytes shorter when there was an inner VLAN 
(because the
VLAN can be deleted from the inner frame).

Signalling that the packet is an IGMP reply (so should be pruned to only 
send to
links with IP multicast routers) can be done with a single bit in the 
TRILL header.

Moving the original destination address into the TRILL header could 
theoretically
be done without adding to the length of the packet, by merely 
considering the
first 6 bytes of the packet to be the final 6 bytes of the TRILL header.

So the cost of moving these into the TRILL header are 2 bytes +1 bit, and
actually the 2 byte cost is only a cost when there was no VLAN tag in 
the inner header.

I'd think the advantages of doing so would be
a) easier for transit RBridges to make a forwarding decision
b) in a sense more "architecturally pure" since the transit RBridges 
would not
need to look at anything more than the TRILL header
c) if 802 invented a new kind of tag, since tags are not TLV encoded, 
transit RBridges
would not need to be upgraded to understand the new tag in order to find the
fields in the inner packet.

I'm not saying we have to change the TRILL format...I just want to 
carefully understand
the pros and cons. What arguments have I missed? (either more arguments 
for moving
everything necessary for forwarding into the TRILL header, or against it).

Thanks,

Radia

Silvano Gai wrote:
> Folks,
>
> We had a detailed discussion on the header format which included all the
> points that Radia list below. We had a strong consensus on one solution.
> The WG chairs confirmed this consensus on the mailing list.
>
> There is no new piece of information. We have not discovered anything
> that was not known at the time of the consensus. I propose we stick with
> the current header format.
>
> If we continue to change things we will never converge and the frame
> format needs to be stable ASAP.
>
> If we reopen the frame format discussion, then I want to reopen nickname
> vs address ;-) :-) :-) ;-)
>
> -- Silvano
>
>   
>> From: [email-masked] [mailto:[email-masked]]
>>     
> On
>   
>> Behalf Of Radia Perlman
>> Sent: Thursday, June 07, 2007 1:29 PM
>> Cc: [email-masked]
>> Subject: Re: [rbridge] multicast pruning in TRILL
>>
>> (revisiting the issue of moving whatever is necessary for transit
>> bridges to look at
>> for pruning of multicasts (VLAN tag and destination multicast address)
>> to the portion of the frame outside the tunnel, i.e., either the TRILL
>> header or
>> the outer header)
>>
>> The mailing list archives are daunting, even though I've been trying
>>     
> to
>   
>> follow it all along.
>> I'd like to see the arguments both sides of this issue summarized
>>     
> rather
>   
>> than
>> pointing people at the mailing list -- just now I tried to review the
>> mailing list
>> on this issue and got discouraged. It never hurts to summarize the
>> issues again.
>>
>> I'll start by writing down concisely what I do remember, and perhaps
>> people can
>> concisely add other arguments:
>>
>> a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer
>> bits total (since you
>> don't need the Ethertype) to include it as a tag in the inner header),
>> it's easier to find since
>> transit RBridges don't need to find the inner header,
>> the TRILL header is still fixed length.  Minuses: It takes up room
>>     
> even
>   
>> when there is
>> no VLAN tag in the inner header
>>
>> b) moving VLAN tag to TRILL header as an option: Pluses: it only takes
>> up room
>> when there is a VLAN tag in the inner frame. Minus: it makes the TRILL
>> header
>> variable length
>>
>> c) moving the inner multicast address (for IP multicast pruning) into
>> the TRILL header: I don't think this was discussed. But it would
>>     
> clearly
>   
>> have to be done as an option in the TRILL
>> header since we wouldn't want to make space for it in the TRILL header
>> on unicast
>> packets, so it would make the TRILL header variable length
>>
>> d) copying the inner multicast address (for IP multicast pruning) into
>> the *outer* Ethernet
>> header. I don't think this was discussed at all on the mailing list. I
>> assume that it wouldn't
>> confuse non-RBridge devices listening to that multicast address that
>> might hear the
>> packet because the Ethertype would be TRILL, so they'd (hopefully)
>>     
> drop
>   
>> it without
>> getting confused.
>>
>> Whatever I've missed, can someone add to this?
>>
>> Thanks,
>>
>> Radia
>>
>>
>> Eastlake III Donald-LDE008 wrote:
>>     
>>> @@@ Indeed, for precisely the reason you give, it was and remains my
>>> strong personal opinion that the VLAN-tag information should be part
>>>       
> of
>   
>>> the TRILL Header where it would be at least 14 bytes earlier and you
>>> would also save the 2 bytes of tag Ethertype. It contains priority
>>>       
> as
>   
>>> well as the VLAN ID info.
>>>
>>> @@@ However, the working group appears to be of the opinion that the
>>> VLAN-tag should be inserted inside the inner frame with an
>>>       
> Ethertype.
>   
>>> See the May mail here which includes arguments on the other side of
>>>       
> the
>   
>>> issue:
>>> http://www.postel.org/pipermail/rbridge/2007-May/thread.html.
>>>
>>>
>>>       
>> [email-masked]

Date: Thu, 14 Jun 2007 21:53:53 -0700
From: Radia Perlman <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1721

Radia

Content-class: urn:content-classes:message
Date: Mon, 11 Jun 2007 12:24:04 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 15062

Anoop,

	Two things:

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: [email-masked]
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Cc: [email-masked]
> > > From: Anoop Ghanwani [mailto:[email-masked]]
> > > Cc: [email-masked]
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > >

Content-class: urn:content-classes:message
Date: Mon, 11 Jun 2007 09:58:12 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 13037

Eric,

Thanks,
Anoop 

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Cc: [email-masked]
> > From: Anoop Ghanwani [mailto:[email-masked]]
> > Cc: [email-masked]
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > >

Content-class: urn:content-classes:message
Date: Mon, 11 Jun 2007 09:50:49 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1494

Content-class: urn:content-classes:message
Date: Mon, 11 Jun 2007 09:32:10 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 958

I agree with Joe.
In general we should use only MAY or MUST, not SHOULD

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Joe Touch
> Sent: Monday, June 11, 2007 8:48 AM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] multicast pruning in TRILL
> 
> 
> 
> Radia Perlman wrote:
> > Re: Is multicast pruning a MAY or MUST:
> >
> > I'm not sure there's been enough opinion voiced to have a consensus
on
> this.
> > I'd be happy with MAY or SHOULD, since it really it just an
> optimization.
> 
> IMO, optimizations should be expressed as MAY.
> 
> To say "SHOULD" is to say that implementations that do not implement
the
> optimization should have a good reason for not doing so. I don't think
> the presumption should be tilted that way.
> 
> Joe
> 
> --

Content-class: urn:content-classes:message
Date: Mon, 11 Jun 2007 10:55:29 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 11775

Anoop,

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Cc: [email-masked]
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> >

See: 

for more information.

> Anoop

Date: Mon, 11 Jun 2007 08:48:23 -0700
From: Joe Touch <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 1276

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

Radia Perlman wrote:
> Re: Is multicast pruning a MAY or MUST:
>=20
> I'm not sure there's been enough opinion voiced to have a consensus on =
this.
> I'd be happy with MAY or SHOULD, since it really it just an optimizatio=
n.

IMO, optimizations should be expressed as MAY.

To say "SHOULD" is to say that implementations that do not implement the
optimization should have a good reason for not doing so. I don't think
the presumption should be tilted that way.

Joe

--=20

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

--------------enig379256FFDAB9F816DF083044--

Date: Sat, 09 Jun 2007 21:02:11 -0700
From: [email-masked]
To: Silvano Gai <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 5128

Expanding on what Silvano said, and agreeing with what I think Anoop was pointing out.

It was an error in the previous version of the spec to say that the IP multicast group membership
information would be announced in the per-VLAN instance, since the core guys would need
to look at membership in VLAN A, even if they are not in VLAN A, in order to prune multicasts
in VLAN A inside the core. So IP group membership is moving to the core instance.

And for now the per-VLAN instance (which would have announced endnode membership) is
going away, though I'd like it to be optional in the future, for letting an RBridge announce
endnodes that have actually enrolled at layer 2, since it's a more secure binding than
just having an endnode transmit a data packet with the source address. But it will be a MUST
to learn from data packets, and, if we define a per-VLAN instance of IS-IS for announcing endnode
memberships, it would be a SHOULD to announce endnodes that have actually enrolled, with
perhaps a metric for how securely they've enrolled (whether it was cryptographic authentication, e.g.).
And it would be a SHOULD to learn from such reports, and a SHOULD to have the IS-IS announcement
be believed when there is a conflict between what is learned from decapsulating a data packet vs
what is announced in IS-IS.

Radia
----- Original Message -----
From: Silvano Gai <[email-masked]>
Date: Saturday, June 9, 2007 10:01 am
Subject: Re: [rbridge] per-VLAN instances of IS-IS

> > From: [email-masked] [[email-masked]]
> On
> > Behalf Of Anoop Ghanwani
> > Cc: [email-masked]
> > > From: [email-masked]
> > > [[email-masked]] On
> > > Behalf Of Anoop Ghanwani
> > > To: [email-masked]
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Sat, 9 Jun 2007 20:33:26 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 3858

See below at ###

-----Original Message-----
From: Silvano Gai [mailto:[email-masked]] 
Sent: Saturday, June 09, 2007 1:02 PM
To: Anoop Ghanwani; Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Anoop,

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]
> > From: [email-masked]
> > [mailto:[email-masked]] On
> > Behalf Of Anoop Ghanwani
> > To: [email-masked]

### Donald

> [email-masked]

Content-class: urn:content-classes:message
Date: Sat, 9 Jun 2007 20:21:58 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 1052

The consensus determination referred to is here:
http://www.postel.org/pipermail/rbridge/2007-May/002226.html
which refers to the option 1 here:
http://www.postel.org/pipermail/rbridge/2007-May/002078.html

Donald

-----Original Message-----
From: Silvano Gai [mailto:[email-masked]] 
Sent: Saturday, June 09, 2007 11:04 AM
To: Radia Perlman; Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] multicast pruning in TRILL

Folks,

We had a detailed discussion on the header format which included all the
points that Radia list below. We had a strong consensus on one solution.
The WG chairs confirmed this consensus on the mailing list.

There is no new piece of information. We have not discovered anything
that was not known at the time of the consensus. I propose we stick with
the current header format.

If we continue to change things we will never converge and the frame
format needs to be stable ASAP.

If we reopen the frame format discussion, then I want to reopen nickname
vs address ;-) :-) :-) ;-)

-- Silvano

Content-class: urn:content-classes:message
Date: Sat, 9 Jun 2007 10:01:35 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 3290

Anoop,

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Cc: [email-masked]
> > From: [email-masked]
> > [mailto:[email-masked]] On
> > Behalf Of Anoop Ghanwani
> > To: [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Sat, 9 Jun 2007 08:06:31 -0700
From: "Silvano Gai" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1760

Anoop,

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> To: [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Sat, 9 Jun 2007 08:03:38 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 3834

Folks,

We had a detailed discussion on the header format which included all the
points that Radia list below. We had a strong consensus on one solution.
The WG chairs confirmed this consensus on the mailing list.

There is no new piece of information. We have not discovered anything
that was not known at the time of the consensus. I propose we stick with
the current header format.

If we continue to change things we will never converge and the frame
format needs to be stable ASAP.

If we reopen the frame format discussion, then I want to reopen nickname
vs address ;-) :-) :-) ;-)

-- Silvano

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Thursday, June 07, 2007 1:29 PM
> Cc: [email-masked]
> Subject: Re: [rbridge] multicast pruning in TRILL
> 
> (revisiting the issue of moving whatever is necessary for transit
> bridges to look at
> for pruning of multicasts (VLAN tag and destination multicast address)
> to the portion of the frame outside the tunnel, i.e., either the TRILL
> header or
> the outer header)
> 
> The mailing list archives are daunting, even though I've been trying
to
> follow it all along.
> I'd like to see the arguments both sides of this issue summarized
rather
> than
> pointing people at the mailing list -- just now I tried to review the
> mailing list
> on this issue and got discouraged. It never hurts to summarize the
> issues again.
> 
> I'll start by writing down concisely what I do remember, and perhaps
> people can
> concisely add other arguments:
> 
> a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer
> bits total (since you
> don't need the Ethertype) to include it as a tag in the inner header),
> it's easier to find since
> transit RBridges don't need to find the inner header,
> the TRILL header is still fixed length.  Minuses: It takes up room
even
> when there is
> no VLAN tag in the inner header
> 
> b) moving VLAN tag to TRILL header as an option: Pluses: it only takes
> up room
> when there is a VLAN tag in the inner frame. Minus: it makes the TRILL
> header
> variable length
> 
> c) moving the inner multicast address (for IP multicast pruning) into
> the TRILL header: I don't think this was discussed. But it would
clearly
> have to be done as an option in the TRILL
> header since we wouldn't want to make space for it in the TRILL header
> on unicast
> packets, so it would make the TRILL header variable length
> 
> d) copying the inner multicast address (for IP multicast pruning) into
> the *outer* Ethernet
> header. I don't think this was discussed at all on the mailing list. I
> assume that it wouldn't
> confuse non-RBridge devices listening to that multicast address that
> might hear the
> packet because the Ethertype would be TRILL, so they'd (hopefully)
drop
> it without
> getting confused.
> 
> Whatever I've missed, can someone add to this?
> 
> Thanks,
> 
> Radia
> 
> 
> Eastlake III Donald-LDE008 wrote:
> >
> > @@@ Indeed, for precisely the reason you give, it was and remains my
> > strong personal opinion that the VLAN-tag information should be part
of
> > the TRILL Header where it would be at least 14 bytes earlier and you
> > would also save the 2 bytes of tag Ethertype. It contains priority
as
> > well as the VLAN ID info.
> >
> > @@@ However, the working group appears to be of the opinion that the
> > VLAN-tag should be inserted inside the inner frame with an
Ethertype.
> > See the May mail here which includes arguments on the other side of
the
> > issue:
> > http://www.postel.org/pipermail/rbridge/2007-May/thread.html.
> >
> >
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2007 18:25:08 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2619

> From: [email-masked] 
> [mailto:[email-masked]] On
> Behalf Of Anoop Ghanwani
> To: [email-masked]
..

Thanks,
Anoop

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2007 18:15:04 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 6176

> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
>
...

           D
           |
v1 -- A -- B -- C -- v1
           | 
           E

A-E are RBridges.

 

Anoop

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2007 13:47:53 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 2744

Hi Anoop,

See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Friday, June 08, 2007 12:59 PM
To: [email-masked]
Subject: [rbridge] per-VLAN instances of IS-IS

Anoop

@@@ Thanks,
@@@ Donald

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2007 12:41:22 -0500
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 4603

Anoop,

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
> To: [email-masked]

 

 

> [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2007 09:59:21 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] per-VLAN instances of IS-IS
Status: RO
Content-Length: 1102

Anoop

Content-class: urn:content-classes:message
Date: Thu, 7 Jun 2007 16:28:58 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 4162

Hi,

See below at @@@ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Caitlin Bestler
Sent: Thursday, June 07, 2007 2:00 PM
To: Radia Perlman; Anoop Ghanwani
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL

Caitlin Bestler <[email-masked]> wrote:

I can see some value in moving RBridge-relevant fields earlier
in the overall packet, but I would want to avoid any and all
risks of doing so in a way where the semantics of those fields
did not remain fully under the IEEE and/or that would require
product to implement the same logic twice. Leaving them where
they are totally avoids such risks.

@@@ The proposal would be to put a two byte field into the TRILL Header
that would be specified by reference to the IEEE standard. The 16 bits
would be used to control distribution tree pruning, priority queuing,
etc., inside an Rbridge in exactly the same way, regardless of whether
those 2 bytes are a field in the TRILL Header or are inserted inside the
encapsulated frame after an Ethertype. 

@@@ more below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Thursday, June 07, 2007 2:15 PM
To: Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL

Radia,

> Re: Is multicast pruning a MAY or MUST:
> 
> I'm not sure there's been enough opinion voiced to have a 
> consensus on this.
> I'd be happy with MAY or SHOULD, since it really it just an 
> optimization.

Actually, I think I agree with Donald's response.  Even
if it were a MAY/SHOULD, no one would ever want to build
a system that didn't do pruning.  It would be way too
inefficient.

> On the other part of what you said -- namely that you have to 
> dig deeper 
> into
> the frame for multicast and VLAN pruning --- it was suggested, but
> not extensively discussed, to move the inner VLAN into the 
> TRILL header
> so that VLAN pruning would not need to be done by finding the 
> inner frame.
> 
> This would still require an RBridge in the core to look 
> inside to find the
> inner frame in order to look at the multicast address.
> 
> There are two ways I can think of to avoid this:
> a) move the multicast address into the inner frame, perhaps 
> as an option in
> the TRILL header
> b) use the multicast address in the inner frame as the destination 
> address in the outer
> header.

Moving the multicast address to the outer
header doesn't really help in terms of 
implementation since the look ups required
stay the same.  It might help from an 
architecture standpoint, but even that
I don't really see.

@@@ Seems to me that moving an inner multicast or broadcast MAC address
to the outer Ethernet header could, on shared links, cause additional
interrupts to end stations from frames they would ultimately have to
discard (and probably shouldn't be handling anyway) because they don't
understand the TRILL Ethertype... 

Essentially, we need both the inner VLAN and the
MAC DA to make their way into the TRILL header
so that they can be consulted for forwarding.
But doing so would unnecessarily add to the 
frame overhead.

@@@ As far as I can see, moving the VLAN tag info to the TRILL Header
reduces frame overhead. There would no longer be a need to insert an
Ethertype and the VLAN tag info into the encapsulated frame. Thus you
would save two bytes.

@@@ On the other hand, since the inner MAC DA is right after the TRILL
Header, whether it is part of the TRILL Header or not just depends on
where you draw the boundaries of that header :-)

@@@ Thanks,
@@@ Donald

Perhaps what is defined is as good as it
gets.  :-)

Somewhat off topic -
I now recall why the statement about "problems 
with learning when doing multipathing" was put
into the TRILL routing requirements document.
In the early days of TRILL, IIRC RBridges 
were going to just forward unicast frames without
an encapsulation header.  In that case, if
one had RBridges and regular bridges intermixed
in a network and had ECMP running in the RBridges,
we'd run into problems with address learning.

Anoop

Date: Thu, 07 Jun 2007 13:28:59 -0700
From: Radia Perlman <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 2675

(revisiting the issue of moving whatever is necessary for transit 
bridges to look at
for pruning of multicasts (VLAN tag and destination multicast address)
to the portion of the frame outside the tunnel, i.e., either the TRILL 
header or
the outer header)

The mailing list archives are daunting, even though I've been trying to 
follow it all along.
I'd like to see the arguments both sides of this issue summarized rather 
than
pointing people at the mailing list -- just now I tried to review the 
mailing list
on this issue and got discouraged. It never hurts to summarize the 
issues again.

I'll start by writing down concisely what I do remember, and perhaps 
people can
concisely add other arguments:

a) moving VLAN tag to TRILL header always: Pluses: it takes up fewer 
bits total (since you
don't need the Ethertype) to include it as a tag in the inner header), 
it's easier to find since
transit RBridges don't need to find the inner header,
the TRILL header is still fixed length.  Minuses: It takes up room even 
when there is
no VLAN tag in the inner header

b) moving VLAN tag to TRILL header as an option: Pluses: it only takes 
up room
when there is a VLAN tag in the inner frame. Minus: it makes the TRILL 
header
variable length

c) moving the inner multicast address (for IP multicast pruning) into 
the TRILL header: I don't think this was discussed. But it would clearly 
have to be done as an option in the TRILL
header since we wouldn't want to make space for it in the TRILL header 
on unicast
packets, so it would make the TRILL header variable length

d) copying the inner multicast address (for IP multicast pruning) into 
the *outer* Ethernet
header. I don't think this was discussed at all on the mailing list. I 
assume that it wouldn't
confuse non-RBridge devices listening to that multicast address that 
might hear the
packet because the Ethertype would be TRILL, so they'd (hopefully) drop 
it without
getting confused.

Whatever I've missed, can someone add to this?

Thanks,

Radia

Eastlake III Donald-LDE008 wrote:
>
> @@@ Indeed, for precisely the reason you give, it was and remains my
> strong personal opinion that the VLAN-tag information should be part of
> the TRILL Header where it would be at least 14 bytes earlier and you
> would also save the 2 bytes of tag Ethertype. It contains priority as
> well as the VLAN ID info.
>
> @@@ However, the working group appears to be of the opinion that the
> VLAN-tag should be inserted inside the inner frame with an Ethertype.
> See the May mail here which includes arguments on the other side of the
> issue:
> http://www.postel.org/pipermail/rbridge/2007-May/thread.html.
>
>   

Content-class: urn:content-classes:message
Date: Thu, 7 Jun 2007 11:34:40 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Erik Nordmark" <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] TRILL at the next IETF
Status: RO
Content-Length: 252

Chairs,

The preliminary agenda shows the TRILL meeting split over two days.

https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=
69

This is really inconvenient.
Can we have the two slots in the same day?

Thank You

-- Silvano

Content-class: urn:content-classes:message
Date: Thu, 7 Jun 2007 11:15:28 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 2039

Radia,

> Re: Is multicast pruning a MAY or MUST:
> 
> I'm not sure there's been enough opinion voiced to have a 
> consensus on this.
> I'd be happy with MAY or SHOULD, since it really it just an 
> optimization.

Actually, I think I agree with Donald's response.  Even
if it were a MAY/SHOULD, no one would ever want to build
a system that didn't do pruning.  It would be way too
inefficient.

> On the other part of what you said -- namely that you have to 
> dig deeper 
> into
> the frame for multicast and VLAN pruning --- it was suggested, but
> not extensively discussed, to move the inner VLAN into the 
> TRILL header
> so that VLAN pruning would not need to be done by finding the 
> inner frame.
> 
> This would still require an RBridge in the core to look 
> inside to find the
> inner frame in order to look at the multicast address.
> 
> There are two ways I can think of to avoid this:
> a) move the multicast address into the inner frame, perhaps 
> as an option in
> the TRILL header
> b) use the multicast address in the inner frame as the destination 
> address in the outer
> header.

Moving the multicast address to the outer
header doesn't really help in terms of 
implementation since the look ups required
stay the same.  It might help from an 
architecture standpoint, but even that
I don't really see.

Essentially, we need both the inner VLAN and the
MAC DA to make their way into the TRILL header
so that they can be consulted for forwarding.
But doing so would unnecessarily add to the 
frame overhead.

Perhaps what is defined is as good as it
gets.  :-)

Somewhat off topic -
I now recall why the statement about "problems 
with learning when doing multipathing" was put
into the TRILL routing requirements document.
In the early days of TRILL, IIRC RBridges 
were going to just forward unicast frames without
an encapsulation header.  In that case, if
one had RBridges and regular bridges intermixed
in a network and had ECMP running in the RBridges,
we'd run into problems with address learning.

Anoop

Content-class: urn:content-classes:message
Date: Thu, 7 Jun 2007 11:00:27 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 1477

[email-masked] wrote:
> Re: Is multicast pruning a MAY or MUST:
> 
> I'm not sure there's been enough opinion voiced to have a consensus
> on this. I'd be happy with MAY or SHOULD, since it really it just an
> optimization. 
> 
> On the other part of what you said -- namely that you have to
> dig deeper into the frame for multicast and VLAN pruning ---
> it was suggested, but not extensively discussed, to move the
> inner VLAN into the TRILL header so that VLAN pruning would
> not need to be done by finding the inner frame.
> 
> This would still require an RBridge in the core to look
> inside to find the inner frame in order to look at the multicast
> address. 
> 
> There are two ways I can think of to avoid this:
> a) move the multicast address into the inner frame, perhaps
> as an option in the TRILL header
> b) use the multicast address in the inner frame as the
> destination address in the outer header.
> 
> I rather like the notion of moving stuff that RBridges need
> to look at into the outer header or TRILL header.
> 
> But this would need to be discussed, and hopefully soon.
> 
> Radia
> 

I can see some value in moving RBridge-relevant fields earlier
in the overall packet, but I would want to avoid any and all
risks of doing so in a way where the semantics of those fields
did not remain fully under the IEEE and/or that would require
product to implement the same logic twice. Leaving them where
they are totally avoids such risks.

Date: Thu, 07 Jun 2007 10:33:29 -0700
From: Radia Perlman <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 2162

Re: Is multicast pruning a MAY or MUST:

I'm not sure there's been enough opinion voiced to have a consensus on this.
I'd be happy with MAY or SHOULD, since it really it just an optimization.

On the other part of what you said -- namely that you have to dig deeper 
into
the frame for multicast and VLAN pruning --- it was suggested, but
not extensively discussed, to move the inner VLAN into the TRILL header
so that VLAN pruning would not need to be done by finding the inner frame.

This would still require an RBridge in the core to look inside to find the
inner frame in order to look at the multicast address.

There are two ways I can think of to avoid this:
a) move the multicast address into the inner frame, perhaps as an option in
the TRILL header
b) use the multicast address in the inner frame as the destination 
address in the outer
header.

I rather like the notion of moving stuff that RBridges need to look at 
into the
outer header or TRILL header.

But this would need to be discussed, and hopefully soon.

Radia

Anoop Ghanwani wrote:
> Per Section 3.5 of the Rbridge Base Protocol
> Specification, it looks like the trees computed
> by the ISIS base instance need to be pruned 
> based on VLAN/IGMP membership information.
>
> Also, in order to actually make use of the 
> pruning information when forwarding frames 
> in a TRILL device, it looks like one would 
> have to consult the inner L2 header of the 
> frame to extract the inner VLAN and inner
> MAC DA (the latter is needed for multicast).
>
> In some sense TRILL is creating a tunnel,
> and yet we need to dig deeper than the tunnel
> headers in order to accomplish forwarding.
> It also lacks consistency in that unicasts
> are forwarded based on the RBridge destination
> address and multicasts are forwarded based
> on the inner MAC DA and VLAN.
>
> If pruning was not a requirement we would
> not have this issue.
>
> Is the pruning functionality a requirement
> (MUST) or a recommendation (MAY)?
>
> Thanks,
> Anoop
>
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 6 Jun 2007 23:58:22 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 3459

Hi Anoop,

See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 06, 2007 5:35 PM
To: [email-masked]
Subject: [rbridge] multicast pruning in TRILL

Per Section 3.5 of the Rbridge Base Protocol
Specification, it looks like the trees computed
by the ISIS base instance need to be pruned 
based on VLAN/IGMP membership information.

Also, in order to actually make use of the 
pruning information when forwarding frames 
in a TRILL device, it looks like one would 
have to consult the inner L2 header of the 
frame to extract the inner VLAN and inner
MAC DA (the latter is needed for multicast).

In some sense TRILL is creating a tunnel,
and yet we need to dig deeper than the tunnel
headers in order to accomplish forwarding.

@@@ Certainly, the encapsulated ingress to egress Rbridge transport is a
tunnel.

@@@ Indeed, for precisely the reason you give, it was and remains my
strong personal opinion that the VLAN-tag information should be part of
the TRILL Header where it would be at least 14 bytes earlier and you
would also save the 2 bytes of tag Ethertype. It contains priority as
well as the VLAN ID info.

@@@ However, the working group appears to be of the opinion that the
VLAN-tag should be inserted inside the inner frame with an Ethertype.
See the May mail here which includes arguments on the other side of the
issue:
http://www.postel.org/pipermail/rbridge/2007-May/thread.html.

It also lacks consistency in that unicasts
are forwarded based on the RBridge destination
address and multicasts are forwarded based
on the inner MAC DA and VLAN.

@@@ There really isn't any inconsistency. The egress Rbridge for a
known-unicast frame is determined by using the destination MAC address
and the VLAN ID. It is just that for unicast, this can all be factored
into the selection of one relevant egress Rbridge and no in transit
pruning is needed. On the other hand, for multicast/broadcast, you could
theoretically have the ingress Rbridge determine and unicast to all the
relevant egress Rbridges, but that doesn't scale very well :-) So you
flood the frame but need to consult the destination address and VLAN for
pruning along the way so it only gets to relevant egress RBridges. For
both known-unicast and multi-destination frames, the frame passes
through transit Rbridges based on IS-IS adjacency and optimization
regardless of VLAN.

If pruning was not a requirement we would
not have this issue.

Is the pruning functionality a requirement
(MUST) or a recommendation (MAY)?

@@@ On the question of VLAN pruning and IP multicast pruning
implementation requirements, they can be considered separate questions
and there has been substantial discussion of them. I believe that VLAN
pruning should have an equal or higher level of implementation
requirement as IP multicast pruning and it is my impression that
"SHOULD" would be a reasonable implementation requirement for both of
these. 

@@@ Rbridges would, in some sense, operate "correctly" if there were no
pruning of multi-destination frames but you could be talking about
several orders of magnitude of inefficiency. If you were going to do
that, maybe you should consider being ultra consistent and just flooding
all frames, including unicast; after all, destination Rbridges that
don't need the frames can always throw them away. :-)

Thanks,
Anoop

@@@ Thanks,
@@@ Donald

Content-class: urn:content-classes:message
Date: Wed, 6 Jun 2007 14:34:38 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] multicast pruning in TRILL
Status: RO
Content-Length: 899

Per Section 3.5 of the Rbridge Base Protocol
Specification, it looks like the trees computed
by the ISIS base instance need to be pruned 
based on VLAN/IGMP membership information.

Also, in order to actually make use of the 
pruning information when forwarding frames 
in a TRILL device, it looks like one would 
have to consult the inner L2 header of the 
frame to extract the inner VLAN and inner
MAC DA (the latter is needed for multicast).

In some sense TRILL is creating a tunnel,
and yet we need to dig deeper than the tunnel
headers in order to accomplish forwarding.
It also lacks consistency in that unicasts
are forwarded based on the RBridge destination
address and multicasts are forwarded based
on the inner MAC DA and VLAN.

If pruning was not a requirement we would
not have this issue.

Is the pruning functionality a requirement
(MUST) or a recommendation (MAY)?

Thanks,
Anoop

Content-class: urn:content-classes:message
Date: Sat, 2 Jun 2007 12:27:29 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer 3IS-IS, and TRILL-encapsulated data packets?
Status: RO
Content-Length: 5032

Commenting on my own message, see below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Wednesday, May 30, 2007 10:26 PM
To: [email-masked]
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer
3IS-IS, and TRILL-encapsulated data packets?

OK.

Well, based on the email with this subject, the working group seems
pretty happy with the solution where both TRILL encapsulated data and
TRILL IS-IS frames are indicated by the TRILL Ethertype and header with
one of the current two reserved bits used to distinguish these cases.

But, to allow for the possibility of learning end nodes via IS-IS, I
think we need to provide for a per VLAN TRILL IS-IS message. The
proposal seems to be that, if a Q-tag is present, then it is per VLAN,
otherwise it is a core TRILL IS-IS message.

So a per VLAN multicast TRILL IS-IS message would look like

Outer.DA - 6 bytes (All-Rbridges)
Outer.SA - 6 bytes (this hop SA)
TRILL-Ethertype - 2 bytes (tbd)
TRILL Header - 6 bytes (with "control message" and multi-destination
bits on)
Inner.DA - 6 bytes (All-Rbridges)
Inner.SA - 6 bytes (original SA)
Q-Ethertype - 2 bytes
Q-tag value - 2 bytes
Length - 2 bytes
IS-IS DSAP - 1 byte (0xFE)
IS-IS SSAP - 1 byte (0xFE)
CTL - 1 byte (0x03)
IS-IS payload - variable

A core TRILL IS-IS message would be the same but without the inner
Q-tag. (Also, for a core IS-IS message, the inner and outer SA would
always be the same.)

If the IS-IS message was unicast core, the outer and inner DA addresses
would be the unicast destination, there would be no inner Q-tag, and the
multi-destination bit would be off.

If the IS-IS message was unicast per VLAN, the outer DA would the "this
hop" DA, the inner DA would be the original DA, the Q-tab would be
present, and the multi-destination bit would be off.

In the TRILL header, for the per VLAN case, the Hop Count seems
meaningful. But the ingress and egress RBridge nicknames are not used
and, in fact, you need to send IS-IS Hellos before nicknames may have
been established. Basically, the TRILL data frame needs six addresses,
one pair each for the end stations, the ingress/egress Rbridges, and the
per hop Rbridges. But IS-IS control messages are only ever from one
Rbridge to another, so they only need four addresses in the per VLAN
case (and really only two addresses in the core case since they go only
one hop).

@@@ The above is incorrect with reference to per VLAN  multicast IS-IS
messages. In particular, you need to specify the distribution tree. For
consistency, it seems best to do this via the "egress Rbridge" field.
This means you really can't do per VLAN IS-IS until the nicknames are
settled, which is probably OK.

So it seems to me that the alternatives are to either
	(1) Leave the nickname fields unset or set to zero on
transmission and ignored on receipt or
	(2) Maybe add one of the reserved bits to the Version field and
re-name it "Variation" or something and have the 6 byte "Data" variation
as currently specified and the "IS-IS" variation which is just 2 bytes
because it does not have the nickname fields.

@@@ Making the Version field into a Variation field is really orthogonal
and may be a reasonable idea regardless.

@@@ Because the "egress Rbridge" field is needed to specify the
distribution tree for per VLAN multicast IS-IS messages, it seems
simpler to stick with the existing TRILL Header format for both data and
TRILL IS-IS messages.

@@@ Thanks,
@@@ Donald

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2007 2:25 PM
To: Erik Nordmark
Cc: Radia Perlman; Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] How is an IS-IS packet differentiated from layer
3 IS-IS, and TRILL-encapsulated data packets?

Erik,

You are correct, I oversimplified the explanation, but the conclusion
still holds

-- Silvano

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2007 11:02 AM
> To: Silvano Gai
> Cc: Radia Perlman; Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from
layer 3
> IS-IS, and TRILL-encapsulated data packets?
> 
> Silvano Gai wrote:
> 
> > The advantage of using a reserved bit is that the frame with
Ethertype =
> TRILL already go through DR blocked ports. The non-TRILL IS-IS frames
will
> have Ethertype = ISIS and will be dropped by DR blocked ports.
> 
> I don't know if this matters, but AFAIK (and after checking RFC 1142),
> there is no Ethertype for IS-IS. Instead IS-IS uses a 802.3 header
(i.e.
> a length field instead of an Ethertype field) followed by 3 bytes of
LLC
> header with the SAP 0xFE. Thus the 3 bytes after the length field is
03
> FE FE.
>     Erik

[email-masked]