Subject: Re: [Isis-wg] How should we encode TRILL IS-IS to distinguish it fromlayer 3 IS-IS?

From: Radia Perlman <[email-masked]>
Date: Thu, 14 Jun 2007 22:48:09 -0700

Whoops. Lost these messages.

So...TRILL needs an area address. It would be nice to know it was one that
would never be used by L3 IS-IS. I don't care what it is. It should be a 
constant
for TRILL. Would someone like to
tell us what constant to specify? "0" is specified by IS-IS as 
"illegal". And Les
said "I don't see why TRILL should use an illegal address". But I don't 
see why not.
I like 0. I can remember it. It's short. And no L3 IS-IS will ever use 
it. But if the
IS-IS group would like to tell us something different, it's trivial to 
change the spec to that.

And yes--I was saying (and Les and Mike were agreeing) that it's 
essential that
a TRILL IS-IS not get mistaken to be L3 IS-IS. Les pointed me at:

http://www.ietf.org/internet-drafts/draft-previdi-isis-mi-00.txt
section 3.4.1

which basically says to use a different destination multicast
address.

I was assuming this wouldn't work because aren't there occasionally
IS-IS packets that are unicast? The one I assumed (from my
memory of DECnet Phase V routing) would be unicast would be
a PSNP requesting that the DR retransmit an LSP.

Radia

