Re: [Isis-wg] [rbridge] Why is MTU discovery important?

[Hannes Gredler <hannes at juniper.net>]

hi donald,

please see answers inline.

Donald Eastlake wrote:
> > i am terribly sorry but i need to bring up an old question again:
> >
> > why are there separate PDUs for multicast LSPs and SNPs ? -
>
> Answers to that question have been posted several times to the ISIS WG
> mailing list. I gather the answers do not satisfy you...

exactly ... my whole point is that we do not need additional PDUs
for the reasons mentioned in draft-ietf-isis-layer2 (maybe there are
other non explicit written downs reasons - i do not know ...)


specifically:

   [ ... ]
   In the Layer-2 environment, it is expected the join/leave frequency
   of the multicast members will be much higher than unicast topology
   changes.  It is efficient to separate the updates for the group
   membership change information from the remainder of the information
   by placing this information in a separate PDU.  This enables
   reachability information, that would trigger an SPF, to be not
   impacted at all.  Furthermore, during SPF runs, TLVs being on
   different PDUs which do not affect SPF need not be inspected during
   processing.

this justification is not valid as a decision whether to run SPF or not
should be an entire implementation matter.

an implementation typically does figure out during LSP parsing if a SPF is required
or not. the necessary leaf vs. edge optimizations are deployed for years
e.g. when parsing prefixes (read: leaf information) - if just the offered prefix set,
the metric - there is no need to run SPF.

the above statement is actually an alarm signal - a Dijkstra implementation which
is negatively impacted by the number of prefixes or group state in the lsdb is
hopeless broken. we should not engineer protocols to band-aid broken
implementations, right ?

   The choice of a different PDU also opens the LSP-space to another 256
   fragments to carry a large number of groups.  This additional space
   can be used judiciously to carry only multicast information.

we have the lsp-ext draft for increasing fragment count > 256.
do we really think that 375KB of mcast information is not plenty
enough storage ?

> > most implementation keep all sort of internal databases,
> > so practically there is a already a separation between unicast
> > and multi cast - why do we need to change the on-wire representation
> > of multi-ast data (= new PDU) while the same stuff can be carried in
> > vanilla LSPs as well. [ ... ]

> Which draft are you talking about? As far as I know, the additional
> PDUs first showed up in draft-ward-l2isis. Because they were there, I
> put them in draft-eastlake-trill-rbridge-isis and they are now in
> draft-ietf-isis-layer2. But I don't think they have ever been
> mentioned in any TRILL WG draft and I don't off hand recall much
> discussion of them in the TRILL WG.

i am talking about draft-ietf-isis-layer2-00.
i would appreciate a thorough discussions on the points being raised:

i am afraid but just saying "we need additional LSP and SNP PDUs"
to mimikry the same behaviour that sensible implementations do today
(suppress SPF for leaf information) is too little, to less justification.

> > why do we think that app. 375KB of LSP space to store multicast
> > information is not enough, and if so why don't we reuse the LSP-ext
> > draft for adding more space.