Subject: [Isis-wg] Regarding document for best current practices

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 2 Jan 2002 10:34:30 -0500

Dave,

Changed the subject line to actually reflect the contents of the discussion.

No matter how small the difference, don't you think it would be good to
document it somewhere(may be, "not all that sticky" issues, could be
documented too)?

To think of it, wouldn't it be nice, if we could actually have an
informational document(all ISIS work in IETF is informational anyway, I
guess) which could talk about ISIS for IP specifically. This could talk
about the entire protocol(instead of a delta with the ISO spec as in
RFC1195) and could incorporate the best current practices. 

Would there be any interest in the group for this kind of a document? I
personally feel it would be a good idea, and would help in easier
understanding and better implementation of ISIS(atleast for those who are
not all that well versed). I have no idea of the IETF/ISO laison though.(I
tried to check if this thing had been raised before in the mailing list
couldn't find it)

Thanks,
Vishwas

---------------------------------------------------------------------
I think the number of things that are done in practical conflict with
the spec is vanishingly small, where "practical conflict" is
interpreted as "a reasonable implementation would notice."
Excessively pedantic boxes have a way of fixing themselves one way or
another.

Most of these things are pretty obvious to anyone reasonably versed in
the art, though the potentially sticky ones (like not bothering with
ISHs) should probably be documented.

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

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 9 Jan 2002 10:48:26 -0500

Folks,

Here are some more things I think "could"(based on what the list feels) be
documented too(though they may not necessarily have any interoperability
concerns). 

1. Some draft obsoleting TLV type 10. (though I know the draft on reserved
TLV codepoints calls it illegal, it is supposed to be a database of TLV's,
or will this suffice??). This issue seems to have been raised numerous
times, by different people.

2. There is talk about System-ID being 6 bytes and MaxAreaAddresses being
3(should this thing be documented too, to avoid confusion(anyway nobody uses
any other values), could these be made a constant for IP???) This was raised
by Radia, I guess !!!

3. Besides the MaxAge even the ISIS Hello Multiplier is configureable though
its described as an architectural constant(that could be documented too, as
we do not probably want the MIB to violate the specs)

4. An LSP received with wrong checksum should be dropped, instead of trying
to purge it.(this was listed in one of Dave's mail). Wouldn't it be good to
document this too? The MIB does talk about an object isisSysLSPIgnoreErrors
but that seems to be slightly different(or is it the same?).

Thanks,
Vishwas

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: Wednesday, January 09, 2002 1:14 AM
To: 'Jeff Learman'; Manral, Vishwas
Cc: 'Dave Katz'; Les Ginsberg; [email-masked]
Subject: RE: [Isis-wg] Regarding document for best current practices

In the work plan in ISO SC6/WG7 which produced the revised 10589:2001 spec,
there was a Phase 2 specified which was aimed at producing a document which
covered changes to the protocol introduced in the IP world. The exact form
this was to take was never agreed upon, the idea was floated on this list
(by me) with a rather tepid response. As the 10589 revision work progressed,
it became clear to me that ISO was the wrong place for this Phase 2 work to
take place - if it was going to take place at all it needed to be driven by
the community which was driving the evolution of the protocol.

In my view, what is needed is not a BCP document, but rather a new version
of RFC 1195. This would not need to supplant existing RFCs describing
protocol extensions, but it should at a minimum correct inaccuracies and
obsolete items in 1195, and hopefully go on to define extensions to the
protocol which have become common practice but have never been documented -
and have interoperability issues. The MAXAGE issue is a minor example - as
Mike Shand's keen eye has demonstrated - a strictly conformant
implementation based on 10589 would reject LSPs with a lifetime > 1200. The
fact that no one seems to do this does not diminish the need for having a
document that clearly states this.

It is a good thing that the way this group works tries to be responsive to
real world (AKA customer) requirements. It is not a good thing when protocol
extensions are made and left purely to word-of-mouth/reverse engineering
style documentation.

Given the extension of ISIS for IP into the formerly OSI only world of
SONET, the need for formalizing protocol extensions becomes even greater -
else we will end up with multiple/non-interoperable solutions.

I would love to believe that a meaningful liason between IETF/ISO/ITU
regarding IS-IS could be achieved, since that would allow all the interested
communities to participate in the evolution of the protocol - but having
spent a fair amount of effort trying to make that happen, I am not
optimistic. (No disrespect to a number of interested parties who were
supportive along the way).
Jeff Learman's comments below are pretty much on the mark - but if there is
sufficient interest in addressing things, I will be a willing participant.

   Les

> -----Original Message-----
> From: Jeff Learman [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2002 8:49 AM
> To: Manral, Vishwas
> Cc: 'Dave Katz'; [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] Regarding document for best current practices
> 
> 
> 
> Vishwas,
> 
> You repeated your request for a new document on IS-IS, either a
> compendium of best practices or a new spec that describes Integrated
> IS-IS.  One response I saw was that there weren't many discrepancies
> between spec and practice, and that most "best practices" were matters
> of implementation, not specification.
> 
> I suspect that there are things that would be good to 
> document, and perhaps
> padding of IIHs is one.  If you were to go over the list of 
> potential issues
> and present it, it might generate some interest.  I doubt 
> that this is work
> that anyone is eager to take on out of public interest, but if you are
> willing to drive the work, I'm sure you would get lots of feedback ;-)
> 
> Concerning creating a new spec that combines ISO 10589 and RFC-1195,
> this sure would be nice for those trying to learn integrated IS-IS
> and newcomers to the field.  However, there are significant issues:
> 
>   1.  It would be a lot of hard work.
> 
>   2.  Any new wording of these specs would create new 
> ambiguity problems.
>       Which spec would be the definitive one?  Would the new 
> document be
>       definitive or just descriptive?
> 
>   3.  There would be a temptation to "fix" things, which 
> would be a disaster.
>       If there is any new text, it should start out with the 
> intention of
>       being identical in meaning to the previous specs.  
> Unfortunately,
>       this would make it less helpful and clear for the IP-only crowd.
>       But at least, it could be used as a starting point, so that any
>       changes could be written against it, and therefore anyone could
>       tell what changed between two subsequent versions.
> 
> All of these issues could be worked through, if there is 
> enough commitment
> among all players.  But I doubt that we will find this kind 
> of commitment,
> and I question whether the result would justify the amount of work and
> haggling that would be required.
> 
> Alternatively, someone could write a good book on implementing IS-IS.
> They'd probably sell upwards of 50 copies ;-)
> 
> Regards,
> Jeff
> 
> Disclaimer: This is my opinion.  I do not represent Cisco in this
> forum and I have never worked on IS-IS at Cisco.
> 
> At 10:34 AM 1/2/2002, Manral, Vishwas wrote:
> >Dave,
> >

---

From: Danny McPherson <[email-masked]>
Date: Wed, 09 Jan 2002 10:09:24 -0700

> but that seems to be slightly different(or is it the same?).

It's the same...

-danny

---

From: Jeff Parker <[email-masked]>
Date: Wed, 9 Jan 2002 11:49:24 -0500

> > 4. An LSP received with wrong checksum should be dropped, 
> ... The MIB does talk about an object isisSysLSPIgnoreErrors
> 
> It's the same...
> 
> -danny

Danny -
	Thanks: I missed that reference.

Vishwas -
	There was a recent discussion of this, and I have removed
the object from the MIB.  Since no one should do what the spec
suggested, it is asking for trouble to suggest that it is an
option.  I think the ISO group is aware of this and fixing the
update.  

	Perhaps it is time to publish the current version of the 
MIB: I have only been tweaking it in the last week or two.  

--      Removed isisSysLSPIgnoreErrors: LSPs with errors should
--              always be ignored

- jeff parker

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 9 Jan 2002 12:22:52 -0500

Danny,

If the object

     isisSysLSPIgnoreErrors OBJECT-TYPE
         SYNTAX TruthValue
         MAX-ACCESS read-create
         STATUS current
         DESCRIPTION
             "If true, allow the router to ignore IS-IS link state packets
             (LSPs) that are received with internal checksum errors rather
             than purging the LSPs."
         DEFVAL { false }
     ::= { isisSysEntry 27 }

is supposed to do the same as the mail 
http://people.juniper.net/pipermail/isis-wg/1999/000084.html 
seems to suggest.

Then may be the wording instead should be "drop" instead of "ignore". I have
suggested Jeff P. the same in a private mail. Shouldn't this be specifed in
another draft anyway(as MIB's are not supposed to violate specs)?

Thanks,
Vishwas

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Wednesday, January 09, 2002 10:39 PM
To: [email-masked]
Subject: Re: [Isis-wg] Regarding document for best current practices 

It's the same...

-danny

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 9 Jan 2002 12:45:03 -0800

The perils of purging an LSP received w checksum error were identified in
Defect Report 1 (ISO/IEC JTC1/SC6/WG2/N523) which was written in April 1993.
Item #15 of this DR specified that the spec should be changed to indicate
the the corrupt LSP should be discarded, not purged. The DR was approved by
ISO. Unfortunately, due to some confusion created by an earlier version of
this DR which omitted Items 14-16, this spec change never got published. 

The 2001 revision of ISO 10589 has incorporated this change. Section
7.3.14.2e now reads:

	"An Intermediate system receiving a Link State PDU with an incorrect
LSP Checksum or with an invalid PDU syntax shall

	1)	generate a corruptedLSPReceived circuit event,

	2)	discard the PDU."

The point of all this is that a conformant implementation should always
discard an LSP with wrong checksum and that a knob is unnecessary. This was
discussed earlier and Jeff Parker has agreed to drop the item from the MIB
entirely.

   Les

> Sent: Wednesday, January 09, 2002 9:09 AM
> instead of trying

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 10 Jan 2002 01:48:54 -0500

Jeff,

Instead of the word ignore, the word "discarded" or "dropped" should be
used(whereever it is supposed to be). ;-)

-Vishwas

-----Original Message-----
From: Jeff Parker [mailto:[email-masked]]
Sent: Wednesday, January 09, 2002 10:19 PM
To: [email-masked]'; [email-masked]
Subject: RE: [Isis-wg] Regarding document for best current practices 

Danny -

Vishwas -

- jeff parker

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 10 Jan 2002 08:11:13 -0500

Folks,

With the use of domain-wide prefix distribution(especially L2->L1), do we
necessarily need to set the Attach bit in LSP's of "ATTACHED" routers.
Shouldn't that be allowed a configureable option now?

Also should the rule that default routes are not permitted in Level 1 areas
still be there. It could happen that a router connected to another
domain(ASBR), want to send default routes in L1 areas, however default
routes should be less preffered over routes to someone who originates LSP's
with Attached bit. (I assume we did not allow defaults was because defaults
were used for routing to nearest L2 router, right?)

Thanks,
Vishwas

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: Thursday, January 10, 2002 2:46 AM
To: 'Tony Li'; Tony Przygienda
Cc: Les Ginsberg; 'Jeff Learman'; Manral, Vishwas; 'Dave Katz';
[email-masked]
Subject: RE: [Isis-wg] Regarding document for best current practices

> 
> 
>  | Modulo Tony Li's opinion, if we see enough cycles of 
> cluefull people 
>  | being committed to make an update of RFC1195 happen, 
> that's something
>  | that can be talked about. 
> 
> 
> No disagreement.  However, folks should understand that it 
> will still be
> informational.
> 
> Tony
>

But isn't that precisely the problem? Significant revisions to the protocol
have been and are being made via this work group. At the same time, and even
more so these days because of the introduction of IP to the SONET world, the
ISO/ITU community is also making revisions. But in terms of specifications,
there is no real attempt to integrate. So we end up with confusion - and
what is even worse - interoperability issues. 

The fact that things have worked as well as they have thus far is
principally because:

a)Since 1992 the ISO world has made only minor revisions/corrections to the
protocol

b)Many of the folks who developed the 1992 spec have remained involved in
this WG and have kept the IP world mindful of interoperability issues

But that is changing. The work going on within the ITU on revising the rules
for supporting multiple protocols (IP and CLNP in their case) will have
significant impact on the protocol - and relates closely to IPV4/IPV6 issues
in the IP only world.

It is definitely true that interest in the ISO world per se is virtually
nil. As Micah has pointed out those people within ISO who took the time to
comment on the 2001 draft were, with one exception,  participants in this WG
as well. So it would be foolish to believe that ISO will somehow manage to
produce a document that incorporates the changes from the IP world. (For
that matter, I wonder how the ITU folks expect their changes to be reflected
in the ISO spec.)

I know that considerable politics is (unfortunately) involved here - perhaps
it is simply unworkable - but believing in possibilities is still a good
thing.

   Les