Subject: [Isis-wg] L2 LSP Area Address TLV

From: "Ken Larmer" <[email-masked]>
Date: Tue, 12 Jun 2001 12:12:04 -0400

Hi,

	I am in doubt about the use of the L2 LSP Area Address TLV?

ISO-10589-06n1704 states the following:

7.3.9 Generation of level 2 LSPs (non-pseudonode)

-	In the Area Addresses option — the set of partitionAreaAddresses for this
intermediate system as described in 7.2.10.3

7.2.10.3 Computation of partition area addresses

For systems which do not implement partition repair, the value of
partitionAreaAddresses is identical to the value computed for areaAddresses
as described in 7.2.11.

7.2.11 Computation of area addresses

A Level 1 or Level 2 Intermediate System shall compute the values of
areaAddresses (the set of area addresses for this Level 1 area), by forming
the union of the sets of manualAreaAddresses reported in the Area Addresses
field of all Level 1 LSPs with LSP number zero in the local Intermediate
system’s link state database.

NOTES

18 This includes all source systems, whether currently reachable or not. It
also includes the local Intermediate system’s own Level 1 LSP with LSP
number zero.

7.1.5 Manual area addresses

...Each level 1 IS distributes its manualAreaAddresses in its Level 1 LSP’s
Area Addresses field, thus allowing level 2 ISs to create a composite list
of all area addresses in use within a given area. Level 2 ISs in turn
advertise the composite list throughout the level 2 subdomain by including
it in their Level 2 LSP’s Area Addresses field, thus distributing
information on all the area addresses associated with the entire routeing
domain. ...

7.2.9.2 Setting the attached flag in level 2 intermediate systems

When executing the level 2 decision process for each supported metric, level
2 IS shall ascertain whether or not it can reach any destinations outside
its area using that metric.  The IS considers itself attached if either:

a)	it can reach at least one other area using the coresponding routeing
metric, or
b)	it has at least one enabled reachable address prefix with the
corresponding metric defined.

Otherwise the IS considers itself not attached.

END OF ISO-10589 REFERENCES:

	What I am seeing on a well known implementation of Int IS-IS is that when
an IS has no L1 adjacencies, the L2 LSP being generated does not contain the
Area Address TLV. The spec states that an LSP should be generated but not
transmitted unless it has an adjacency! So there should always be a L1 LSP
number = 0 for each IS with IS-type = L1 or L1/L2.

1. Is this the correct behavior or should the area address TLV always be
present in an L2 LSP?
2. What is the Area Address TLV used for when contained within a L2 LSP? I
can think of the following two purposes:
	a Calculation of NSAP based routes and subsequent forwarding of CLNS
packets.
	b. Determining if an IS is connected to another L2 area as stated above?

So, should each L2 LSP contain an Area Address TLV regardless of the L1
adjacencies it possesses. If not, I would think (as I have observed) this
would break the rules for determining when to set the Attached bit!

Cheers,
Ken Larmer

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Tue, 12 Jun 2001 18:09:15 +0100

Ken,
         While what you describe is the "correct" behaviour, there are some 
advantages to not advertising the area addresses of an isolated L1 router, 
since this give some rudimentary protection against area partitioning. The 
thought is that there is probably some other larger portion of the L1 area, 
and not advertising the area address for this stub, prevents traffic for 
the area being erroneously directed to this sub-functional router.

Of course if this really is the ONLY router in the L1 area, then you might 
actually
  want the traffic.

I think most well known IS-IS implementations probably have a way to turn 
off this feature if required.

         Mike