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

[Ayan Banerjee]

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