[rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?

Sat May 19 19:09:25 PDT 2007

Hi Radia,

This proposal seems fine but a few comments, in somewhat miscellaneous
order:

I believe that multicast addresses are cheap and, if we wanted to, we
could get any reasonable number; however, multicast frames don't seem to
me to be the problem. If you receive a frame sent to All Rbridges,
according to the current protocol draft, it can only have one of two
Ethertypes, TRILL or IS-IS. And if that Ethertype is IS-IS, then it is
an IS-IS packet for the TRILL core IS-IS instance. (The qualification
"core" no longer being necessary with the per-VLAN IS-IS instances
dropped.)

Layer 3 IS-IS multicast messages would always be sent to a multicast
address different from All Rbridges.

So it is only unicast IS-IS messages that would be a problem if an
Rbridge had difficulty telling whether they were for layer-3 or for
Rbridge IS-IS.

I believe Ethertypes are a much more scarce resource and it is best to
stick with one, as your proposal does.

A TRILL header with one of the currently reserved bits set would
certainly serve to mark unicast IS-IS packet intended for TRILL and
could also be included in the multicast case for greater uniformity and
added protection against some layer 3 IS-IS router deciding to process
the frame despite its multicast address. However, most of the fields in
such a TRILL header are or might be unused. The Rbridges might not yet
have selected nicknames and in any case the nicknames would not be
useful, the hop count is not useful, etc.

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Saturday, May 19, 2007 12:23 AM
To: Radia Perlman
Cc: Rbridge at postel.org
Subject: Re: [rbridge] How is an IS-IS packet differentiated from layer
3 IS-IS, and TRILL-encapsulated data packets?

OK. Here's my proposal.

TRILL IS-IS will always be encapsulated in a TRILL header.
That means the outer Ethertype is always="TRILL" for TRILL IS-IS packets
(whether they are LSPs, Hellos, or SNPs).

I propose using a bit in the TRILL header (that would have been
"reserved"
to mean "this is a TRILL IS-IS packet".

Is this OK?

Radia

Radia Perlman wrote:
> Now that I'm editing the spec to be real specific here, I need a 
> sanity check, or
> advice from implementers about what would be most convenient for them.
>
> My assumption is that we are removing the per-VLAN instance of IS-IS 
> (which could
> be added later on, for the purpose of distributing endnode information

> that is more
> securely learned, say through a cryptographically authenticated layer 
> 2 enrollment
> protocol). But we are requiring RBridges to learn (ingress RBridge, 
> source MAC address)
> from packets they are decapsulating onto their link.
>
> So we just have the core instance of IS-IS. We have to make sure layer

> 3 IS-IS
> packets (which might also be flowing across the campus between 
> routers) don't
> get confused with TRILL IS-IS. We also have to have RBridges easily 
> distinguish
> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data packets.
>
> When a router generates an IS-IS packet, the destination address will 
> be "all-level1-routers"
> or "all-level-2 routers", or perhaps, a specific router (for instance,

> to send a PSNP).
> The way this is recognized as an IS-IS packet is due to the 
> EThertype=IS-IS.
>
> RBridge, I believe, should not treat IS-IS packets differently from 
> any other "data"
> packets. If it's addressed to "all-level1-routers" or 
> "all-level2-routers" it would be
> treated like any other multidestination packet, encapsulated, and sent

> along a distribution
> tree. If it's unicast, it is treated like any other unicast packet by 
> RBridges, assuming
> the layer 2 address specified in the destination is known to the 
> ingress RBridge.
>
> The question is---how are TRILL IS-IS packets encoded?
>
> Could we get a second Ethertype for this? I'm assuming not...
>
> I'm assuming we just have a single Ethertype for "TRILL-encapsulated".

> So we have
> to use that.
>
> We could use a different multicast destination address for 
> "all-RBridges-for-IS-IS" vs
> "all-RBridges" that is used for multicast data.
>
> Or we could have a bit in the TRILL header saying "this is an IS-IS 
> packet".
>
> We could in theory not use the TRILL header for IS-IS packets, since 
> in theory
> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs 
> directly over layer 2).
> But then we'd need a separate Ethertype.
>
> So...if we are going to use the TRILL header, then how do we not get 
> confused
> between TRILL IS-IS and layer 3 IS-IS?
>
> I guess we could assume that it's enough to have TRILL IS-IS use "0" 
> as the area
> address, and use IS-IS as the Ethertype in the inner header. For 
> TRILL-encapsulated
> packets, we actually could choose some weirdo Ethertype (like 0) in 
> the inner header.
> But we still need to differentiate TRILL IS-IS from layer 3 IS-IS on 
> the first hop.
>
> This is probably something I should ask the IS-IS WG, since it really 
> depends on
> idiosyncracies of the current IS-IS implementations.
>
> Radia
>
>
>
>
>
>
>
>
>

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