Subject: Charter

From: Tony Li <[email-masked]>
Date: Fri, 16 Oct 1998 17:55:36 -0700 (PDT)

Folks,

It's time for us to start to solidify the charter for the WG.  The mailing
list has been on line for a couple of weeks now and the changes on it have
basically stopped, so....  We need your comments on the charter.  In
particular, we need a clear set of milestones and documents.

Suggestions?

Tony & Tony == Tony

IS-IS working group (isis)
==========================

Chairs:  
Tony Li <[email-masked]>
Antoni Przygienda <[email-masked]>

Routing Area Director(s):
      Rob Coltun <[email-masked]>
 
Routing Area Advisor:
      Rob Coltun <[email-masked]>
 
Mailing Lists:
      General Discussion: [email-masked]
      To Subscribe: [email-masked]
      Archive: ftp://ftp.juniper.net/pub/isis/      

Description of Working Group:

IS-IS is an IGP specified and standarized by ISO and incorporating
extensions to support IP. It has been deployed successfully in the Internet
for several years years. The IS-IS Working Group is chartered to document
current protocol implementation practices and improvements, as well as to
propose further extensions to be used within the scope of IS-IS and IP
routing. Short term, the WG is expected to deliver a set of documents
describing common implementation practices and extensions necessary to
scale the protocol. These specifications will encourage multiple,
inter-operable vendor implementations. Longer term or at the same time, the
group may choose to work on further protocol improvements such as, but not
limited to, security issues, MIBs, traffic engineering support, enhanced
metric support, additional hierarchy, and carriage of IS-IS over protocols.

This working group will interact with other standards bodies that have
responsibility for standardizing IS-IS.

Goals and Milestones:
     TBD

Documents:
     TBD

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 17 Oct 1998 20:37:18 -0400

Tony Li wrote:

> ... zap ...

> responsibility for standardizing IS-IS.

One thing worth remembering is that the charter can be renegotiated so it's
kind of first shot to get going. As well, there was a first crude version of
goals & milestones floating around  (which is of course incomplete) but could
serve as a starting point to speed up convergence:

 short term:

   * writedown of extensions ISPs are using already today
   * MIB (yes, chance to become famous here ;-)
   * decision whether to pursuit other workitems

middle term:

   * commenting on ISO work if necessary
   * ISIS encapsulated in IP
   * MPLS support with longer metrics
   * security work
   * checksumming of all packet types
   * tackling the 255 Adjacencies problem
   * other ?
   * decision to pursuit longer-term, crazy ideas ?

longer term:

   * larger/better hierarchy
   * more fragments
   * any other crazy ideas such as flooding of metrics over spanning trees ?
   * ?

It would probably be beneficial for the members of this group to get their
comments together over the next week+ or so. we'll need to plan for the
meeting & things will become tight ...

        let's roll

        -- tony

---

From: Tony Li <[email-masked]>
Date: Sat, 17 Oct 1998 19:08:13 -0700 (PDT)

|   short term:
|  
|     * writedown of extensions ISPs are using already today

As far as I know, that consists soley of the Katz PTP IIH extension.

|     * MIB (yes, chance to become famous here ;-)
|     * decision whether to pursuit other workitems
|
|  middle term:
|  
|     * commenting on ISO work if necessary
|     * ISIS encapsulated in IP
|     * MPLS support with longer metrics

I believe that we need to move this to the short term work.

|     * security work

This could also be moved to the short term.

|     * checksumming of all packet types
|     * tackling the 255 Adjacencies problem
|     * other ?
|     * decision to pursuit longer-term, crazy ideas ?
|  
|  longer term:
|  
|     * larger/better hierarchy
|     * more fragments
|     * any other crazy ideas such as flooding of metrics over spanning trees ?

Someone had a crazy idea like computing redundant spanning trees for doing
LSP flooding.  This should go here.

Tony

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 18 Oct 1998 00:21:07 -0400

> As far as I know, that consists soley of the Katz PTP IIH extension.

There was an argument here whether only the things that change bits on the wire
are tobe documented or whether things that determine some of the internal protocol
behavior
need to be documented as well. The argument for the first is "do as little as you
can".
The argument for the second is the fact that e.g. operational issues that force
ISPs to
do things such as restrict flooding need to be documented if implementations are
to be truly
interoperable. E.g. one wouldn't have to specify implementation of aggregation
mechanisms
either but things like OSPF spec or 1195 do since it makes for much better
interoperability.
If this argument is taken, there is much more things to write about than the 3-way
hello ...
Even in the first case things like "don't-flood-on-checksum-error" things are
probably
necessary since they violate the spec if taken literally ;-)

> |     * decision to pursuit longer-term, crazy ideas ?

Generally I agree that basically all the middle-term items should go into
short-term to simplifythe list but that means more dates & milestones to be agreed
upon and accepted ;-) I'm however happy about
folding in the middle-term list into the short one ...

    thank you

    --- tony

