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

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

At 16:36 12/07/2002 +0100, Philip Christian wrote:

>Excuse my ignorance on this, but is it normal practice (or even mandatory) 
>for an IS to store the old LSP when a new one comes along?

No.

>  Presumably it holds it till it times out?

Only the most recent

>Therefore sending a big TLV is bad.
>Sending a TLV frequently is bad.
>Sending a big TLV frequently is bad^2 ?
>
>Is that about right?

One reason using up lots of space is bad is because we are somewhat limited 
to about 255*1500 bytes per systemID. If someone decided to generate lots 
of very large private TLVs, this would be a bad thing (but only for the 
router doing it).

However,  all the other routers would have to have memory space to store them.

And if you send them frequently, you would use up a fair amount of link 
bandwidth in flooding all these LSPs.

The point is that the idea of these private TLVs is so that you can 
implement some cunning enhancement to routing, perhaps using a few bytes, 
probably not even changing it frequently.

What we want to discourage is using this technique to implement a 
generalised reliable multicast service usable by an application. A 
mis-design like that could end up sending several thousand bytes per 
second. That is emphatically NOT what IS-IS should be used for.

But I really think a note along the lines of "be sensible" is all that is 
required.

         Mike

>Thanks, Philip
>
>-----Original Message-----
>From: Jeff Learman [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Friday, July 12, 2002 4:16 PM
>To: mike shand
>Cc: Christian, Philip [HAL02:GI50:EXCH]; [email-masked]
>Subject: RE: [Isis-wg] Proprietary / Private TLV numbers?
>
>
>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
> >
> >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: Alex Zinin <[email-masked]>
Date: Sun, 14 Jul 2002 13:56:14 +0900

Saturday, July 13, 2002, 12:58:46 AM, mike shand wrote:
...
> second. That is emphatically NOT what IS-IS should be used for.

Amen!

Alex