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

From: Radia Perlman <[email-masked]>
Date: Fri, 18 May 2007 21:43:07 -0700

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?

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.

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

---

From: Jeff Learman <[email-masked]>
Date: Mon, 21 May 2007 11:43:50 -0400

At 12:43 AM 5/19/2007, Radia Perlman wrote:
>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).
>
>campus between the RBridges, but will be stripped off at the egress RBridge so layer 3 routers won't know it happened.
>
>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
>TRILL will use "area address=0", which I'm assuming is not a legal area address for layer 3. Is this assumption correct?
>
>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?
>
>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.

Better to allocate a new Ethertype, IMHO.  Only one protocol can
get away with the "ethertype zero" trick.  Furthermore, it will
look like an 802.3 packet to many implementations (length being
less than 0x0800), and no doubt that would cause some confusion.

Since it only appears in the context of a TRILL tunnel, these
issues are probably minor, but it would at least make life easier
for protocol analysis to use a nonzero Ethertype.

>b) We could use a flag in the TRILL header (steal a reserved bit) to mean "This is a TRILL IS-IS packet"

I see no harm in this, if TRILL bridges only ever talk to each
other across TRILL tunnels.  If two rbridges are collocated on
a LAN, would they use TRILL tunnels to communicate between them?
Or would the area 0 in LSPs be sufficient?

Regards,
Jeff

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Tue, 22 May 2007 13:13:25 -0700

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

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.

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

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.

> appear in a data packet. Then RBridges would interpret Ethertype=0 as
a

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

---

From: mike shand <[email-masked]>
Date: Wed, 23 May 2007 10:09:41 +0100

A couple of comments inline....

    Mike

Les Ginsberg (ginsberg) wrote:
>> Which means that layer 3 IS-IS, if routers are connected via a
>>     
> "campus",
>   
>> will look
>> like:
>>
>> RBridges, and a hop count, and (luckily, because I think we'll need
>>     
> it)
>   
>> some reserved bits.
>>
>> 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
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.
> 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.
>> Layer 3 IS-IS routers will not ever see a TRILL IS-IS packet because
>>     
> it
>   
>> will be
>> But the question is---how does an RBridge know the difference between
>>     
> a
>   
>> layer 3
>> appear in a data packet. Then RBridges would interpret Ethertype=0 as
>>     
> a
>   
>> TRILL IS-IS
>> packet.
>>     
>
There is NO such thing, I think you mean :-)