Robert Raszuk wrote:
As Dave points out there is "significant amounts of shared code" between L3 ISIS & TRILL-ISIS and IMHO it does make sense to keep isis-wg in the loop.
hehe, i was playing devils advocate here ;-) ... i'll find it worry some that the "significant" portion is shrinking for no good reason ... i am terribly sorry but i need to bring up an old question again: why are there separate PDUs for multicast LSPs and SNPs ? - most implementation keep all sort of internal databases, so practically there is a already a separation between unicast and multi cast - why do we need to change the on-wire representation of multi-ast data (= new PDU) while the same stuff can be carried in vanilla LSPs as well. the latest version of the draft does not contain answers on that matter, although being promised ... why do we think that app. 375KB of LSP space to store multicast information is not enough, and if so why don't we reuse the LSP-ext draft for adding more space. /hannes
Robert Raszuk wrote:It seems to me just like section 4.2.4.3 Hello Contents of the above draft says there is sufficiently large number of optional information usable for TRILL which could be added to today's ISIS header that perhaps it may make sense to just define it as separate TRILL-Hello msg. My point was that in the same time the padding issue would be solved yet a lot of already available code for L3 ISIS could be reused.so we have now separate L2-encaps, separate IIH, separate LSP and separate SNP PDUs- all of that with changed semantics ...sounds to me much more like a new protocol, than something vendors can integratein their existing IS-IS implementation.if we want to further walk down that road, we should name the beast TRILL-something and drop the isis-wg groups involvement, since this is not IS-IS any more./hannes