Subject: [Isis-wg] ManualL2Only

From: Koen Vermeulen <[email-masked]>
Date: Tue, 16 Oct 2001 08:33:16 +0200

Hello,

Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an
explicit rule whether or not to include the network address
of a manualL2only-enabled interface in the L1 LSP generated
by a L1/L2 IS.
Somebody has some ideas/good reasons for not including
the address of that manualL2only interface in L1?

Thanks,
Koen

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

---

From: Jeff Learman <[email-masked]>
Date: Wed, 17 Oct 2001 10:19:39 -0400

>the address of that manualL2only interface in L1?

Without consulting the specs, I can say that it doesn't make
sense to include such an adjacency in the L1 LSP.  If you do,
then when you run SPF, you will either use "inadmissible"
local knowledge when running SPF (thereby creating a different
topology than other ISs) or else you won't heed the L2-only
nature of the link and will forward L1 traffic on it.

For example:

  A --- B ==== C ---- D
  |                   |
  E -- F -- G -- H -- I

where all are in the same area, but the link between B and C
is L2-only.  If A wants to send data to D, it will send it to
B.  If B heeds the l2-only property, it would send it back to A.

Note that B runs the SPF using the same data as everyone else:
the LSDB.  It uses its adjacency database also, true, but only
to preload "tent" (or is it "paths", it's been a while).

B needs to advertise links consistently with how it would use
them itself, so that the area topology is identical for all ISs
in the area.

Regards,
Jeff

---

From: "Ken Larmer" <[email-masked]>
Date: Wed, 17 Oct 2001 11:33:31 -0400

Hi Koen,

	I found the following conflicting references.

ISO-10589 V1 states the following:

-In the Intermediate System Neighbours option the set of Intermediate system
IDs of neighbouring In
termediate systems formed from:

The set of neighbourSystemIDs with an appended zero octet (indicating
non-pseudonode)
from adjacencies in the state Up, on circuits of type Point-Point, In or
Out, with

xneighbourSystemType L1 Intermediate System

xneighbourSystemType L2 Intermediate System and adjacencyUsage Level 2 or
Level1 and 2.

ISO-10589 V2 states the following:

7.3.7 Generation of level 1 LSPs (non-pseudonode)

-	In the Intermediate System Neighbours option - the set of Intermediate
system IDs of neighbouring Intermediate systems formed from

.	The set of neighbourSystemIDs with an appended zero octet (indicating
non-pseudonode) from adjacencies in the state "Up", on circuits of type
"ptToPt", "staticIn", or "staticOut", with

x  neighbourSystemType "L1 Intermediate System"

x neighbourSystemType "L2 Intermediate System" and adjacencyUsage "Level 1"
or "Level 1 and 2".

	I believe that this section should read as follows:

7.3.7 Generation of level 1 LSPs (non-pseudonode)

-	In the Intermediate System Neighbours option - the set of Intermediate
system IDs of neighbouring Intermediate systems formed from

.	The set of neighbourSystemIDs with an appended zero octet (indicating
non-pseudonode) from adjacencies in the state "Up", on circuits of type
"ptToPt", "staticIn", or "staticOut", with

x  neighbourSystemType "L1 Intermediate System"

RFC-1195 states the following for the IP Internal Reachability Information
TLV for both L1 and L2 LSPs.

IP Internal Reachability Information -- IP addresses within the routing
domain reachable directly via one or more interfaces on this Intermediate
system.

	I believe this should read as follows for L1 LSPs

IP Internal Reachability Information -- IP addresses within the L1 routing
subdomain reachable directly via one or more interfaces on this Intermediate
system.

Cheers,
Ken Larmer
CommSense Networks
www.commsense.net

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jeff Learman
> Sent: Wednesday, October 17, 2001 10:20 AM
> To: Koen Vermeulen
> Cc: Isis-wg
> Subject: Re: [Isis-wg] ManualL2Only
>
>