mike shand wrote:
> A couple of comments inline....
>
>    Mike
>
> Les Ginsberg (ginsberg) wrote:
>> Radia -
>>
>>  
>>> -----Original Message-----
>>> From: Radia Perlman [mailto:[email-masked]]
>>> Sent: Friday, May 18, 2007 9:43 PM
>>> To: [email-masked]
>>> Subject: [Isis-wg] How should we encode TRILL IS-IS to distinguish it
>>> fromlayer 3 IS-IS?
>>>
>>> The TRILL WG would like to use IS-IS for RBridges to have a routing
>>> protocol among themselves.
>>>
>>> RBridges encapsulate packets with a TRILL header as they are forwarded
>>> across the RBridged-cloud (called a "campus").
>>>
>>> Which means that layer 3 IS-IS, if routers are connected via a
>>>     
>> "campus",
>>  
>>> will look
>>> like:
>>>
>>> inner frame: exactly as the first IS-IS router transmits it, i.e., an
>>> Ethernet header
>>> with Ethertype="IS-IS", Ethernet source address=IS-IS router that
>>> transmitted it,
>>> Ethernet destination address usually="all-Level1-routers" or
>>> "all-Level2-routers", but
>>> sometimes unicast (like in the case of a PSNP).
>>>
>>> And this frame will be TRILL-encapsulated while travelling across the
>>> campus between the RBridges, but will be stripped off at the egress
>>> RBridge so
>>> layer 3 routers won't know it happened.
>>>
>>> The layer 3 IS-IS packet, when TRILL-encapsulated look like:
>>>
>>> outside the inner frame is a "TRILL header", which identifies the
>>> ingress and egress
>>> RBridges, and a hop count, and (luckily, because I think we'll need
>>>     
>> it)
>>  
>>> some reserved bits.
>>>
>>> outside that is an ordinary looking Ethernet header (in case there are
>>> bridges
>>> between two RBridges), with Ethertype=TRILL.
>>>
>>> ***********
>>> So far OK.
>>>
>>> But now -- how do we encode TRILL IS-IS packets so they are not
>>>     
>> confused
>>  
>>> with
>>> layer 3 IS-IS, and also not confused with TRILL-encapsulated data
>>>     
>> packets?
>>  
>>> TRILL will use "area address=0", which I'm assuming is not a legal
>>>     
>> area
>>  
>>> address for
>>> layer 3. Is this assumption correct?
>>>     
>>
>> I am not sure why you ask the question.
>> Are you thinking this is some extra layer of protection that should an
>> L3 IS-IS instance mistakenly process a TRILL IS-IS PDU that it would
>> reject the PDU because of an illegal area address?
>>
>> First, if the solution does not prevent TRILL IS-IS PDUs from being
>> processed by L3 IS-IS instances then it has already failed in a
>> significant way because it has added unnecessary processing overhead to
>> these instances. This MUST be prevented.
>>
>> Second, even if a TRILL IS-IS PDU were to be processed by an L3 IS-IS
>> instance it would be rejected because the L3 IS-IS instance would not
>> recognize the source i.e. IS-IS specifies that PDUs must not be accepted
>> unless they are from a system to which the receiving router has an
>> adjacency. I am assuming that the TRILL Rbridges will use unique system
>> IDs and therefore the source will not be known to any L3 IS-IS instance.
>> The exception would be IIHs - in which case the importance of my first
>> point applies.
>>   
> I'm pretty sure that implementations exist which do not perform the 
> adjacency check on received LSPs etc.
> Which again emphasises the importance of Les's first point.
>> Third, I doubt that most IS-IS implementations perform syntax checking
>> on the area addresses. They simply determine whether they overlap with
>> the manually configured set or not so they can determine whether the
>> sender and receiver are in the same area. So I would not expect that
>> PDUs would be rejected for having "a bad area address".
>>   
> Yes. I'm sure most implementations simply treat the Area address as a 
> string of bits. Using Area Address = 0 doesn't seem to help at all.
>> The technical answer to your question is "Yes - 00 is an illegal area
>> address". See ISO/IEC 8348:2002 (E) Table A.1 which specifies that:
>>
>>     00-0F, FF Reserved - Will not be allocated
>>
>> However I see no reason why TRILL should use an illegal area address.
>>
>>  
>>> Layer 3 IS-IS routers will not ever see a TRILL IS-IS packet because
>>>     
>> it
>>  
>>> will be
>>> TRILL-encapsulated. The Ethertype will be TRILL rather than IS-IS, and
>>> RBridges
>>> will not use the IS-IS layer 2 multicast addresses.
>>>
>>> But the question is---how does an RBridge know the difference between
>>>     
>> a
>>  
>>> layer 3
>>> IS-IS packet that has been encapsulated for transit across the campus,
>>> and a TRILL
>>> IS-IS packet?
>>>
>>> Both will have TRILL headers.
>>>
>>> There's lots of solutions -- I just want to know what will be most
>>> convenient for
>>> IS-IS implementers.
>>>
>>> a) We could use an "illegal" inner Ethertype, say Ethertype=0, that
>>> would never
>>> appear in a data packet. Then RBridges would interpret Ethertype=0 as
>>>     
>> a
>>  
>>> TRILL IS-IS
>>> packet.
>>>     
>>
>> I agree with Jeff's point about this being a rather ugly - and not
>> reuseable - solution. However, since your question is in part what would
>> be most "convenient for IS-IS implementers", I suggest you look at what
>> has been proposed in the recently published MI draft:
>>
>> http://www.ietf.org/internet-drafts/draft-previdi-isis-mi-00.txt
>>
>> (See Section 3.4.1)
>>
>> Because IS-IS PDUs use 802.3 format - there is such thing as an "IS-IS
>>   
> There is NO such thing, I think you mean :-)
>> Ethertype". One of the points of discussion when writing the MI draft
>> was whether the use of a different Mcast destination address for the MI
>> PDUs was sufficient protection to prevent legacy implementations from
>> mistakenly processing MI PDUs. One proposal that was considered was
>> whether to acquire an "Ethertype MI-IS-IS" and send MI PDUs in Ethertype
>> format.
>>
>> After some discussion, we elected to retain the use of 802.3 format as
>> this is what all IS-IS implementations currently support and rely on the
>> new multicast address as a sufficient means of preventing legacy
>> implementations from seeing the new PDUs. The logic here is that any
>> implementation which does not properly filter by MAC address is already
>> vulnerable to severe degradation in the presence of packets of any type
>> (not necessarily IS-IS) which happen to use a destination address which
>> slips through a filter.
>>
>> Even if a new Ethertype were used, the use of a different multicast
>> address is still required to prevent legacy implementations from
>> needlessly processing PDUs only to discover they should be discarded.
>> But we would also place a new requirement on IS-IS implementations to
>> recognize and handle two different Ethernet frame formats. The potential
>> impact of this on legacy implementations is unknown. This seems
>> undesirable.
>>
>> In a way, your question here is very timely since we (authors of the MI
>> draft) also were looking for feedback on this particular point. I would
>> suggest that we both settle on the same solution style.
>>
>>    Les
>>
>>  
>>> b) We could use a flag in the TRILL header (steal a reserved bit) to
>>> mean "This is
>>> a TRILL IS-IS packet"
>>>
>>> Any other ideas or advice?
>>>
>>> Thanks,
>>>
>>> Radia
>>>
>>>
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/isis-wg
>>>     
>>
>> _______________________________________________
>> Isis-wg mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/isis-wg
>>
>>   

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

---

From: mike shand <[email-masked]>
Date: Fri, 15 Jun 2007 08:53:01 +0100

Radia Perlman wrote:
> would never be used by L3 IS-IS. I don't care what it is. It should be 
> a constant
> tell us what constant to specify? "0" is specified by IS-IS as "illegal". 
Its not IS-IS that specifies it as "Illegal" it is ISO/IEC 8348. IS-IS 
is completely agnostic about the format of NETs used, and the problem is 
that so are most implementations. So although 8348 deems it illegal 
there is likely to be nothing to prevent anyone using it, especially 
since most users of IS-IS know nothing, and care less, about any ISO 
addressing specifications.

Now I agree it is very unlikely that anyone would use an area address of 
zero. But I'm not sure you can rely on never seeing it.

OTOH reserving some other value is just as likely to run into trouble, 
so perhaps, for the reasons you mention, zero is the best choice.
> And Les
> said "I don't see why TRILL should use an illegal address". But I 
> don't see why not.
No, we deliberately required that the PSNP was multicast even though 
only the DR responds to it. See ISO/IEC 10589 clause 7.3.17 note 38

If an Intermediate system detects that the transmitter had more up to 
date information, the receiving Intermediate system shall multicast a 
Partial
Sequence Numbers PDU (PSNP), containing information about LSPs for which 
it has older information. This serves as an implicit request for the
missing information. Although the PSNP is multicast, only the Designated 
Intermediate System of the appropriate level shall respond to the
PSNP.

NOTE 38 This is equivalent to the PSNP being transmitted directly to the 
Designated Intermediate System, in that it avoids each Intermediate System
unnecessarily sending the same LSP(s) in response. However, it has the 
advantage of preserving the property that all routeing messages can be 
received
on the multi-destination addresses, and hence by a LAN adapter dedicated 
to the multi-destination address.

Mike

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Sun, 17 Jun 2007 21:50:17 -0700

Adding a bit to what Mike has said (all of which I agree with)...

> From: Mike Shand (mshand)
> Sent: Friday, June 15, 2007 12:53 AM
> To: Radia Perlman
> Cc: Les Ginsberg (ginsberg); [email-masked]
> Subject: Re: [Isis-wg] How should we encode TRILL IS-IS to distinguish
it
> > So...TRILL needs an area address. It would be nice to know it was
one
> > that
> "illegal".
> > it.

This last statement cannot be stated with certainty - which is what both
Mike and I have been trying to say. Just as you find it convenient to
use "00" so might someone else for their own reasons. So, DO NOT RELY on
this as a means of isolating yourself.

The more important point is that if TRILL IS-IS PDUs make it past the
receive filter of a router and have to be processed by an IS-IS
implementation you will have failed to adequately isolate TRILL IS-IS
even if the IS-IS implementation rejects the PDU. 

Finally, the use of "00" is not actually prohibited by ISO 8348. The
document simply declares that the value will never be allocated by any
addressing authority. As per Annex B.2:

"Annex A merely reserves these AFI values, and does not specify how they
might be used; all such uses are outside the scope of Annex A."

   Les

> > But if the

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 18 Jun 2007 07:34:11 -0400

Hi,

