Subject: Review of ISO 10589 Second Edition Draft

From: "Lester Ginsberg" <[email-masked]>
Date: Fri, 9 Oct 1998 18:06:44 -0700

Good people -

I have had the opportunity to review the ISO 10589
Second Edition Draft over the past few weeks. I have
prepared a review document which is now available at:

ftp://ftp.juniper.net/pub/isis/isis_review.doc

While I welcome all comments about my review, what is
more important at the moment is the "big picture" i.e.
whether the document in its current form is suitable for
approval as an international standard. I think the answer
clearly is no. If this group collectively agrees, then
we should provide that consensus input to the appropriate
standards group(s) so that the Draft, which is now
scheduled to be voted on at the December WG7 meeting, is
not approved in its current form.

There will then be additional time to provide input to
change the document appropriately.

Enjoy!

  Les

-- 

  -------------------------------------------------------------------
    VERTEL, The TMN Company  [ formerly Telegenics / Retix ]
  -------------------------------------------------------------------
Les Ginsberg                     "Before enlightenment, chopping wood
[email-masked]             and drawing water. 
Vertel                            After enlightenment, chopping wood 
21300 Victory Blvd                  and drawing water." 
Suite 1200
Woodland Hills, Ca. 91367
818 227-1405 (Direct Dial)
818 227-1400 (Main)
818 888-0725(FAX)

---

From: Pedro Marques <[email-masked]>
Date: Fri, 9 Oct 1998 18:11:52 -0700 (PDT)

>>>>> "Lester" == Lester Ginsberg <[email-masked]> writes:

    Lester> Good people -

    Lester> I have had the opportunity to review the ISO 10589 Second
    Lester> Edition Draft over the past few weeks. I have prepared a
    Lester> review document which is now available at:

    Lester> ftp://ftp.juniper.net/pub/isis/isis_review.doc

Can you please provide an ascii text version ?
I've no means to read your document.

Alternativly i can print postscript or pdf but it would be really nice
just to be able to read it online.

regards,
  Pedro.

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 11 Oct 1998 15:46:36 -0400

> change the document appropriately.

Lester, spent (finally) some time reading your comments & the newest
spec that Tony requested from the editor. I only went through the
crucial link-state parts, not spending much time on partition repair and
less-used features. First, let me say that I think you did a pretty
thorough job IMHO of going over the stuff in the short time available.
The general conclusion you draw is unfortunately pretty accurate, if
this thing gets approved as a spec, it's not implementable and will draw
a serious amount of corrigendums after it (but then again, what's new
;-)  Let me go into more specifics and throw couple of additional points
into your comments that caught my eye on a brief walk-through:

   * 7.2 Decision Process, output, bullet 6, should proably say instead
     of "... within the area with lowest system ID ..." the following
     "...within the area which is attached, supports partition and has
     the lowest system ID .."
   * 7.2.3 Broadcast subnetworks: The new sentence saying "using the LAN
     ID field in LAN IIH PDUs on each broadcast subnetwork" seems to me
     to imply that you send the same LAN ID on all broadcast circuits
     you are attached to.
   * 7.2.4 Before "a) The setting of the AttachedFlag bit" we'd need
     "before a) The setting of the P bit". Compare 7.3.4.2
   * figure 5 changed. seems ok to me except that now R and H seem to be
     both attached to Y and P seems not to be attached. kind of
     confusing if you apply Occam's razor, a simpler example would do,
     e.g. dropping I and H's connection to L2 would not hurt, neither
     taking I out completely.
   * 7.2.11.3 as you point out, is basically FUBAR. It seems it's a
     meltdown of election and virtual link creation.
   * your comment on 7.3.4.1 is very interesting of course. Could you
     send to this mailing list the whole DR list for 10589 you mention
     and the note that SIF submitted ?  I personally think that by
     forcing (when inserting a new interface with a small NPDU) the max
     size for the whole domain to be reconfigured is rather nasty. Are
     there any efforts to specify a fragmentation ? Although that would
     break the protocol  as it stands today IMHO. I personally think
     that enapsing ISIS with fragmentation into e.g. IP or 8473 (very
     much OSPF like) is the best practical solution for this malady of
     meanwhile sizable number of configurable parameters floating around
     in this respect.
   * The slips in table 1, 7.3.17.6 and 7.3.13 makes the spec useless.
     As as side comment on the new table, I personally like the "action
     on reception" text better, it makes for easier implementation and
     less arguments, even when table 1 is around.
   * 7.3.20.1.2 should not talk about "reported value is newer" but
     rather "LSP entry", it made sense in the old spec, reads awkward
     now
   * 7.3.22 b) in front of NOTE is too much
   * 8.4.3.2 needs probably a 4) saying that if the IS is L2 and the
     circuit is L2manual, then the adjacency should be L2 only.
     Generally, couple of things have been ommitted (e.g. g)) which were
     right and the section suffered. It could use a few words on
     behavior when e.g. type of remote system changes or circuit is set
     to manualL2only as well.
   * 9.7 says that LSP ID is the identity of the source of the Link
     State PDU which it's not (or only the first two fields)
   * 9.4 replaced "Any codes in a received LSP that are not recognised
     are ignored and passed through unchanged" with "Any codes in
     received PDU that are not recognised shall be ignored". IMHO, the
     previous was better ..

