[rbridge] encoding of TRILL IS-IS frames
Dinesh G Dutt
ddutt at cisco.com
Fri Oct 10 17:10:52 PDT 2008
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.
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
> 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.
> rbridge mailing list
> rbridge at postel.org
We make our world significant by the courage of our questions and by
the depth of our answers. - Carl Sagan
More information about the rbridge