Based on the current draft and discussions in the TRILL WG,
TRILL/Rbridge IS-IS messages will be distinguished from layer 3 IS-IS
messages in three ways:
	(1) They will be sent to a different multicast address, All
Rbridges (which has not yet been allocated).
	(2) The IS-IS frame will actually appear inside a TRILL frame
after a TRILL Ethertype (tbd) and header.
	(3) TRILL IS-IS messages will use Area Address zero.

So, for there to be confusion, you would need a router IS-IS
implementation that was willing to parse the message despite the wrong
multicast address, somehow skip past the  opaque TRILL Ethertype and
header it doesn't understand, and form an adjacency with area zero...

Donald (co-chair, TRILL) 

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 12:50 AM
To: Mike Shand (mshand); Radia Perlman
Cc: [email-masked]
Subject: RE: [Isis-wg] How should we encode TRILL IS-IS to distinguish
itfromlayer 3 IS-IS?

it
one

   Les

---

From: Tony Li <[email-masked]>
Date: Mon, 18 Jun 2007 12:20:53 -0700

Donald,

This then raises the obvious question: any implementation that  
violates (1) and (2) will undoubtedly have no issues violating (3).   
So, what's the point?  It would seem that (1) and (2) should be  
sufficient.

Ob. disclosure: my preference is for http://tools.ietf.org/id/draft- 
previdi-isis-mi-00.txt.  We all might as well be different in the  
same way.  ;-)

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 20 Jun 2007 10:22:56 -0700

On Jun 20, 2007, at 10:03 AM, James Carlson wrote:

> I don't think that helps.  We need the separate Ethertype in order to
> deal with blocking state -- RBridges need some way to know that the
> inbound control datagram needs to be processed even though the link
> isn't otherwise active for data traffic, including ordinary IS-IS.  I
> don't think a new TLV works well for that.

The draft allocates new multicast addresses for that purpose.  Please  
see section 3.4.1:

    An MI-RTR will use the AllL1IS and AllL2IS ISIS mac layer addresses
    (as defined in [IS-IS]) when sending ISIS PDUs for the standard
    instance (IID #0). An MI-RTR will use two new (TBD) dedicated layer
    2 multicast addresses (one for each level) when sending IS-IS PDUs
    for any non-zero IID.

Tony

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 20 Jun 2007 13:55:06 -0400

That's right. Rbridges have to be able to run with zero configuration
and need some Area Address. Zero is sort of an elegant number that it
does not take very many bits to express :-)

However, besides the mandatory core instance of IS-IS that runs across
all the Rbridges in a campus, there can be optional per VLAN instances
that, if they exist, run only in the Rbridges that are designated router
for a link with an end station in that VLAN. The mechanism in this draft
could be considered for distinguishing between the core instance and the
per VLAN instances of IS-IS in Rbridges.

Thanks,
Donald

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Wednesday, June 20, 2007 1:04 PM
To: Tony Li
Cc: Eastlake III Donald-LDE008; Les Ginsberg (ginsberg); Radia Perlman;
[email-masked]; Mike Shand (mshand)
Subject: Re: [Isis-wg] How should we encode TRILL IS-IS to
distinguishitfromlayer 3 IS-IS?

> So, what's the point?  It would seem that (1) and (2) should be  

I believe that (3) is there mostly as support for zero-configuration,
and doesn't necessarily help provide the segregation that (1) and/or
(2) does.  (You have to choose some area as 'default'.)

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

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 20 Jun 2007 14:07:10 -0400

Not all Rbridge protocol traffic is multicast.  Data unicast to a known
address is unicast inside a TRILL Ethertype frame.

An Rbridge can tell whether it should process a frame, despite receiving
it on a port that is in a blocking state for native data traffic (and a
layer 3 IS-IS would just appear to be native data to an RBridge) by
looking for the TRILL Ethertype. Frames with that Ethertype should be
further processed, those without should not be. (I'm ignoring stuff that
is sort of taken care of the by port like 802.1AB or 802.1AE...)

