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

Fri May 28 06:25:50 PDT 2010

> Do you have references
> to minutes or emails for the TRILL WG indicating when we discussed
> this?

Sorry, I do not recall any emails on TRILL WG on this topic. I was also
referring to ISIS WG minutes.

Thanks, Hari

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Erik Nordmark
> Sent: Friday, May 28, 2010 5:44 AM
> To: rbridge at postel.org
> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
> advertising multicast groups?
> 
> On 05/26/10 08:14 AM, Hari Balasubramanian (harih) 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 don't recall such discussion in the TRILL WG. Do you have references
> to minutes or emails for the TRILL WG indicating when we discussed
> this?
> 
> Ayan was referring to ISIS minutes, which is different.
> 
>     Erik
> 
> > 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
> >
> > _______________________________________________
> > 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