Subject: RE: [Isis-wg] ManualL2Only

From: Les Ginsberg <[email-masked]>
Date: Wed, 17 Oct 2001 19:17:49 -0700

The text in both ISO 10589 V1 and V2 is correct. Please see my comments in
line.

   Les

> -----Original Message-----
> From: Ken Larmer [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2001 8:34 AM
> To: Jeff Learman; Koen Vermeulen
> Cc: Isis-wg
> Subject: RE: [Isis-wg] ManualL2Only
> 
> 
> 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.
> 

You have misquoted the text from 7.3.7. It actually states:

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

This text is identical to the text found in V2 which you correctly quote
below.

> 
> 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"
> 

This is not correct.

On a point-point circuit, a single adjacency is formed and the adjacency
usage is set based upon the advertised circuit types (L1, L2-only, L1 and
L2) and whether the neighbors share an area address. If one system is an L1
IS or an L2 IS with circuit type L1-only, then it would set circuit type to
L1 and adjacency usage could only be L1. If both neighbors are L2 ISs and do
not have the circuit set to L2-only, then adjacency usage will be Level 1
and 2. In both cases you would want to advertise this neighbor in your L1
LSP since it is reachable at this level.

It is probably somewhat confusing to talk about "neighborSystemType" since
what is actually advertised in IIH PDUs is "circuit type". While the IS type
bounds the possible values for circuit type, it is not equivalent. A Level 2
IS is assumed to operate as an L1 IS in its area and can therefore use the
circuit for both L1 and L2 traffic (default behavior) or designate the
circuit as L1 only or L2 only. An L1 IS of course, can only use the circuit
for L1 traffic.

On LANs, separate adjacencies are formed for Level 1 and Level 2 and the
adjacency usage can be implicitly set to L1 and L2 respectively. (This is
not explicitly stated in the spec.)

> 
> 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
> >
> >
> > At 02:33 AM 10/16/2001, Koen Vermeulen wrote:
> > >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?
> >
> > 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
> >
> >
> > >Thanks,
> > >Koen
> > >
> > >_______________________________________________
> > >Isis-wg mailing list  -  [email-masked]
> > >http://external.juniper.net/mailman/listinfo/isis-wg
> >
> > _______________________________________________
> > Isis-wg mailing list  -  [email-masked]
> > http://external.juniper.net/mailman/listinfo/isis-wg
> >
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Ken Larmer" <[email-masked]>
Date: Fri, 19 Oct 2001 09:05:24 -0400

Hi Les,

	Please see my comments inline.

Cheers,
Ken Larmer

> From: Les Ginsberg [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2001 10:18 PM
> To: 'Ken Larmer'; Jeff Learman; Koen Vermeulen
> Cc: Isis-wg

Les, here is a cut and paste from RFC-1142 (Integrated IS-IS)

7.3.7 Generation of Level 1 LSPs (non-pseudonode)
The Level 1 Link State PDU not generated on behalf of a pseudonode contains
the following information in its variable length fields.
...
-In the Intermediate System Neighbours option the set of Intermediate system
IDs of neighbouring In
termediate systems formed from:

xThe 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 L2 Intermediate System and adjacencyUsage Level 2 or
Level1 and 2.

	I believe this is different from the V2 spec?

> LSP since it is reachable at this level.

Les, yes you are correct! I was looking at the text in the V1 spec when I
made the above statement. Of course, my proposed text was still wrong! The
V2 spec is correct!

> > subdomain reachable directly via one or more interfaces on

Any comments on the above text???