There will be a new version of the TRILL base protocol document, -04,
posted in a few days. People interested may want to look at that.

Donald

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Wednesday, June 20, 2007 1:23 PM
To: James Carlson
Cc: Eastlake III Donald-LDE008; Les Ginsberg (ginsberg); Radia Perlman;

Tony

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 21 Jun 2007 20:17:20 +0200

another zero-config option to prevent adjacencies coming up would be
to allocate a nlpid for trill and advertise it in the protocol
supported TLV #129.

all implementations that i am familiar with do:

1. generate TLV #129 and list the supported nlpid's - {ipv4,ipv6,clnp}
2. do not take an adjacency up if there is no common nlpid.

/hannes

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Thu, 21 Jun 2007 23:43:23 -0700

> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Thursday, June 21, 2007 11:17 AM
> To: Eastlake III Donald-LDE008
> Cc: Les Ginsberg (ginsberg); Mike Shand (mshand); Radia Perlman; isis-
> [email-masked]

Pretty much any CLNS only implementation (and there ARE deployments of
those) knows nothing about TLV #129.

But preventing adjacencies from forming between TRILL/non-TRILL IS-IS
instances is NOT a problem.

TRILL IS-IS implementations send/receive using new multicast addresses.
Therefore, any IS-IS PDU sent by a non-TRILL IS-IS implementation will
NOT be processed by a TRILL IS-IS implementation. That means that no
matter what the non-TRILL IS-IS may do, the three way handshake will
never be satisfied. And since TRILL IS-IS will never advertise an
IS-neighbor to a non-TRILL IS, the two way connectivity check would also
never be satisfied. We do not need to rely upon PDU content (be it area
address, NLPID, or some new TLV) for protection.

The REAL issue is whether TRILL IS-IS PDUs can be expected to make their
way past the receive filters on a non-TRILL IS. If they do, then we
impact the operation of the non-TRILL IS - even when the PDUs are
eventually rejected - which is highly undesirable.

What TRILL and  

propose is that new multicast addresses will be sufficient to prevent
the intrusion of unwanted IS-IS PDUs to legacy implementations.

The argument for new multicast addresses is that legacy implementations
MUST have destination address filtering in place or run the risk of
being deluged with unwanted multicast packets - whether of the new IS-IS
type or others. The filtering may be a combination of hardware and
software filtering - but an implementation that does not do complete
filtering is already at great risk absent any new traffic.

This is the point which merits discussion. I look forward to replies on
this issue.

   Les

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Jun 2007 13:32:01 -0400

>     2 multicast addresses (one for each level) when sending IS-IS PDUs

So, as a bridge, the proposal is that when in blocking state, we would
examine IS-IS PDUs for those new multicast addresses.  If the TLV is
present, and it identifies an RBridge instance, then process it.
Otherwise, drop.

When not in blocking state, we'd then bridge those non-RBridge messages
as usual, so the determination of forward-versus-terminate depends on
the IID.

Unless I'm misunderstanding that, it seems messy.

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Jun 2007 13:03:37 -0400

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Jun 2007 13:32:01 -0400

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Jun 2007 13:03:37 -0400

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 22 Jun 2007 10:45:46 -0400

Perhaps it would be a good idea to include a TLV #129 with the "rbridge"
nlpid or the like, but only in case someone implements a different
protocol in the future for layer 2 IS-IS routing on MAC addresses. I can
see little purpose to adopting a scheme where layer 2 Rbridge IS-IS
instances have to grovel through layer 3 IS-IS packets to decide to
reject them, and vice versa, when it is to easy to keep them completely
separate. I mean, from the point of view of a layer 3 router, Rbridges
only want to do IS-IS communications inside a single link while the
router wants to do IS-IS communications with other layer 3 routers over
multiple links about routing between different links...

Donald

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 2:17 PM
To: Eastlake III Donald-LDE008
Cc: Les Ginsberg (ginsberg); Mike Shand (mshand); Radia Perlman;
[email-masked]

/hannes

---

From: Tony Li <[email-masked]>
Date: Fri, 22 Jun 2007 10:22:10 -0700