of course here lots of things come to my mind that would make sense to
fix on the spec compared as it is used today given that it seems to
change that much, some of which are:

   * maxAge is not an architectural constant in deployments
   * minimumPtPtTransmissionInterval equivalent to
     BroadcastLSPTransmissionInterval
   * split all the intervals per level

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 11 Oct 1998 19:30:34 -0400

> change the document appropriately.

ouch, hit the send button too early on the last mail, there were couple
more things in both missing and a conclusion ;-)

some more on the document

   * 8.4.3.2 "When the local system either becomes or resigns as Lan
     Level 1 DIS, the IS shall generate a
     IANLevel2DesignatedIntermediateSytemChange ...", should be
     "IANLevel1DesignatedIntermediateSytemChange"
   * did anybody come with a DR for 9.8 packet format when the LSP
     entries are not sorted properly  ? Given e.g. implementations  that
     will ignore entries that are not sorted (which could be caused by a
     bug or careless vendors easily), it seems to me, convergence will
     be broken or extremely slow (you'd always pick the first couple
     sorted ones or one only).  Additionally, the spec only talks about
     the option fields within the variable length fields, if you have
     multiple of variable length fields, they should be sorted as well.
     Went through that and had a hard time catching the bug. Different
     possibilities exist, one is being proactive & accept anything ,
     then as Paul Koning once pointed out, it makes no sense to put the
     restriction in the spec ;-), the other possibility would be to
     punish the guy (e.g. drop adjacencies) actively which goes against
     the rule that you shouldn't make the network change control
     behavior based on some "intelligence", the least would be to at
     least generate an event to the management dudes.
   * went through path computation (I know it's only informative but
     it's kind of very important) and found a couple of interesting
     things:
        o d) Go to step 1 seems superfluous
        o I expected meanwhile that in the description of the Attached
          Flag there will be something indicating that a L2 shouldn't be
          attached if it has an  overload or path computation would
          protect against picking such a node as closest L2.  I couldn't
          find either one. Same's true for partition designated router.
          Maybe it's just my paranoid brain but what if an L2 gets
          picked as closest and his L2 forwarding database is partial
          only ?
        o I think that the way path computation has been rewritten, it
          will not interoperate with anyone implementing the old
          version. The decisive point is h) being removed & the
          additional text that I tried to understand and seems to
          indicate that you don't consider pnode LSPs from any of your
          directly attached broadcast circuits. The old spec was
          initializing the TENT with _all_ the IS neighbor entries from
          such pnode, which could be more than adjacencies visible to
          the node itself. The new spec is ommiting that. In case
          someone sending me packets is running the algorithm over the
          pnode and finds more neighbors I have that I believe to have
          ;-) then persistent loops can be formed. It's unlikely but
          possible (look at 8.4.4). Generally, pretty much anything in a
          path computation within the TENT loop that has an "IF my stuff
          THEN" will break it ...
        o step 2 b) and c) "do nothings" were never very clear, maybe
          "go to step 1" would help ?

We could probably keep on going. Finally, I was far too lazy to look for
typos actively as you did but after scanning through your stuff found
that your document in the editorial has a typo as well ;-), namely you
wrote 7.2.6.1 Legal Paths but it's 7.2.6.2 Legal Paths .

Overall my private conclusion: things are probably too broken to
implement them even with a lot of good will of this proposed spec. I
don't know how much OSI cares about that but I would propose to
disregard this version for the moment in our work and wait what comes
out from the comments submitted. They probably have some way to go to
fix up all this stuff ...

        thank you

        --- tony