Subject: [Isis-wg] ISO ballot

From: Tony Przygienda <[email-masked]>
Date: Fri, 13 Oct 2000 09:19:29 +0200 (MEST)

Following ballot from ISO for the working group. I honestly tried
to convert the enclosed word to PDF first but mickey-soft word 
just died repeatedly on me so I just added the ZIP containing 
version 2 of the spec and the attached ballot. I know it's 
humongeous and some people downloading through slow phone
lines will hate me but I couldn't think of a better way to 
get it out. 

Looks like the ballot is open to the whole working group 
so everybody goes ahead and posts input to the list and 
Tony & me will summarize to ISO I guess ...

	thanks 

	-- tony

-------------------------------------------

Telecommunications and Information
Exchange Between Systems

ISO/IEC JTC 1/SC06 N 11704

DATE:  2000-09-20

REPLACES

DOC TYPE:
Text for CD ballot or comment

TITLE:
ISO/IEC FCD 10589, Information technology – Telecommunications and
information exchange between systems – Intermediate system to
Intermediate system intra-domain routeing information exchange protocol
for use in conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)

SOURCE:
Project Editor (M. Bartell)

PROJECT:

STATUS:
Per SC 6 Prague Resolution 6.7.5, this text is circulated for FCD ballot
closing 2001-02-15 to allow IETF input to the process so that extensions
for IETF requirements can be included as ballot comments.

ACTION ID:  LB

DUE DATE:  2001-02-15

DISTRIBUTION:  P & L Members; SC Chair; WG Conveners and Secretaries

MEDIUM:

DISKETTE NO.:

NO. OF PAGES:  175

ISO/IEC JTC 1/SC 6 Secretariat
ANSI, 11 W. 42nd Street, New York, NY 10036, USA
Tel:  +1 212 642 4992;  Fax:  +1 212 840 2298;  E-mail:
[email-masked]

---

From: Mike Shand <[email-masked]>
Date: Mon, 16 Oct 2000 15:44:18 +0100

>Tony & me will summarize to ISO I guess ...

Oh dear oh dear oh dear. Firstly, let me congratulate the new editor(s) on 
a good job of reconstructing the document and applying the edits.

Unfortunately some of those edits as documented by the previous editor are 
ill conceived to say the least. The main problems focus around section 
7.3.16.   In particular SC6 N10323 DR 15, resulting in the new 7.3.16.4 is 
complete garbage. It results from a misunderstanding of the operation of 
the protocol, and requires some intuitive knowledge by the router as to 
whether an LSP is from an old instanciation. The bug it is trying to fix 
does not exist and the fix introduces a bug "it shall optionally perform". 
We should leave the original text.

Similarly the infamous table 1 on that page is wrong. If X=Y and P>0 and 
the checksums don't match you treat the received LSP as OLDER. Hence you 
return your copy (presumably), but the neighboring router will do the same 
and treat YOUR copy of the LSP as older and send you its copy again 
etc.etc. etc. I think we should remove it and put back the original text. 
If we want to clarify that a bit, then so be it, but lets start from 
something which is correct.

I think the problem arises because the author of the changes has mixed up 
the actions taken on any old LSP with those to be taken on your OWN LSP.

I found the following other problems in a quick scan through the document. 
I don't guarantee I have found them all.

2 Normative references. These need updating. For example ISO 8348:???? now 
contains the text of add1 and add2. They are no longer addenda. most (all) 
the items referenced yet to be published have now been published (I would 
hope:-)

There are multiple references to 8348 add 2 in the text which should now be 
just 8348

6.2 just above NOTE3 ex-changed shouldn't be hyphenated.

7.1.4 according to TC1 the first sentence should continue "and the rules 
stated above in 7.1.3.1"

Figure 4 in the DSP box it's should be its

7.2.5 bullets (c) and (d) have gratuitous space between them

