[rbridge] encoding of TRILL IS-IS frames

[Dinesh G Dutt]

Hi Radia,

I agree with all your points below. Further, I think that ESADI 
discussion is better off in a separate document than the base protocol 
spec. I'm concerned that it maybe not all right if and when someone 
plans a serious implementation of it. I want a very solid base protocol 
specification that is lean, precise and easy to  follow through with as 
little unnecessary stuff in it as possible.

Dinesh
Radia Perlman wrote:
> Someone asked me why IS-IS frames need to be TRILL-encapsulated, and I 
> don't remember. I do know we
> were somewhat concerned about differentiating TRILL IS-IS frames from 
> layer 3 IS-IS frames. But assuming
> we use a different multicast address for TRILL IS-IS than layer 3 IS-IS, 
> with the additional safeguard of
> using a different "area ID" (for TRILL, area ID=0), it seems like there 
> would be no danger of confusion.
>
> Perhaps we were concerned about possible unicast of IS-IS frames, like 
> for instance, a PSNP that one might
> send just to the DR? I think I verified with the IS-IS people that there 
> are no IS-IS frames that are unicast.
>
> So why doesn't the following work?
>
> For core IS-IS frames, no encapsulation, but a special multicast address 
> "all-nbr-TRILL-IS-IS" as
> the destination address.
>
> For ESADI, TRILL encapsulation like with ordinary data packets, but 
> having as the destination
> address in the inner Ethernet header a different multicast address 
> "all-ESADI-TRILL"
>
> The advantage of this is that for core TRILL IS-IS, we'd save header 
> room and probably work for
> RBridges to parse IS-IS packets.
>
> Radia
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan