Subject: [rbridge] I got some answers from the IS-IS mailing list

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 15 Jun 2007 21:11:31 -0700

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

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sat, 16 Jun 2007 08:24:12 -0700

If this is the case I will use the multicast address to distinguish
TRILL ISIS not an extra bit in the header.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman
> Sent: Friday, June 15, 2007 9:12 PM
> To: rbridge at postel.org
> Subject: [rbridge] I got some answers from the IS-IS mailing list
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Sat, 16 Jun 2007 10:10:22 -0700

Hi Radia,

> 2) I checked to make sure that "0" would be OK to use as an area 
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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sat, 16 Jun 2007 19:35:07 -0700

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
>> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
>> from layer 3 IS-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.
>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 16 Jun 2007 23:11:02 -0400

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: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Silvano Gai
Sent: Saturday, June 16, 2007 11:24 AM
To: Radia Perlman; rbridge at postel.org
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list

-- Silvano

On
> is based on having a new multicast address. I wrongly remembered
IS-IS,
> same PSNP). So, for encoding TRILL IS-IS, it can be differentiated
from

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sat, 16 Jun 2007 22:21:47 -0700

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

On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Saturday, June 16, 2007 8:11 PM
On
> > 1) They have deployed a variant of IS-IS, and the way they
distinguish

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sun, 17 Jun 2007 23:57:13 -0400

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:sgai at nuovasystems.com] 
Sent: Sunday, June 17, 2007 1:22 AM
To: Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

-- Silvano

On
On
distinguish

---

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

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: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Sunday, June 17, 2007 8:57 PM
> To: Silvano Gai; rbridge at postel.org
> 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 
> 
> 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
> 
> > routers, the multicast address "All-Level-1-ISs". We are 
> already using
> a
> > > 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
> > > spawned by running the Hello protocol on a link according to each 
> > > VLAN the DR supports)
> > works.
> > > I was worried
> > > worried about weird hardware problems creating nontransitive 
> > > connectivity, we put
> in
> > > what R2 should
> > > packets rather than announcing all endnodes in per-VLAN 
> instances of 
> > > IS-IS) answer
> > everyone's
> > > scalability concerns?
> > >
> > > Radia

---

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

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:anoop at brocade.com] 
Sent: Monday, June 18, 2007 2:10 PM
To: Eastlake III Donald-LDE008; Silvano Gai; rbridge at postel.org
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

Donald,

Anoop 

> I've got no problem with using destination address to bypass 
> [mailto:rbridge-bounces at postel.org]
> > On
> > > Behalf Of Radia Perlman

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 18 Jun 2007 13:51:10 -0700

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

> From: Eastlake III Donald-LDE008 
> [mailto:Donald.Eastlake at motorola.com] 
> Sent: Monday, June 18, 2007 12:36 PM
> To: Anoop Ghanwani
> Cc: rbridge at postel.org
> > > "All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast 
> addresses.
> > You
> > > different multicast address from that, just like they 
> did, by using
> > the
> > > > 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.)
> > > >
> > > > do when the link state database implies R2 can talk to 
> R3 through
> > the
> > > > pseudonode, but

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 18 Jun 2007 17:31:36 -0400

Anoop,

See below at @@@

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

Donald,

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

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

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

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

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

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 18 Jun 2007 14:40:47 -0700

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

> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> 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 
> 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
> 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

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 18 Jun 2007 14:51:28 -0700

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

> Sent: Monday, June 18, 2007 2:32 PM
> To: Anoop Ghanwani
> I think Silvano mentioned it is better to use a multicast MAC 
> address to identify IS-IS frames.
> @@ 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
>

---

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

Hi Anoop,

See below at ### 

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

Donald,

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

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

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

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

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

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

### Thanks,
### Donald

Anoop

---

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

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

---

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

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:Radia.Perlman at sun.com] 
> Sent: Wednesday, June 20, 2007 12:14 PM
> To: Anoop Ghanwani

---

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

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: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Wednesday, June 20, 2007 3:17 PM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list

Radia,

Anoop