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

[Anoop Ghanwani]

I agree.  We should not make any changes unless they
are absolutely needed.

Anoop

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Radia Perlman
> Sent: Wednesday, April 28, 2010 1:34 PM
> To: James Carlson
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
> advertising multicast groups?
> 
> 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