---

From: Tony Li <[email-masked]>
Date: Mon, 19 Oct 1998 00:46:47 -0700 (PDT)

|  > |     * writedown of extensions ISPs are using already today
|  >
|  > As far as I know, that consists soley of the Katz PTP IIH extension.
|  
|  There was an argument here whether only the things that change bits on
|  the wire are tobe documented or whether things that determine some of
|  the internal protocol behavior need to be documented as well. The
|  argument for the first is "do as little as you can".  The argument for
|  the second is the fact that e.g. operational issues that force ISPs to
|  do things such as restrict flooding need to be documented if
|  implementations are to be truly interoperable. E.g. one wouldn't have to
|  specify implementation of aggregation mechanisms either but things like
|  OSPF spec or 1195 do since it makes for much better interoperability.
|  If this argument is taken, there is much more things to write about than
|  the 3-way hello ...  Even in the first case things like
|  "don't-flood-on-checksum-error" things are probably necessary since they
|  violate the spec if taken literally ;-)

Ok.  Difference in terminology.  I don't consider fixing glaring problems
to be extensions.  ;-)

In the case of the LSP checksum error, I will also note that ISO appears to
have picked up on this problem already.  Compare (old spec) 7.3.14.2 e)
vs. (new spec) 7.3.17.1.1 j.  I don't feel that we need to document such
fixes.

I do think that we should document the truncation of purged LSPs and note
the authentication implications that we've already discussed.  There are
also authentication requirements on purges that are not currently
documented.  ;-(

Any other 'bug fixes' that folks have implemented that I'm forgetting?

|  Generally I agree that basically all the middle-term items should go into
|  short-term to simplifythe list but that means more dates & milestones to be agreed
|  upon and accepted ;-) I'm however happy about
|  folding in the middle-term list into the short one ...

Let's do it.  Tony, could you please update your list with the specific
work items and republish?  Thanks.

Tony

---

From: Atul Bansal <[email-masked]>
Date: Mon, 19 Oct 1998 11:16:58 -0400

Is the short term (may even be a long term) goal to focus

on IP4 only? Alternatively, we could make IS-IS true multiprotocol

routing protocol (IPv4, IPv6, ....). 

It will be useful to clarify the intentions related to NL protocols

support at least in the goals section and possibly in the charter.

-Atul

At 08:37 PM 10/17/98 -0400, Antoni Przygienda wrote: 

<excerpt>Tony Li wrote: 

<excerpt>Folks, 

It's time for us to start to solidify the charter for the WG.  The
mailing 

list has been on line for a couple of weeks now and the changes on it
have 

Suggestions? 

... zap ...

extensions to support IP. It has been deployed successfully in the
Internet 

inter-operable vendor implementations. Longer term or at the same time,
the 

group may choose to work on further protocol improvements such as, but
not 

metric support, additional hierarchy, and carriage of IS-IS over
protocols. 

Goals and Milestones: 

     TBD

</excerpt>One thing worth remembering is that the charter can be
renegotiated so it's kind of first shot to get going. As well, there was
a first crude version of goals & milestones floating around  (which is of
course incomplete) but could serve as a starting point to speed up
convergence: 

 short term: 

<paraindent><param>left</param>*  writedown of extensions ISPs are using
already today 

</paraindent>middle term: 

<paraindent><param>left</param>*  commenting on ISO work if necessary 

*  security work 

*  other ? 

</paraindent>longer term: 

<paraindent><param>left</param>*  larger/better hierarchy 

*  more fragments 

*  any other crazy ideas such as flooding of metrics over spanning trees
? 

*  ? 

</paraindent>It would probably be beneficial for the members of this
group to get their comments together over the next week+ or so. we'll
need to plan for the meeting & things will become tight ... 

        let's roll 

        -- tony 

</excerpt><<<<<<<<

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 19 Oct 1998 11:29:39 -0400

> Ok.  Difference in terminology.  I don't consider fixing glaring problems

Well, where should then someone implementing IISIS find the fixes then ?
Version 2 won't show up for 
a good while if all the problems have to be ironed out, if it does as it
stands
it will make things only worse. Even then, lots of things don't show up
in the version 2.

Assuming that the goal is to have documents from which people can
produce interoperable,
usable implementations without having been 5+ years in the IS-IS
intepretation 
business, laying these things out in RFCs seems to be crucial.

I agree with your perception that fixing glaring problems are not
extensions but 
the boundary is very soft, flooding mesh requirements are neither a
glaring problem
nor really a protocol extension but a pretty strong operational
requirement in 
environments ISIS gets deployed these days, therefore probably worth a
write-down 
so we won't have implementors asking on the list "why is this thing
around ?" over and
over again ? 

> also authentication requirements on purges that are not currently