7.2.92 two (new) references to attachedFlag should be in  a sans serif font 
(to comply with the typographical conventions described in clause 5

7.2.10.3 typo Interrmediate Systems reachable

7.2.12.3 bullet (b) "Otherwise, the level 2" (should be level 1)

7.3.4.6 Although this text is what the TC says, it is somewhat misleading, 
since it implies that it is reasonable to not re-issue the (now empty) LSP 
and just let it time out. This of course is quite un-reasonable, and the 
text shouldn't suggest that it is.

7.3.6 last bullet which reads "detection that other systems(s) hold a live 
LSSP which have been generated in a precious incarnation.

This is not strictly something which causes the contents of the LSP to 
change. It is rather an action caused by the normal operation of the update 
process and causes the LSP to be re-issued with a higher sequence number. I 
think it is misleading to include in here. If we HAVE to say something then 
perhaps something like "receipt of a copy of this system's LSP with a 
higher sequence number than that currently used by this system" (could be 
made cleaner..)

7.3.7 "point-to-point" etc. This is all confused. The original DR10 was 
trying (I believe) to align the nomenclature here with that used in 11.3.1 
for circuitType. I agree that point to point static in and static out are 
all dealt with the same, but the new text doesn't really work. Its needles 
on a pinhead stuff, but someone may care...

7.3.8 The new text introduced by DR 11 talking about adjacency usage level 
1 and 2 seems odd. MY paradigm was that on a LAN circuit the L1 hellos said 
L1 and the L2 hellos said L2 (not L1 and L2). We form two separate 
adjacencies, one L1 and one L2. If the L2 contains L1&2 then following this 
we would end up reporting TWO L1 adjacencies in the LSP. Its all tied up 
with the coding in the packet formats, which also got changed I think. The 
point it, if anyone cares, it should all be made consistent.

7.3.9 first bullet partitionAreaAddress should be a sans font

7.3.12 last sentence should say "set the SRM flag for that LSP" rather than 
"transmit the LSP" (as it does for L1)

7.3.14.2 item (e) This is something which SHOULD have been fixed, but seems 
to have fallen through the cracks in terms of getting into an ISO TC. SC6 
WG2 N523 correctly suggested that bullets 2 and 3 should be replaced simply 
by "discard the PDU". This fixes nasty purge storms which have occurred 
when flaky links perpetually deliver damaged LSPs.

7.3.15.1 a) 3) ...from the circuit of manualL2OnlyMode, would read better 
as ...from a circuit with....

7.3.15.2 ditto

7.3.16 stuff I've already complained about.

7.4.3.3 3rd para typo in the original "and the NPDU originated from the a 
local transport..." delete "a"

Also I think the last sentence is now redundant. We have no concept of the 
forward "procedure" return true or false (I think this is a hang over from 
my original DECnet spec!)

8.2.3 a) "cause ISO 9542 protocol machine" would be better "cause the ISO 
9542..."

But this raises the question as to whether we should be getting rid of the 
9542 baggage of sending an ISH first. Most implementations don't (I think). 
They certainly don't wait for it.

8.2.4 iSISHelloTimer should be in sans font

8.4.2.5.1. f) see comments on level1&2 in LAN hellos

8.4.6 new section in bullet b is "outdented"

9.5  Intermediate System Neighbors neighborSystem type should be in sans font

new variable length MAC address diagram should have a box around the top

9.6 NOTE 59 - weird or what? Having the manual area address in the L2 hello 
might just be useful for management reporting, but isn't used by the 
protocol. Not sure what the edit is trying to do.

ditto, box around the variable length MAC option

11.2.1.1 resettingHoldingTimer-B is outdented

11.2.5.7 ISISlevel2Broadcast -P PAckage. The defect report has become 
garbled. What it was trying to do was change the "l" of level to be upper 
case. Hence it should read linkageISISLevel2Broadcast-P NOT 
ISISlevel2Broadcast-P. It also needs correcting at the bottom in the 
REGISTERED AS clasue. Trivial I know!

Annex. As far as I know this is no longer required, since the changes DID 
get made in ISO 10165-5. Strictly someone should verify that, but I'm not 
sure there is anyone left alive who would know:-)

That's all for now.

         Mike

>ISO/IEC FCD 10589, Information technology  Telecommunications and
>information exchange between systems  Intermediate system to
>Content-Type: *unknown*/
>Content-Disposition: attachment; filename=06n1704.ZIP
>Content-Description: 06n1704.ZIP

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