> multiple links about routing between different links...

I have a concern with the idea of allocating code points per  
function.  It's become apparent to me that we will eventually have  
the capability of running many different instances of IS-IS, some of  
which will be due to differing functions (e.g., rbridge, generic  
flooding) and some of which will need multiple instances within a  
single function (e.g., multiple virtual topologies).  If we  
differentiate based on pre-allocated code points, then we need to  
provide enough code points for the cross product of functions and  
instances.  That could quickly get large.

Instead, I'd like to propose that we take the approach of one code  
point that says "this is not your normal IS-IS" and then an extension  
mechanism that would allow local definition of an instance.

Tony

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Fri, 22 Jun 2007 10:55:03 -0700

> From: Tony Li (tli)
> Sent: Friday, June 22, 2007 10:22 AM
> Cc: Hannes Gredler; [email-masked]
> Subject: Re: [Isis-wg] How should we encode TRILL IS-IS todistinguish
> itfromlayer 3 IS-IS?
> 
> 

Agreed.

> mechanism that would allow local definition of an instance.

Since legacy implementations by definition do not understand anything
which is new - be it a new TLV or a new code point in an existing TLV -
we are just as well off defining a new TLV which says "this is not your
normal IS-IS". This is defined in 

But this is only useful for those routers who want to support multiple
instances. For those routers who should not process the PDUs for the new
instances codepoints are at best a very expensive way of filtering - and
at worst ineffective.

For both TRILL and MI the first issue is that we don't want to burden
the non-TRILL/non-MI capable implementations with processing of PDUs
which they will either always reject or (even worse) accept and
misinterpret. Hence the new multicast addresses.

   Les

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 22 Jun 2007 22:44:04 +0200

| On Fri, Jun 22, 2007 at 10:22:10AM -0700, Tony Li wrote:
| Instead, I'd like to propose that we take the approach of one code  
| point that says "this is not your normal IS-IS" and then an extension  
| mechanism that would allow local definition of an instance.

agreed - it just seems that we cannot get consensus what the 'right'
way of flagging of 'this is not your normal IS-IS' is ...

a while ago i have suggested to bump the version field to flag
the changed TLV interpretation semantics of the MI extensions.

today any TLV is self-contained with no assumptions about ordering etc.
MI changes that model that the MI TLV data keys all TLVs found in the PDU.

/hannes

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 22 Jun 2007 17:06:51 -0400

Hi,

See below at @@@ 

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Friday, June 22, 2007 1:22 PM
To: Eastlake III Donald-LDE008
Cc: Hannes Gredler; [email-masked]
Subject: Re: [Isis-wg] How should we encode TRILL IS-IS to distinguish
itfromlayer 3 IS-IS?

@@@ All the current nlpid values mentioned in this thread represent
different types of addresses. Maybe Rbridges should use nlpid="EUI-48"
or something like that.

@@@ Not entirely directly related to your message, but I've read
draft-previdi-isis-mi-00.txt. Its requirement that different instances
be "configured" so as to have different 16-bit instance identifiers
can't be applied in Rbridges which have to be able to operate with zero
configuration. There are up to exactly 2**12 - 2 + 1 instances of IS-IS
in an Rbridge campus: 2**12 - 2 for the number of legal 12 bit VLAN
identifiers (0x000 and 0xFFF are reserved) plus 1 campus wide core
instance of Rbridge IS-IS.

@@@ So, it would be plausible to use the previdi-isis-mi mechanism to
distinguish IS-IS instances in Rbridges, although a bit redundant since
the VLAN ID or an indication that it is the core instance also occurs
elsewhere in the frame, but the previdi-isis-mi instance identifier
would have to be hard-wired as something like zero for the core instance
and 1 through 0xFFE depending on the VLAN ID for any per VLAN instances
that existed. In the extremely implausible event that there was any
cross-over of PDUs between the Rbridge instances of IS-IS and other
instances, the other instances would have to have been configured with
instance identifiers > 0xFFE.

Tony

@@@ Donald