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

From: Radia Perlman <[email-masked]>
Date: Wed, 28 Apr 2010 09:42:59 -0700

Re: https://datatracker.ietf.org/doc/draft-ietf-isis-layer2/

In section 2.9.1, 2.9.2, and 2.9.3, it introduces three new PDUs for
IS-IS for carrying the attached multicast groups instead of carrying
this information in the LSP.

The theory for this is that multicast group joining and leaving might
be more dynamic than the rest of the information in the LSP (RBridge
neighbors, basically). Also, the information is "endnode information"
which does not require recalculating SPF.

Because of creating a new type of LSP (section 2.9.1) there is also
introduced new versions of the CSNP and PSNP for acking the new type
of LSP.

---------------

Now my opinion:
I hadn't been paying too much attention to formats, but this seems
more than just formats, and I don't see how it is particularly useful.

The LSP flooding mechanism in IS-IS already has the capability of
independently flooding fragments. So if source of the LSP puts the
multicast stuff (or anything that is more dynamic) into a separate
fragment, it will achieve the same effect, it seems to me.

And it seems complex and wasteful to have to have separate CSNPs and
PSNPs. Especially, imagine a case where there might be just one,
configured, stable multicast group (I could imagine cases where a
multicast group is sufficiently long-lived that the RBridge is
configured to always request it). Carrying it in the base LSP would be
very little overhead, whereas having to put it into a new type of LSP,
and with separate CSNP and PSNP would be complex and a lot more
packets.

If it's deemed important to signal "this LSP fragment does not require
recalculation of SPF" more easily than parsing the TLVs in the LSP, it
seems like we could add a flag to the LSP, which seems far simpler and
less overhead than creating three new LSP types.

So, especially from those that are implementing TRILL, what is your
opinion? Would TRILL benefit from having the multicast group
information advertised and flooded with three new types of PDUs? If
not, would it be useful to request a flag advising the LSP recipient
that  nothing in that LSP fragment requires running SPF (the
information is still there -- but it requires parsing the LSP to
figure that out)

Radia
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: James Carlson <[email-masked]>
Date: Wed, 28 Apr 2010 13:41:21 -0400

> less overhead than creating three new LSP types.

I'm not really invested in the whole multicast distribution scheme, so I
don't feel strongly about this, but I don't think the above will work
quite right.

If I get an LSP fragment that has the "don't recalculate on account of
me" bit set, how do I really know if I need to recalculate?  If I'm
replacing an older LSP in my database, it could be that I somehow missed
an intervening fragment update that said "yes, really do recalculate
now."  If I did, then I'd potentially fail to recalculate when I need to.

I don't see how I could trust such a bit or how it'd work with the usual
sorts of LS DB designs.  However, if the TLVs are carried separately,
it's much easier to say "this entire class of LSPs never affects
topology in any way, so there."

> information is still there -- but it requires parsing the LSP to

Multicast group information will likely change quite frequently,
especially on non-trivial networks.  Whether carrying that through IS-IS
or through more classical bridge IGMP/MLD "snooping" mechanisms is the
right answer, I don't think I have much of an opinion.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 28 Apr 2010 11:37:01 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of James Carlson
> Sent: Wednesday, April 28, 2010 10:41 AM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
> advertising multicast groups?
> 
> Radia Perlman wrote:

Indeed.
The notion that a receiver will/will not take action on a received LSP
w/o examining the content can only serve to introduce interoperability
issues. It is quite fine to make recommendations as to how TLV
information SHOULD be organized (and ISO 10589 does do that) but
implementation experience shows that following such recommendations is
not as straightforward as it sounds - particularly in cases similar to
what James has referred to where multiple LSP updates are required to
provide all of the revised advertisements. Further, if an implementation
deviates from the recommendations when generating its LSPs the
consequences today are only some inefficiency. The proposal here would
actually cause failures - and introduce the distinct possibility that
not all routers are processing  the complete LSP database.

IMO this per LSP flag is a dangerous idea and should NOT be considered.

   Les

---

From: James Carlson <[email-masked]>
Date: Wed, 28 Apr 2010 14:55:12 -0400