absolutely agreed. I'd expect a draft to be forthcoming ;-] ? 

> Any other 'bug fixes' that folks have implemented that I'm forgetting?

I'd assume that someone steps up to the plate & starts to write down a
BCP draft with 
the extensions/fixes/operational requirements and then we'll compile the
list. 

> work items and republish?  Thanks.

fine, here it goes as far as the input (or lack thereof) influenced it
(I added one 
new that we had some discussion on the list as well):

short term: 

     x writedown of extensions ISPs are using already today 
     x MIB (yes, chance to become famous here ;-) 
     x commenting on ISO work if necessary 
     x ISIS encapsulated in IP 
     x MPLS support with longer metrics 
     x security work 
     x checksumming of all packet types 
     x tackling the 255 Adjacencies problem 
     x optimal IP routing in L1/L2 hierarchy
     x other ? 
     x decision whether to pursuit longer-term, crazy ideas ? 

longer term: 

     x larger/better hierarchy 
     x more fragments 
     x any other crazy ideas such as flooding of metrics over spanning
trees ? 
     x ? 

what about dates ?  6-9 months for the short term ones and 1 year+ for
the longer term   ?

			thank you

		--- -tony

---

From: Henk Smit <[email-masked]>
Date: Mon, 19 Oct 1998 19:01:09 +0200 (MET DST)

> Any other 'bug fixes' that folks have implemented that I'm forgetting?

  I would like to see 7.3.16.3 changed. The last line reads:

    If the value of Remaining Lifetime is greater than MaxAge,
    the LSP shall be processed as if there were a checksum error.

  I would like to see this line dropped from the spec.
 A router, when examining RL, should accept any LSP with RL > 0.
 (As long as other criteria are met, of course).

    Henk.

---

From: Tony Li <[email-masked]>
Date: Mon, 19 Oct 1998 11:11:08 -0700 (PDT)

|  Well, where should then someone implementing IISIS find the fixes then ?
|  Version 2 won't show up for a good while if all the problems have to be
|  ironed out, if it does as it stands it will make things only worse. Even
|  then, lots of things don't show up in the version 2.

I have no objections to us documenting base protocol changes.  Nor was I
trying to discourage that.

|  > I do think that we should document the truncation of purged LSPs and note
|  > the authentication implications that we've already discussed.  There are
|  > also authentication requirements on purges that are not currently
|  > documented.  ;-(
|  
|  absolutely agreed. I'd expect a draft to be forthcoming ;-] ? 

Just as soon as we have decided that it's on the table as an open work
item.  ;-)

|  what about dates ?  6-9 months for the short term ones and 1 year+ for
|  the longer term   ?

I suspect that the dates will largely be a function of the contentiousness
and complexity of the particular document.  Some should be very short.

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 19 Oct 1998 11:07:29 -0700 (PDT)

|  Is the short term (may even be a long term) goal to focus
|  on IP4 only? Alternatively, we could make IS-IS true multiprotocol
|  routing protocol (IPv4, IPv6, ....). 

IS-IS is already a true multiprotocol routing protocol.  Or did we forget
CLNP already?  ;-)

As to supporting IPv6, it would be a reasonable long term work item to do
this extension.  I've heard rumblings in the hallways and have no reason to
think that the extensions are 'hard'.

Tony

---

From: Mike Shand <[email-masked]>
Date: Tue, 20 Oct 1998 08:50:11 +0100

> (As long as other criteria are met, of course).

Yes, I guess that makes sense. When MaxAge was an architectural constant,
then any value greater than MaxAge must clearly have been a corruption, and
hence the treatment as a checksum error. However, now that we want to make
MaxAge a variable (as it is in most implementations), then it is ugly to
have to change the value simultaneously on all systems.

I guess one could argue that accepting ANY value provides an easy way for a
malicous attacker to make any nasties they inject more persistent, but I
don't see that makes a lot of difference. Although the possibility of
non-malicious corruption (without breaking the checksum) causing an LSP to
live for 18 hours sounds scary, the reality is that in most cases it will
be replaced pretty soon by a new one. If we really wanted to retain some
protection we could have a MaxAcceptableAge parameter separate from MaxAge,
but that seems like overkill.

Provided we do the CSNP/PSNP checksum thing, there is no (well very little)
danger of SNP corruption causing very persistent spurious LSPs to be
injected. 

	Mike

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Oct 1998 01:19:49 -0700 (PDT)

|  I guess one could argue that accepting ANY value provides an easy way for a
|  malicous attacker to make any nasties they inject more persistent, but I
|  don't see that makes a lot of difference. 

Dah.  If I'm malicious and authentication is NOT in use, I can pretty much
do arbitrary things anyway.  If authentication IS in use, the best I can do
is to increase or decrease the amount of time that the LSP is useful.

Not a very interesting attack.

Tony