[rbridge] Do people prefer new ISIS PDU types for advertising multicast groups?

Wed May 26 09:45:20 PDT 2010

It was never discussed on the TRILL list, and a lot of people
(including me) assumed that the l2-ISIS spec was just defining syntax
of the fields explicitly called out in the TRILL protocol spec, which
lists all the fields to be included in Hello and LSP.  A design issue
like that should be discussed on the TRILL mailing list and, if there
were a consensus in TRILL for something like that, it should be
covered in the TRILL protocol spec (in addition to having the syntax
in the l2-ISIS spec).

So, definitely I'm sorry I didn't pay more attention to that spec,
but my understanding was that the fields TRILL needed were explicitly
listed in the TRILL protocol document, and so I assumed the l2-isis
document was just syntax, so I could safely ignore it.

Radia

On Wed, May 26, 2010 at 8:14 AM, Hari Balasubramanian (harih)
<harih at cisco.com> wrote:
> I agree with Ayan's comments here. It has been the understanding of early implementers of TRILL spec that the pros and cons of using new ISIS PDU types for advertising multicast groups  were discussed and  it was agreed to use new PDU types as early as April 2009. It has been more than an year since such an understanding was reached and it is concerning that the issue is being opened again. Are there any new concerns that are being raised now that did not come up during the discussions last year?
>
> I understand the early implementers of any protocol, especially before standardization, should be well aware of the risk of some churn in the specs, based on wider comments etc. But I believe it is not unreasonable to hope that the approaches on which a consensus was developed will substantially retain the structure as per the consensus, especially the ones that have been made an year or more back.
>
> Thanks, Hari
>
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
>> Behalf Of Ayan Banerjee (ayabaner)
>> Sent: Tuesday, May 04, 2010 11:09 PM
>> To: Radia Perlman; James Carlson
>> Cc: rbridge at postel.org
>> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
>> advertising multicast groups?
>>
>>
>> I believe that we had substantial discussion on the merits of this
>> approach.
>> I have attached a pointer to the meeting minutes on this after IETF-73
>> -
>> http://tools.ietf.org/wg/isis/minutes?item=minutes73.html . There was
>> also a
>> lot of discussion on this during the Feb/March/April 2009 timeframe in
>> the
>> IS-IS WG mailing list on this.
>>
>> In summary, the reasons outlined during those discussions are:
>> - Separation is desired since the join/leave frequency
>>   of the multicast members will be much higher than unicast topology
>>   changes.
>> - Opens up space for additional fragments to improve scalability
>>   and carrying capacity of the base protocol
>> - Operational convenience of having separate unicast and
>>   multicast information.
>> - Use of other extensions to the protocols, like Extended LSP,
>>   Multi-Instance support etc, just fall in place.
>>
>> This additional PDU introduces very minimal complexity into the
>> process. The
>> update process of MGROUP-PDU follows the exact same design/update flow
>> as
>> the regular PDU. This flow is well understood and other than just
>> maintaining a parallel database, there is really not much of a concern
>> here.
>>
>> This PDU has been out there in the WG for 18 odd months now. I am a bit
>> concerned about changing things at this juncture, when we should be
>> really
>> wrapping things up.
>>
>> Thanks,
>> Ayan
>>
>>
>> On 4/28/10 1:33 PM, "Radia Perlman" <radiaperlman at gmail.com> wrote:
>>
>> > But I still prefer not doing anything; no flag, no new PDU types.
>> >
>> > IS-IS as originally designed for DECnet/CLNP had endnode information
>> > in LSPs. The same argument could have been made back then -- that
>> > there should be a different type of LSP for the endnode information
>> > because that wouldn't trigger SPF, and would be more volatile.
>> >
>> > Merely recommending that the more volatile, non-SPF-producing
>> > information go into separate fragments, seems solution enough. Any RB
>> > not following that will cause a bit of suboptimality, but no other
>> > problems.
>> >
>> > Radia
>> >
>> >
>> >
>> > On Wed, Apr 28, 2010 at 12:48 PM, James Carlson
>> > <carlsonj at workingcode.com> wrote:
>> >> Radia Perlman wrote:
>> >>> Re: James question below
>> >>>
>> >>> Ah. I was assuming that you'd only set the flag if the fragment
>> only
>> >>> contains endnode information, and that fragment number NEVER
>> contained
>> >>> anything but endnode information.
>> >>>
>> >>> I think you were assuming I was recommending you'd set the flag if
>> the
>> >>> adjacencies reported there haven't changed, or that previous
>> sequence
>> >>> numbers of that fragment contained adjacencies that got removed
>> from
>> >>> that fragment because of going down, or being moved to another
>> >>> fragment.
>> >>
>> >> Exactly.
>> >>
>> >>> I was recommending setting the flag only if the only TLVs in the
>> >>> fragment are endnode type information (which in TRILL would only be
>> >>> multicast groups), and that fragment n *never* contained anything
>> but
>> >>> endnode information (though it's not a problem if those adjacencies
>> >>> get moved to a different fragment...it's just a problem if they go
>> >>> away and their absence is SPF-relevant information). If advertising
>> >>> multicast groups is relegated to its own fragment, then this
>> wouldn't
>> >>> be a problem.
>> >>
>> >> Based on what I remember in Quagga, I think that might be hard to
>> >> achieve there, but I can imagine that someone who tracks fragment
>> >> contents over time more carefully could do this.
>> >>
>> >> Thanks; I get it now.  I'm not sure where (in what implementation)
>> it'd
>> >> be workable, but at least I understand how it'd function.
>> >>
>> >> --
>> >> James Carlson         42.703N 71.076W
>> <carlsonj at workingcode.com>
>> >>
>> >
>> > _______________________________________________
>> > rbridge mailing list
>> > rbridge at postel.org
>> > http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>