Radia Perlman wrote:
> On Wed, Apr 28, 2010 at 10:41 AM, James Carlson
> <[email-masked]> wrote:
> 
> Re: James pointing out that sequence number n+1 of fragment x might
> not require SPF, but sequence n (which was missed) does:
> 
> Only the most recent fragment is relevant. So I don't think it can
> happen that you should have done SPF based on fragment n, and get
> tricked by having fragment n+1 say you don't need to.

Either I'm confused (which is certainly possible ;-}) or I'm just not
following how that will work.

Say my LSDB currently has sequence number N for some fragment, and I've
calculated a tree based on that (and all the other fragments, of course).

Something happens, and I miss sequence N+1, which would have required me
to recalculate.  But I missed it, so my tree is still based on N.

Now comes N+2.  It tells me not to bother recalculating, so I don't.
This leaves me with a tree based on (N), while everyone else has one
based on (N+1) or (N+2).

This could go on almost indefinitely ... with me thinking that I have
the latest sequence number at all times, and yet having a really out of
date tree because I missed the intervening signal to recalculate.

---

From: Radia Perlman <[email-masked]>
Date: Wed, 28 Apr 2010 11:43:27 -0700

Radia

---

From: Radia Perlman <[email-masked]>
Date: Wed, 28 Apr 2010 12:18:33 -0700

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.

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.

Radia

---

From: Radia Perlman <[email-masked]>
Date: Wed, 28 Apr 2010 12:01:15 -0700

Well, the only case that could cause a problem is if R1 transmits an
LSP fragment with the flag set incorrectly for that fragment, causing
lazy RBs not to do SPF right away, and others that actually parse the
packet to do SPF immediately. (I don't believe the case James
mentioned...where an earlier sequence number of the same fragment
required SPF but the latest one does not...is a problem at all). But
having an implementation send incorrect information in LSPs, or
violate any portions of the spec, could cause all sorts of problems.

I don't think the flag is necessary (the information is already there
implicitly by checking to see if there are any TLVs included that
require SPF calculation), but it seems far simpler and less overhead
than introducing 3 new PDU types (which I also do not think is
necessary).

I'd be happy with not having the flag, and since 10589 already
recommends putting more volatile things into separate fragments, not
doing anything at all...just putting the multicast group TLVs into
LSPs as the base TRILL protocol spec specified.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 28 Apr 2010 15:21:22 -0400

Hi,

On Wed, Apr 28, 2010 at 2:37 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:
> ...

I'm also a bit dubious about the LSP fragment flag. It seems to me much
better to look at the TLVs.

This is all about optimization. Presumably, if you don't care about that,
you can always recalculate everything on getting any update. If you care
more, you can only recalculate something if you get one or more TLVs the
might require it to be recalculated. If you care even more, you can be
increasingly clever about recalculating something only if you get one or
more TLVs that actually represent a change that does require recalculation.

Different TLVs affect different things. Some would affect SPF calculations
for unicast forwarding. Others would affect the set of distribution trees to
calculate. Still others would affect the optional pruning of distribution
tree propagation of frames.

Seems to me that you have to check on what TLVs you are getting and if they
have changed to do a good job here and that the help provided by MGROUP
probably isn't worth the added complexity...

Thanks,
Donald

  Les

---

From: James Carlson <[email-masked]>
Date: Wed, 28 Apr 2010 15:48:37 -0400

> that fragment because of going down, or being moved to another

Exactly.

> multicast groups is relegated to its own fragment, then this wouldn't

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.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 28 Apr 2010 15:24:28 -0400

Jim,

I think you are assuming LSP fragments with a flag dynamically based on
whether some TLVs have actually changed between version n and n+1 while
Radia was thinking of a flag based on the *type* of TLVs included, which is
presumably the way TLVs are sorted between the standard LSP and the MGROUP
LSP.

(In this and my previous messages, read "TLV or sub-TLV" for where I've said
"TLV".)

Thanks,
Donald

---

From: Radia Perlman <[email-masked]>
Date: Wed, 28 Apr 2010 13:33:48 -0700

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

---

From: JR Rivers <[email-masked]>
Date: Fri, 30 Apr 2010 10:19:57 -0700

For what it's worth, I think this is a great proposal.

JR