Subject: RE: [Isis-wg] Proprietary / Private TLV numbers?

From: mike shand <[email-masked]>
Date: Fri, 12 Jul 2002 16:04:33 +0100

I'm not sure that triggering SPF is the main (or only) concern. An 
implementation can always choose to only re-run SPF when information which 
would affect the outcome of the SPF has changed (although arguably it could 
use considerable resources deciding that it need not bother).

The sheer quantity of information in the LSPs which may require storing and 
flooding is also an issue, and really the one which concerns me most.

But aside from that, I'm not sure the draft need go into so much detail. I 
think it would suffice simply to say "don't do it".

         Mike

At 15:43 12/07/2002 +0100, Philip Christian wrote:

>This is my first thought on the problem of abuse of LSPs.  As normal
>I've probably written too much, but it will give you guys something
>to chew on and improve.  Comments?
>
>Philip
>
>Appropriate use of proprietary TLVs.
>
>    IS-IS is a highly scalable routing protocol.  Networks have been
>    deployed containing many hundreds of ISs in a single level-1 area or
>    level-2 subdomain.
>
>    One contributing factor to this scalability is that an IS needs to
>    advertise its links and metrics only when it starts up, or when its
>    local connectivity changes in some way.  In this way the amount of
>    routing information traversing an IS-IS routed network is normally
>    very low.  Unlike some other routing protocols, there is no periodic
>    transmission of routing information, except for LSP timeout which is
>    very infrequent.
>
>    A downside of this is that every time one IS does advertise a new
>    state of connectivity, every single IS in the network will need to
>    recalculate all of its routes, although there are certain
>    optimisations that reduce this load.
>
>    An unfortunate consequence of an IS sending out new information in a
>    proprietary TLV in an LSP is that it causes every other IS in the
>    level-1 area or level-2 subdomain to recalculate all of its routes,
>    whether an IS understands that particular TLV or not.  If many ISs
>    in a large network were to frequently send out new LSPs then all of
>    the ISs might spend most of their time recalculating routes, which
>    would reduce scalability and stability considerably.
>
>    Therefore an IS SHOULD NOT regularly transmit information in a
>    proprietary TLV in an LSP.  Proprietary TLVs in LSPs SHOULD NOT be
>    used except for the following (or similar) purposes:-
>
>    1. For information about an IS that is constant or very rarely
>       changed.
>
>    2. For information that is related to topology, in which case the
>       topology change would result in a new LSP anyway.  In this case
>       the topology change SHOULD trigger the proprietary TLV to be
>       updated at the same time as the normal LSP update.  This results
>       in all of the other ISs in the network performing only one SPF run
>       rather than two.
>
>    Proprietary TLVs in LSPs MUST NOT be used as a generalised
>    communication channel.
>
>    Proprietary TLVs that are used in Hello and SNP PDUs are not flooded
>    throughout a network, and do not result in route recalculations
>    (unless they are part of a feature that enables or disables
>    adjacencies).  Therefore the proprietary TLV MAY be used more freely
>    in Hello and SNP PDUs.

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Fri, 12 Jul 2002 11:16:18 -0400

I agree, Philip.  When you go into tha much detail, you're bound
to say stuff that isn't technically accurate ;-)  On the other hand,
it really helps when there's enough explanation so that everyone
understands the issues, and my first post certainly wasn't sufficient
in that respect.  It's a matter of balance.

Let me take a crack at it this weekend.

Regards,
Jeff

At 11:04 AM 7/12/2002, mike shand wrote:
>I'm not sure that triggering SPF is the main (or only) concern. An implementation can always choose to only re-run SPF when information which would affect the outcome of the SPF has changed (although arguably it could use considerable resources deciding that it need not bother).
>
>The sheer quantity of information in the LSPs which may require storing and flooding is also an issue, and really the one which concerns me most.
>
>But aside from that, I'm not sure the draft need go into so much detail. I think it would suffice simply to say "don't do it".
>
>
>        Mike
>