Subject: Re: Charter

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Sat, 17 Oct 1998 22:54:24 -0400 (EDT)

Another charter idea:
If it would be possible, perhaps getting the isis working
ng
group to take over the spec and perhaps write a more
readable, self-contained spec than the combo of IS-IS, plus the
integrated IS-IS RFC?

Why the interest in IS-IS encapsulated in IP? It always seemed
strange to me to have a routing protocol encapsulated in the layer
3 protocol, since the packets aren't supposed to get forwarded --
they're supposed to be processed hop by hop. (I'll guess the
answer has to do with OS implementation...multiplexing at a lower
layer vs a higher one).

Radia

---

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

> readable, self-contained spec than the combo of IS-IS, plus the

As seen on this list, commenting on version 2 of the OSI spec would be
necessary first and after they got it out & it's relevant there may be
interest from enough people in pursuing that as long-term workgroup
item.

> answer has to do with OS implementation...multiplexing at a lower

well, solves a couple of things, fragmentation of LSPs being one, doing
away with stuff like OSI ppp extensions being the other. And generally,
IP packets are easier to handle these days than OSI frames.  Forgot the
other reasons but one that I saw as an implementor is that I really like

to open a raw protocol socket & get stuff out like in OSPF ;-)

        thank you

        --- tony

---

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

|  > Another charter idea:
|  > If it would be possible, perhaps getting the isis working
|  > group to take over the spec and perhaps write a more
|  > readable, self-contained spec than the combo of IS-IS, plus the
|  > integrated IS-IS RFC?
|  
|  As seen on this list, commenting on version 2 of the OSI spec would be
|  necessary first and after they got it out & it's relevant there may be
|  interest from enough people in pursuing that as long-term workgroup
|  item.

I should point out that any attempt to 'take over' the spec might be viewed
very dimly by ISO.  They do seem to be working on it actively and I would
certainly not expect them to want to get rid of this work.

|  > Why the interest in IS-IS encapsulated in IP? It always seemed
|  > strange to me to have a routing protocol encapsulated in the layer
|  > 3 protocol, since the packets aren't supposed to get forwarded --
|  > they're supposed to be processed hop by hop. (I'll guess the
|  > answer has to do with OS implementation...multiplexing at a lower
|  > layer vs a higher one).

The primary motivation that I know of right now is that it would allow
people to eliminate one level of protocol demuxing that they currently do
on their ATM networks.  Since the most common protocol demux today is
rather expensive (AAL5/SNAP), it has a huge efficiency win on certain small
packets that the encapsulation forces into 2 cells.

In other words, we're costing people lots of money.  

|  well, solves a couple of things, fragmentation of LSPs being one, doing
|  away with stuff like OSI ppp extensions being the other. And generally,
|  IP packets are easier to handle these days than OSI frames.  Forgot the
|  other reasons but one that I saw as an implementor is that I really like
|  to open a raw protocol socket & get stuff out like in OSPF ;-)

Another big reason was that certain folks didn't have to be dependent on
there being a CLNP stack in their kernel.  For folks trying to vend IS-IS
over *, this was a big issue.  As one who has had to grunt to get CLNP back
into a BSD kernel, I will attest that this was No Fun (tm).

I'm not sure that I agree about the fragmentation of LSPs point.  If you
don't do the current fragmentation of LSPs, you have really horrible
properties on LSP changes.  For example, consider what happens when you
have 30kbytes of data and ONE TLV changes.

Also consider the nasty case where one IP fragment out of N is dropped.  We
saw this pattern back in the EGP days and had to kludge heavily to get
around it.  ;-(

Tony

---

From: Mike Shand <[email-masked]>
Date: Mon, 19 Oct 1998 08:59:16 +0100

>saw this pattern back in the EGP days and had to kludge heavily to get

Yup. In the original design for IS-IS we did have humungous LSPs being
fragmented using traditional fragmentation/reassembly, but changed it to
the current scheme for exactly those sorts of reasons. I wouldn't want to
go back to that.

	Mike

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 19 Oct 1998 10:34:44 -0400

> certainly not expect them to want to get rid of this work.

I tend to agree although I tried not to put it that bluntly ;-)  I think
that 
commenting on their version 2 spec and working with them is a first step
to 
trying to make sure the "right things happen" (tm ;-)  However,
respining the 
integrated RFC may be good idea ...
 
