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

[Radia Perlman]

Right (what Donald said below).

To summarize -- if we TRILL-encapsulate IS-IS packets, then we have to be
able to notice, based on the TRILL header, that this is a TRILL IS-IS 
packet (rather than
an encapsulated layer 3 IS-IS packet).

We might avoid TRILL-encapsulating an IS-IS packet by
using a new multicast address and using the IS-IS Ethertype, but I'm
nervous it might confuse some layer 3 IS-IS implementations. I'm also 
worried
that occasionally an IS-IS packet would not be multicast (for instance, 
a PSNP
might be unicast).

I'm also worried about the per-VLAN instance of IS-IS. Even if we don't
make advertising endnodes via IS-IS a MUST, or even if we don't mention it
in the first version of the protocol, I'd like to be able to add 
advertisement of
"particularly well-learned" endnode addresses via a per-VLAN instance of 
IS-IS at
some point in the future, and make the advertisements, as well as the 
learning
from them, be a MAY or SHOULD.

So...if we TRILL-encapsulate (in order to use the TRILL Ethertype), 
basically all
the fields in the TRILL header are useless. So, we could use a reserved 
bit in
the TRILL header to say this
is IS-IS. Or we could reserve a value of nickname (say, nickname=0), and 
define
IS-IS to use ingress and egress nickname both=0.

Once we find a way to differentiate a TRILL-encapsulated TRILL-IS-IS from
a TRILL-encapsulated layer 3 IS-IS packet, doing the per-VLAN one won't be
hard. We'd just add a VLAN tag in the "right place".

So---if these are the alternatives, what do people prefer?
TRILL-encapsulate IS-IS packets, using Ethertype=IS-IS in
the inner frame, differentiating TRILL IS-IS from a
TRILL-encapsulated layer 3 IS-IS using either:

a) a reserved bit in the TRILL header
b) reserved nickname values (say ingress nickname = 0)

Radia




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