Subject: RE: [Isis-wg] ManualL2Only

From: Les Ginsberg <[email-masked]>
Date: Fri, 19 Oct 2001 12:04:22 -0700

Ken -

Using RFC 1142 as a reference is something I would strongly discourage. It
was an early draft of ISO 10589 - many corrections were made before the 1992
ISO standard was published. Clearly the section you quoted was one of them.
When I accused you of misquoting, I was assuming you were referencing the
1992 spec. Certainly, one should never refer to RFC 1142 as ISO 10589 V1 -
that designation rightfully belongs to the 1992 ISO standard.

I would also go one step further and encourage folks to use the 2001 V2
draft. This includes corrections to the 1992 spec. 

ftp.cisco.com/pub/rfc/ISO/ISO10589v2-2001-07-04.pdf

As for the issue of advertising directly connected reachability for L2-only
circuits in L1 LSPs, I am not in favor of that. L1 routers are supposed to
direct packets destined for addresses "out of the area" to the nearest L2
router. Including L2-only reachability deviates from that model - and I see
no compelling reason to do so.

   Les

> -----Original Message-----
> From: Ken Larmer [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 6:05 AM
> To: Les Ginsberg; Jeff Learman; Koen Vermeulen
> Cc: Isis-wg
> Subject: RE: [Isis-wg] ManualL2Only
> 
> 
> Hi Les,
> 
> 	Please see my comments inline.
> 
> Cheers,
> Ken Larmer
> 
> > -----Original Message-----
> > From: Les Ginsberg [mailto:[email-masked]]
> > Sent: Wednesday, October 17, 2001 10:18 PM
> > To: 'Ken Larmer'; Jeff Learman; Koen Vermeulen
> > Cc: Isis-wg
> > Subject: RE: [Isis-wg] ManualL2Only
> >
> >
> > 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.
> >
> 
> 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 L1 Intermediate System
> 
> xneighbourSystemType L2 Intermediate System and 
> adjacencyUsage Level 2 or
> Level1 and 2.
> 
> 	I believe this is different from the V2 spec?
> 
> > 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.
> 
> 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!
> 
> > 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.
> > >
> 
> Any comments on the above text???
> 
> > >
> > > 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