> saw this pattern back in the EGP days and had to kludge heavily to get

yes, I know the war stories. However, being able to and having to are 2
different 
things. One does not have to produce 30 Kbytes of data in a single LSP
(like in the old 
times ;-), that would be a lousy implementation,
however being strangled by an artificial  <smallest MTU in network>*255 
is pretty 
painfull as well. When I blow my 255 fragments limit or have a couple of
interfaces attached 
and I have to bring up a new one with a smaller MTU, reconfiguring the
whole 
network is not a great thing. As well, having 
a network that can partition in terms of flooding because of
misconfiguration somewhere
is not a desirable design restriction either ;-)
it seems like a good insurance to be able to  produce decently sized
LSPs 
when necessary (at least from my OSPF experience ;-) 

Summa summarum, I didn't claim that fragmentation is there to be used
whenever possible 
and is inherently a good thing, I just claim that it may come handy in
some situations and will
fall out for free from IP encaps.

	thank you

		-- tony

---

From: "Lester Ginsberg" <[email-masked]>
Date: Mon, 19 Oct 1998 23:20:32 -0700

Work on the ISO 10589 standard is coordinated by ISO JTC1/SC6
WG7. Voting in ISO committees is through member countries
national standards bodies - ANSI in the US. For many ISO
committees/working groups, member countries create TAGs wherein
interested parties can provide input and formulate a
position to be presented at the ISO WG meetings.

In the US, there has been no WG7 TAG for some time, presumably
through lack of interest. As a result, WG7 issues have been funneled
to the US SC6 TAG, which has almost always abstained on WG7
issues because the SC6 TAG members have not had the time/expertise
to comment on network/transport layer issues, the current scope
of WG7 work.

At the moment, the US SC6 TAG administrator is actively seeking
to promote the formation of a US WG7 TAG. This requires an ANSI
approved administrator as well as companies interested in 
joining/participating in the TAG. The interests of this group
(isis-wg) may be well served by participating in a WG7 TAG should it
be formed since it would provide a formal input path to
ISO JTC1/SC6 WG7. This would allow the development of a single
IS-IS standard - something which I see as highly desirable.

Unless your company has the blessing of ANSI to perform TAG
administrative duties (if you are not sure - then your company
probably does not have such a blessing) - it is too soon to
do much about this issue - but hopefully a willing administrator will
be found soon and then the level of interest on the part of US companies
will be an important factor in the success of the TAG.

It would be a good thing if this group was prepared to support
the formation of a US WG7 TAG - as well as participate in the
appropriate TAGs in other ISO member countries in the case of
companies based outside of the US.

  Les

---

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

Les,

Thank you for that summary.  In addition to that, we hope that the ITU will
accept contributions from the IS-IS WG under the terms of RFC 2436,
"Collaboration between ISOC/IETF and ITU-T" ...

In particular, section 3.3.1 reads:

3.3.1  IETF to ITU-T

   IETF documents (e.g., Internet Drafts) can be submitted to a Study
   Group as a Contribution from ISOC.  In order to ensure that the IETF
   has properly authorized this,  the IETF Working Group must agree that
   the specific drafts are of mutual interest and that there is a
   benefit in forwarding them to the ITU-T for review, comment and
   potential use.  Once agreed, the Vice President Standards for ISOC
   would review the Working Group request and give approval.  The
   contributions would then be forwarded (with the noted approval) to
   the TSB for circulation as a Study Group Contribution.

While this is no replacement for actual participation in the ITU, I would
hope that contributions from the IETF (especially about IS-IS) would be
given serious consideration.

Tony

---

From: Mike Shand <[email-masked]>
Date: Tue, 20 Oct 1998 09:41:10 +0100

So what ITU SG deals with 10589?

	Mike

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 20 Oct 1998 10:17:34 -0400

> So what ITU SG deals with 10589?

As far as I understood 10589 is a pure ISO product, ITU doesn't touch it
;-) 

		thank you

		--- tony