From isis-wg-admin@spider.juniper.net  Fri Jun  1 03:00:17 2001
Received: from external.juniper.net ([207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01359
	for <isis-archive@odin.ietf.org>; Fri, 1 Jun 2001 03:00:16 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA31921;
	Fri, 1 Jun 2001 00:43:08 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA25504
	for <isis-wg@spider.juniper.net>; Wed, 30 May 2001 22:26:50 -0700 (PDT)
Received: from WS0005.indiatimes.com ([203.199.93.15])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f4V4fKw62026
	for <isis-wg@juniper.net>; Wed, 30 May 2001 21:41:21 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from 192.168.57.15 (a1 [192.168.57.21])
	by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id JAA07745
	for "isis"<isis-wg@juniper.net>; Thu, 31 May 2001 09:51:01 +0530
From: "Sivakumar A" <sivaa@indiatimes.com>
Message-Id: <200105310421.JAA07745@WS0005.indiatimes.com>
To: "isis"<isis-wg@juniper.net>
Reply-To: "Sivakumar A"<sivaa@indiatimes.com>
X-URL: http://indiatimes.com
Content-Type: multipart/alternative;
	   boundary="=_MAILER_ATTACH_BOUNDARY1_20015314957572083149517"
MIME-Version: 1.0
Subject: [Isis-wg] Routes/sec
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Thu, 31 May 2001 09:57:57 +0530

--=_MAILER_ATTACH_BOUNDARY1_20015314957572083149517
Content-Type: text/plain; charset=us-ascii

Hello all,


Can you pls. suggest me a reasonable value for routes per second a router need to support.


Thanks in advance


Regards


Sivakumar A
Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com

--=_MAILER_ATTACH_BOUNDARY1_20015314957572083149517
Content-Type: text/html; charset=us-ascii

<P>Hello all,</P>
<P>Can you pls. suggest me a reasonable value for routes per second a router need to support.</P>
<P>Thanks in advance</P>
<P>Regards</P>
<P>Sivakumar A</P>
<hr><font face="Arial" size="2"><b>Get Your Private, Free E-mail from Indiatimes at  </font><a href="http://email.indiatimes.com"><font face="Arial" size="2">http://email.indiatimes.com</font></a></b>

--=_MAILER_ATTACH_BOUNDARY1_20015314957572083149517--

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun  5 14:50:35 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28152
	for <isis-archive@odin.ietf.org>; Tue, 5 Jun 2001 14:50:34 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA59227;
	Tue, 5 Jun 2001 12:34:08 -0700 (PDT)
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA59215
	for <isis-wg@spider.juniper.net>; Tue, 5 Jun 2001 12:33:43 -0700 (PDT)
Received: from tot-wp1-wo.proxy.aol.com (tot-wp1-wo.proxy.aol.com [205.188.200.3])
	  by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id OAA26423 for <isis-wg@external.juniper.net>;
	  Tue, 5 Jun 2001 14:37:13 -0400 (EDT)
Received: from ma.ultranet.com (AC8D309E.ipt.aol.com [172.141.48.158])
	by tot-wp1-wo.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f55Ib8S15853
	for <isis-wg@external.juniper.net>; Tue, 5 Jun 2001 14:37:08 -0400 (EDT)
Message-ID: <3B1D5164.913F20C6@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Content-Type: multipart/mixed;
 boundary="------------B6D8409BDBD74229EA97F680"
X-Apparently-From: Hudeks@aol.com
Subject: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04.txt]
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 05 Jun 2001 14:38:45 -0700

This is a multi-part message in MIME format.
--------------B6D8409BDBD74229EA97F680
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

I originally sent the following note to Jeff, and
he asked me to resend it to the wg email list.
Comments/clarifications/corrections/further discussion welcomed.

Thanks,
dave h

David Hudek wrote:
> 
> Hi Jeff...
> 
> I'm not sure if these sorts of questions/comments
> should go on the ISIS working group email list or
> be sent directly to the author... I'm just
> opting for the latter as a default :-)
> 
> I've started looking at draft-ietf-isis-wg-mib-04.txt (believe
> this is the latest?) and had a couple minor
> questions/comments concerning the IsisSummAddrEntry stuff...
> 
>     a) Why two "type" entries, one for address and
>        one for mask... are they not required to agree?
>        (e.g., if the address is ipv4 type, then doesn't
>         the associated mask also have to be ipv4 type?)
> 
>        My first thought was that only one is needed,
>        with extra error handling now required if we
>        allow two and they accidentally differ...
>        but perhaps a heterogeneous combination
>        makes sense and I just didn't see it?
> 
> 
>     b) Assuming the summary addresses are for the
>        purpose of prefix summarization when leaking
>        routes up or down the levels (with leaking down
>        now allowed via rfc 2966) (?)...
> 
>        Can there be a little more verbiage describing
>        exactly what the isisSummAddrAdminState
>        (which can take on values indicating L1, L2,
>        L1L2, and off) is supposed to indicate?
>        Perhaps something to indicate which end of the
>        leaking is contemplated (e.g., "into" vs. "out of")...
>        For instance, if it's "summaryl1", does that mean the
>        summarization is supposed to be applied when leaking
>        out of L1, or when leaking into L1? Basically,
>        in which direction is the filter applied?
>        I'm assuming "out of" is meant, but you know
>        what happens when one assumes :-)
> 
>        Also, is an L1L2 entry functionally the same
>        as an L1 entry and a separate L2 entry with
>        identical addr/mask?
>        (is it just there to save on an extra config step
>         or does it mean something different)?
>        If it's the same as a L1 and a L2, I'd personally
>        rather see the L1L2 removed and the two summaries
>        be made explicit, so they can be treated independently.
>        Else, if it was L1L2, and user decided they just
>        wanted L1, then they'd have to turn off L1L2
>        and then quickly add it back as L1, possibly causing
>        unnecessary churn in the LSPs as the summarization
>        state bounced.

         (of course, one could change the order, add the 
          L1 and then turn off the L1L2, but still...
          the semantics are a little unclear, as 
          mentioned next)

>        And you could get complaints about the treatment of
>        the same addr/mask in overlapping types if one was
>        turned off and the other on... which one wins?
>        For instance, if the user turned off L1L2 intending
>        that they both not summarize that addr/mask, but
>        they also had that addr/mask as an L1, then what
>        happens? I'm assuming that the L1 summarization
>        occurs (L1 on trumps L1L2 off)
>        but perhaps others would assume differently.
> 
>        (and a really *minor* nit... if there's not
>         a MIB convention that prohibits it, when naming
>         items with L and 1 next to each other,
>         could the capital L be used instead of lower case?
>         "l1" looks an awful lot like "11", while
>         "L1" is easily distinguished... personal opinion,
>         I think that summaryL1 looks just spiffy, while
>         summaryl1l2 at first glance looks like the
>         many-level-ISIS effort has gone on steroids
>         with over 1000 levels  :-) )
> 
> Thanks,
> dave h
> dhudek@ma.ultranet.com
--------------B6D8409BDBD74229EA97F680
Content-Type: message/rfc822
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3B1C50B2.C6A8A2AF@ma.ultranet.com>
Date: Mon, 04 Jun 2001 20:23:30 -0700
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: jparker@axiowave.com
Subject: Question/Comment on draft-ietf-isis-wg-mib-04.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi Jeff...

I'm not sure if these sorts of questions/comments
should go on the ISIS working group email list or
be sent directly to the author... I'm just
opting for the latter as a default :-)


I've started looking at draft-ietf-isis-wg-mib-04.txt (believe
this is the latest?) and had a couple minor 
questions/comments concerning the IsisSummAddrEntry stuff...

    a) Why two "type" entries, one for address and
       one for mask... are they not required to agree?
       (e.g., if the address is ipv4 type, then doesn't
        the associated mask also have to be ipv4 type?)

       My first thought was that only one is needed,
       with extra error handling now required if we 
       allow two and they accidentally differ...
       but perhaps a heterogeneous combination
       makes sense and I just didn't see it?

	
    b) Assuming the summary addresses are for the
       purpose of prefix summarization when leaking
       routes up or down the levels (with leaking down
       now allowed via rfc 2966) (?)...

       Can there be a little more verbiage describing
       exactly what the isisSummAddrAdminState 
       (which can take on values indicating L1, L2, 
       L1L2, and off) is supposed to indicate?
       Perhaps something to indicate which end of the
       leaking is contemplated (e.g., "into" vs. "out of")... 
       For instance, if it's "summaryl1", does that mean the 
       summarization is supposed to be applied when leaking 
       out of L1, or when leaking into L1? Basically,
       in which direction is the filter applied?
       I'm assuming "out of" is meant, but you know
       what happens when one assumes :-)

       Also, is an L1L2 entry functionally the same
       as an L1 entry and a separate L2 entry with 
       identical addr/mask?
       (is it just there to save on an extra config step
        or does it mean something different)?
       If it's the same as a L1 and a L2, I'd personally
       rather see the L1L2 removed and the two summaries
       be made explicit, so they can be treated independently.
       Else, if it was L1L2, and user decided they just
       wanted L1, then they'd have to turn off L1L2
       and then quickly add it back as L1, possibly causing 
       unnecessary churn in the LSPs as the summarization 
       state bounced.
       And you could get complaints about the treatment of
       the same addr/mask in overlapping types if one was
       turned off and the other on... which one wins?
       For instance, if the user turned off L1L2 intending
       that they both not summarize that addr/mask, but
       they also had that addr/mask as an L1, then what
       happens? I'm assuming that the L1 summarization
       occurs (L1 on trumps L1L2 off) 
       but perhaps others would assume differently.

       (and a really *minor* nit... if there's not
        a MIB convention that prohibits it, when naming
	items with L and 1 next to each other,
	could the capital L be used instead of lower case?
	"l1" looks an awful lot like "11", while
	"L1" is easily distinguished... personal opinion,
	I think that summaryL1 looks just spiffy, while
	summaryl1l2 at first glance looks like the
	many-level-ISIS effort has gone on steroids
	with over 1000 levels  :-) )

Thanks,
dave h
dhudek@ma.ultranet.com

--------------B6D8409BDBD74229EA97F680--

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun  5 16:06:06 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29368
	for <isis-archive@odin.ietf.org>; Tue, 5 Jun 2001 16:06:06 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA59596;
	Tue, 5 Jun 2001 13:51:08 -0700 (PDT)
Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA59584
	for <isis-wg@spider.juniper.net>; Tue, 5 Jun 2001 13:50:41 -0700 (PDT)
Message-ID: <EB5FFC72F183D411B3820006295734296AEEE9@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'David Hudek'" <dhudek@ma.ultranet.com>, isis-wg@spider.juniper.net
Subject: RE: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04
	.txt]
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0EDFA.BBE4B9F0"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 5 Jun 2001 16:04:31 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EDFA.BBE4B9F0
Content-Type: text/plain;
	charset="iso-8859-1"

> > ...[is] draft-ietf-isis-wg-mib-04.txt ... the latest?

Yup.

> >     a) Why two "type" entries, one for address and
> >        one for mask... are they not required to agree?
> >        (e.g., if the address is ipv4 type, then doesn't
> >         the associated mask also have to be ipv4 type?)

This is an issue with RFC 2851's InetAddress object.  This has 
been addressed in a recent draft that Juergen Schoenwaelder
pointed out, draft-ietf-ops-rfc2851-update-00.txt, which includes
provisions for a triple (Type, Address, MaskLen).
I will use this in version 05.  

> > 
> >     b) Assuming the summary addresses are for the
> >        purpose of prefix summarization when leaking
> >        routes up or down the levels (with leaking down
> >        now allowed via rfc 2966) (?)...

Point taken.  The original anticipated summarizing L1 
routes into L2.  I was trying to support the ability 
to summarize L1 routes into L1 as well, which some
vendors support.  If you are importing routes from
another protocol into IS-IS, you might wish to summarize
before announcing.

Any comments from the list about the relevance
of summaries from {L1, L2} into {L1, L2}?  
(That is, which of the four possibilities make sense)
Does it make sense to summarize L2 into L1?  

> >        Also, is an L1L2 entry functionally the same
> >        as an L1 entry and a separate L2 entry with
> >        identical addr/mask?

You raise a good point about controlling these.  The
question of what we should/should not support remains.  

> >         could the capital L be used instead of lower case?
> >         "l1" looks an awful lot like "11", while
> >         "L1" is easily distinguished... 
> >
> > dhudek@ma.ultranet.com

Many of these are easy to fix.  
I think there is a requirement that the first character 
of  an enumerated type be lower case (as below).  I 
suppose these could be spelled out as "level1..."
and "level2...".  Would that be any better?

- jeff parker
- axiowave networks

     isisISAdjNeighSysType OBJECT-TYPE
         SYNTAX INTEGER {
             l1IntermediateSystem(1),
             l2IntermediateSystem(2),
             l1l2IntermediateSystem(3),
             unknown(4)
             }

------_=_NextPart_001_01C0EDFA.BBE4B9F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Isis-wg] [Fwd: Question/Comment on =
draft-ietf-isis-wg-mib-04.txt]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; &gt; ...[is] draft-ietf-isis-wg-mib-04.txt ... =
the latest?</FONT>
</P>

<P><FONT SIZE=3D2>Yup.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; a) Why two =
&quot;type&quot; entries, one for address and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
one for mask... are they not required to agree?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(e.g., if the address is ipv4 type, then doesn't</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the associated =
mask also have to be ipv4 type?)</FONT>
</P>

<P><FONT SIZE=3D2>This is an issue with RFC 2851's InetAddress =
object.&nbsp; This has </FONT>
<BR><FONT SIZE=3D2>been addressed in a recent draft that Juergen =
Schoenwaelder</FONT>
<BR><FONT SIZE=3D2>pointed out, draft-ietf-ops-rfc2851-update-00.txt, =
which includes</FONT>
<BR><FONT SIZE=3D2>provisions for a triple (Type, Address, =
MaskLen).</FONT>
<BR><FONT SIZE=3D2>I will use this in version 05.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; b) Assuming the =
summary addresses are for the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
purpose of prefix summarization when leaking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
routes up or down the levels (with leaking down</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
now allowed via rfc 2966) (?)...</FONT>
</P>

<P><FONT SIZE=3D2>Point taken.&nbsp; The original anticipated =
summarizing L1 </FONT>
<BR><FONT SIZE=3D2>routes into L2.&nbsp; I was trying to support the =
ability </FONT>
<BR><FONT SIZE=3D2>to summarize L1 routes into L1 as well, which =
some</FONT>
<BR><FONT SIZE=3D2>vendors support.&nbsp; If you are importing routes =
from</FONT>
<BR><FONT SIZE=3D2>another protocol into IS-IS, you might wish to =
summarize</FONT>
<BR><FONT SIZE=3D2>before announcing.</FONT>
</P>

<P><FONT SIZE=3D2>Any comments from the list about the relevance</FONT>
<BR><FONT SIZE=3D2>of summaries from {L1, L2} into {L1, L2}?&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>(That is, which of the four possibilities make =
sense)</FONT>
<BR><FONT SIZE=3D2>Does it make sense to summarize L2 into L1?&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Also, is an L1L2 entry functionally the same</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
as an L1 entry and a separate L2 entry with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
identical addr/mask?</FONT>
</P>

<P><FONT SIZE=3D2>You raise a good point about controlling these.&nbsp; =
The</FONT>
<BR><FONT SIZE=3D2>question of what we should/should not support =
remains.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; could the capital =
L be used instead of lower case?</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;l1&quot; =
looks an awful lot like &quot;11&quot;, while</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;L1&quot; is =
easily distinguished... </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; dhudek@ma.ultranet.com</FONT>
</P>

<P><FONT SIZE=3D2>Many of these are easy to fix.&nbsp; </FONT>
<BR><FONT SIZE=3D2>I think there is a requirement that the first =
character </FONT>
<BR><FONT SIZE=3D2>of&nbsp; an enumerated type be lower case (as =
below).&nbsp; I </FONT>
<BR><FONT SIZE=3D2>suppose these could be spelled out as =
&quot;level1...&quot;</FONT>
<BR><FONT SIZE=3D2>and &quot;level2...&quot;.&nbsp; Would that be any =
better?</FONT>
</P>

<P><FONT SIZE=3D2>- jeff parker</FONT>
<BR><FONT SIZE=3D2>- axiowave networks</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; isisISAdjNeighSysType =
OBJECT-TYPE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SYNTAX INTEGER {</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; l1IntermediateSystem(1),</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; l2IntermediateSystem(2),</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; l1l2IntermediateSystem(3),</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; unknown(4)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; }</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EDFA.BBE4B9F0--
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun  5 19:32:19 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01530
	for <isis-archive@odin.ietf.org>; Tue, 5 Jun 2001 19:32:19 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA60436;
	Tue, 5 Jun 2001 17:16:08 -0700 (PDT)
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA60424
	for <isis-wg@spider.juniper.net>; Tue, 5 Jun 2001 17:15:55 -0700 (PDT)
Received: from tot-tg1-th.proxy.aol.com (tot-tg1-th.proxy.aol.com [152.163.213.3])
	  by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id TAA11388 for <isis-wg@external.juniper.net>;
	  Tue, 5 Jun 2001 19:16:14 -0400 (EDT)
Received: from ma.ultranet.com (AC971655.ipt.aol.com [172.151.22.85])
	by tot-tg1-th.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f55NGCc26094
	for <isis-wg@external.juniper.net>; Tue, 5 Jun 2001 19:16:12 -0400 (EDT)
Message-ID: <3B1D92CC.9E0DC03@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 05 Jun 2001 19:17:48 -0700
Content-Transfer-Encoding: 7bit


Hi all,

The latest ISIS TE draft I could find is the one mentioned in the 
subject. Assuming that's the latest, or that a later one has 
similar treatment (non-treatment) of external metric type, I'd like
to offer the following comments/suggestions.

First, let me say I'm no big fan of the external metric type, and 
it wouldn't bother me if it were to just fade away. It simplifies 
things nicely if all metrics are comparable. [Since no one has told 
me nay, I'm assuming that the previous "History of the External
Metric Type?" email is at least reasonably close to the actual state 
of affairs? If not, please let me know and perhaps the
rest of this comment will be filed under Rosanne Rosannadana
("nevermind..."  ;-))]

However, I'm more concerned with implementations' interoperability,
and so if it is going away, I'd like to see it do so in an orderly 
manner. If it's not going away, I'd like to see it defined in the 
relevant message. 

It's troubling to read of some folks just picking undocumented random
bits 
in the message to indicate metric type, while others do nothing and 
ignore it, and some talk of using an unspecified subTLV.

As I understand it, the draft rfc has an Extended IP Reachability TLV, 
which is intended to replace two of the original IP TLVs...
IP Internal Reachability (Type 128) and IP External Reachability
(Type 130) [the only really significant difference between the two being
that ExtReach could potentially use external non-comparable type
metrics,
while IntReach could not... and all reachability using
internal metric type, from either TLV, is treated similarly...
so the only distinguishing factor boils down to the
external metric type or not]

Besides other nice stuff, the new Extended TLV uses a wider metric. 
To my knowledge, no official subTLVs have been defined for it, and 
it intentionally makes no mention of the metric type. The rationale 
mentioned so far for this omission is that no one is using the 
non-comparable "external" metric type, and implementers could just 
assume that info supplied via the Extended IP Reachability TLV
should be treated as though it had comparable "internal" metrics.

However, that sort of advice has only been given via the mailing list 
and is not part of the (draft) rfc itself, where a future implementer 
could readily find it. Also, it is not clear that the rationale is 
correct, since at least one person posted to the list in the past that 
they intended to make use of some otherwise unused bit to indicate the
external metric type in their implementation. Others have mentioned 
using an undocumented subTLV type.

Can we decide if external metric type is *actually required*
(seems to be some disagreement?), and either:

    a) explicitly deprecate it in the TE spec.
       Some verbiage to the effect that the external metric
       type is no longer supported, and any metrics
       received via the Extended IP Reachability TLV
       MUST be treated as having comparable ("internal")
       metrics (is there anyone on the list who would
       strongly oppose such a thing?)

       OR

    b) explicitly specify a subTLV in which to convey the
       metric type. For a stake in the ground, how about
       something like the following (using least sig bit
       in the value as internal/external type, other bits
       sent as zero and ignored upon receipt), and since
       we only need one bit and it seems so wasteful to
       spend 3 octets to convey one bit's worth of data,
       possibly generalize the new subTLV into an
       "Extended Control Info" type for future general use 
       of the other bits if needed? :

       Extended Control Type SubTLV
          Sub-TLV Type:     1
          Sub-TLV Length:   1
	  Sub-TLV Values:   0 if metric is comparable (internal type)
                            1 if metric is non-comparable (external
type)

       If someone really really demanded symmetry with the
       old TLVs, one could use the second least sig bit
       to indicate internal or external reachability,
       but it's not clear that buys you anything?...
       (but for completeness, could use these values instead,
        with the upper 6 bits reserved, zeroed on send, ignored on
receipt)
          00 - metric is internal reach/comparable metric type
          01 - metric is internal reach/non-comparable metric type
(illegal?)
          10 - metric is external reach/comparable metric type
          11 - metric is external reach/non-comparable metric type)


If it's true that there's no real justification for external metric
type,
then I'd favor (a). If there are valid reasons for having it, then I'd 
favor something along the lines of (b) with things at least nailed down 
sufficiently for an implementation.

If this has been resolved after draft ver 02 or elsewhere, 
oops...  my bad!   and can you point me to it? 

Thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 03:40:45 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23119
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 03:40:44 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA62427;
	Wed, 6 Jun 2001 01:25:08 -0700 (PDT)
Received: from mailweb25.rediffmail.com ([203.199.83.29])
	by external.juniper.net (8.9.3/8.9.3) with SMTP id BAA62412
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 01:24:39 -0700 (PDT)
Received: (qmail 16362 invoked by uid 510); 6 Jun 2001 07:42:46 -0000
Message-ID: <20010606074246.16361.qmail@mailweb25.rediffmail.com>
Received: from unknown (61.135.52.212) by rediffmail.com via HTTP; 06 Jun 2001 07:42:46 -0000
MIME-Version: 1.0
To: "isis-wg@external.juniper.net" <isis-wg@spider.juniper.net>
From: "Purushothaman  NandaKumaran" <purush_isis@rediffmail.com>
Content-ID: <Wed_Jun__6_13_12_45_IST_2001_0@mailweb25.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [Isis-wg] Summary Address
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: 6 Jun 2001 07:42:46 -0000
Content-Transfer-Encoding: 7bit

Hi,
I have some doubts in advertising summary routes.

1) Whether the configured summary address will go as IP internal or external reachability information in the generated LSP's?

2) If some redistributed routes fall under the summary route (redistributed routes will be sent as IP external reachability information) and if some level 1 routes also
fall under the same summary route (level 1 to level 2 which should go as IP internal reachability information)
then how should we advertise that summary route?

Please clarify my doubts.
thanks in advance,
Purush


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com




_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 09:49:43 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00823
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 09:49:43 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA64065;
	Wed, 6 Jun 2001 07:34:08 -0700 (PDT)
Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA64053
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 07:33:17 -0700 (PDT)
Message-ID: <EB5FFC72F183D411B3820006295734296AEF01@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'David Hudek'" <dhudek@ma.ultranet.com>
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>
Subject: RE: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0EE8F.28642680"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 09:46:59 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EE8F.28642680
Content-Type: text/plain;
	charset="iso-8859-1"

 > ...two of the original IP TLVs...
> IP Internal Reachability (Type 128) and IP External Reachability
> (Type 130) [the only really significant difference between 
> the two being that ExtReach could potentially use external 
> non-comparable type metrics,
> while IntReach could not... and all reachability using
> internal metric type, from either TLV, is treated similarly...
> so the only distinguishing factor boils down to the
> external metric type or not]

Just to be clear about this, these metrics are quite different.
The worst metric for an internal reachability is preferred over
the best metric in external.  This could be visualized as an 
extra 9th bit that is set for external and cleared for internal. 
This would allow the two metrics to be mapped into a new
consistent value.  

Any route learned from another protocol (BGP, Static, RIP) gets 
an external: any route learned via the IGP gets an internalReach.
Of course, implementations have been known to import external
routes as Internal Reachability, but that was not the original
intention.  

There is an argument to be made that local policy should define
how metrics are mapped, and that since IS-IS is an IGP, we only
need to worry about local policy.  However, I like to have some
guidelines on interoperation between metric types.  It is bad
enough that we need to compare two types, with the 2 extra bits,
without adding an incomperable 3rd metric.  

- jeff parker 

------_=_NextPart_001_01C0EE8F.28642680
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp;&gt; ...two of the original IP TLVs...</FONT>
<BR><FONT SIZE=2>&gt; IP Internal Reachability (Type 128) and IP External Reachability</FONT>
<BR><FONT SIZE=2>&gt; (Type 130) [the only really significant difference between </FONT>
<BR><FONT SIZE=2>&gt; the two being that ExtReach could potentially use external </FONT>
<BR><FONT SIZE=2>&gt; non-comparable type metrics,</FONT>
<BR><FONT SIZE=2>&gt; while IntReach could not... and all reachability using</FONT>
<BR><FONT SIZE=2>&gt; internal metric type, from either TLV, is treated similarly...</FONT>
<BR><FONT SIZE=2>&gt; so the only distinguishing factor boils down to the</FONT>
<BR><FONT SIZE=2>&gt; external metric type or not]</FONT>
</P>

<P><FONT SIZE=2>Just to be clear about this, these metrics are quite different.</FONT>
<BR><FONT SIZE=2>The worst metric for an internal reachability is preferred over</FONT>
<BR><FONT SIZE=2>the best metric in external.&nbsp; This could be visualized as an </FONT>
<BR><FONT SIZE=2>extra 9th bit that is set for external and cleared for internal. </FONT>
<BR><FONT SIZE=2>This would allow the two metrics to be mapped into a new</FONT>
<BR><FONT SIZE=2>consistent value.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Any route learned from another protocol (BGP, Static, RIP) gets </FONT>
<BR><FONT SIZE=2>an external: any route learned via the IGP gets an internalReach.</FONT>
<BR><FONT SIZE=2>Of course, implementations have been known to import external</FONT>
<BR><FONT SIZE=2>routes as Internal Reachability, but that was not the original</FONT>
<BR><FONT SIZE=2>intention.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>There is an argument to be made that local policy should define</FONT>
<BR><FONT SIZE=2>how metrics are mapped, and that since IS-IS is an IGP, we only</FONT>
<BR><FONT SIZE=2>need to worry about local policy.&nbsp; However, I like to have some</FONT>
<BR><FONT SIZE=2>guidelines on interoperation between metric types.&nbsp; It is bad</FONT>
<BR><FONT SIZE=2>enough that we need to compare two types, with the 2 extra bits,</FONT>
<BR><FONT SIZE=2>without adding an incomperable 3rd metric.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>- jeff parker </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EE8F.28642680--
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 09:56:49 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00959
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 09:56:48 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA64138;
	Wed, 6 Jun 2001 07:42:09 -0700 (PDT)
Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA64126
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 07:41:37 -0700 (PDT)
Message-ID: <EB5FFC72F183D411B3820006295734296AEF02@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Purushothaman  NandaKumaran'" <purush_isis@rediffmail.com>
Cc: "'isis-wg@spider.juniper.net'" <isis-wg@spider.juniper.net>
Subject: RE: [Isis-wg] Summary Address
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0EE90.409B6140"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 09:54:49 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EE90.409B6140
Content-Type: text/plain;
	charset="iso-8859-1"

> 1) Whether the configured summary address will go as IP 
> internal or external reachability information in the generated LSP's?
>
> 2) If some redistributed routes fall under the summary route 
> (redistributed routes will be sent as IP external 
> reachability information) and if some level 1 routes also
> fall under the same summary route (level 1 to level 2 which 
> should go as IP internal reachability information)
> then how should we advertise that summary route?
> 
> Please clarify my doubts.
> thanks in advance,
> Purush

As to point 2, if you have an internal route to a destination,
there is no need to advertise an external route.  Even if you
did, no one would use it until you withdrew the InternalReach 
route.  

As to point 1, I would assume that routes preserve 'type',
but I can't cite chapter and verse to defend this.  

- jeff parker
- axiowave networks


------_=_NextPart_001_01C0EE90.409B6140
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [Isis-wg] Summary Address</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; 1) Whether the configured summary address will go as IP </FONT>
<BR><FONT SIZE=2>&gt; internal or external reachability information in the generated LSP's?</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; 2) If some redistributed routes fall under the summary route </FONT>
<BR><FONT SIZE=2>&gt; (redistributed routes will be sent as IP external </FONT>
<BR><FONT SIZE=2>&gt; reachability information) and if some level 1 routes also</FONT>
<BR><FONT SIZE=2>&gt; fall under the same summary route (level 1 to level 2 which </FONT>
<BR><FONT SIZE=2>&gt; should go as IP internal reachability information)</FONT>
<BR><FONT SIZE=2>&gt; then how should we advertise that summary route?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Please clarify my doubts.</FONT>
<BR><FONT SIZE=2>&gt; thanks in advance,</FONT>
<BR><FONT SIZE=2>&gt; Purush</FONT>
</P>

<P><FONT SIZE=2>As to point 2, if you have an internal route to a destination,</FONT>
<BR><FONT SIZE=2>there is no need to advertise an external route.&nbsp; Even if you</FONT>
<BR><FONT SIZE=2>did, no one would use it until you withdrew the InternalReach </FONT>
<BR><FONT SIZE=2>route.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>As to point 1, I would assume that routes preserve 'type',</FONT>
<BR><FONT SIZE=2>but I can't cite chapter and verse to defend this.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>- jeff parker</FONT>
<BR><FONT SIZE=2>- axiowave networks</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EE90.409B6140--
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 15:25:48 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08165
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 15:25:47 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA65572;
	Wed, 6 Jun 2001 13:10:08 -0700 (PDT)
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA65557
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 13:09:00 -0700 (PDT)
Received: from tot-wh1-wg.proxy.aol.com (tot-wh1-wg.proxy.aol.com [205.188.196.3])
	  by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id OAA01544 for <isis-wg@external.juniper.net>;
	  Wed, 6 Jun 2001 14:22:31 -0400 (EDT)
Received: from ma.ultranet.com (AC83BA79.ipt.aol.com [172.131.186.121])
	by tot-wh1-wg.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f56IMRX15778
	for <isis-wg@external.juniper.net>; Wed, 6 Jun 2001 14:22:27 -0400 (EDT)
Message-ID: <3B1E9F72.3FFE0CB1@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt
References: <EB5FFC72F183D411B3820006295734296AEF01@r2d2.axiowave.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 06 Jun 2001 14:24:03 -0700
Content-Transfer-Encoding: 7bit

Hi Jeff,

I think we probably agree?  ...but just want to drill down
to the detail to make sure.  I'm beginning implementation
soon and want to ensure I've got a reasonably accurate
understanding of the issues first (much easier to change what 
you haven't coded yet ;-) )

> Jeff Parker wrote:
> 
> > ...two of the original IP TLVs...
> > IP Internal Reachability (Type 128) and IP External Reachability
> > (Type 130) [the only really significant difference between
> > the two being that ExtReach could potentially use external
> > non-comparable type metrics,
> > while IntReach could not... and all reachability using
> > internal metric type, from either TLV, is treated similarly...
> > so the only distinguishing factor boils down to the
> > external metric type or not]
> 
> Just to be clear about this, these metrics are quite different.
> The worst metric for an internal reachability is preferred over
> the best metric in external.  This could be visualized as an
> extra 9th bit that is set for external and cleared for internal.
> This would allow the two metrics to be mapped into a new
> consistent value.

I agree that the metrics (*if distinguished by a different metric
type*) are quite different, but I also believe they are not 
different only based on which TLV they arrive on, and if they
have the same metric type, then it doesn't matter if they're
internalReach or externalReach... at least, that's
my current understanding based on rfc1195 and some prior emails
on this list. Could we agree on one of the prior sentences if
it were changed to say: 
    The worst metric for an internal reachability is preferred over
    the best metric <add:"with external metric type"> in external
    <add:"reachability">.
  
    and, "External Reachability with internal metric type has
    the same preference as Internal Reachability."

I believe that the worst metric for an internal reachability would
not be preferred over a better metric in an external reachability
if that external reachability metric was of internal type (?)  I'm
basing that on my reading of the NOTE on page 29 of rfc1195,
where it says, if I'm interpreting it correctly :-), that
internal routes from Internal Reachability (presumably with internal
metric type since external metric type is illegal there) and external
routes from External Reachability with metric type internal,
are treated identically for the purpose of the order of preference
of routes, and the Dijkstra calc.

The terminology of all this can get quite confusing, with
the terms external and internal applying to both reachability 
as well as the metric type. Looking back, I wish they
could have used a different term for the metric type :-)


> Any route learned from another protocol (BGP, Static, RIP) gets
> an external: any route learned via the IGP gets an internalReach.
> Of course, implementations have been known to import external
> routes as Internal Reachability, but that was not the original
> intention.

Just curious... does anyone know why the original intent
was to separate routes into different reachability types like 
that (if it is indeed true that the only practical difference 
from a route calc point of view is the metric type, not the
reachability type) ?  Was it an aid to network managers in
wading through a bunch of show database output... help them
pick out which routes were from another protocol, based
on the reachability type?


> There is an argument to be made that local policy should define
> how metrics are mapped, and that since IS-IS is an IGP, we only
> need to worry about local policy.  However, I like to have some
> guidelines on interoperation between metric types.  It is bad
> enough that we need to compare two types, with the 2 extra bits,
> without adding an incomperable 3rd metric.

I'm not quite sure I understand the last part about 3rd metric?
As I understand it, today we have two reachability types and
two metric types (internal reach, external reach,
internal metric, external metric). With the new TE draft we now
have a new unnamed extended reachability type and no explicit
metric type... is that the third metric?  
And that's where some potential incompatabilities come in... 
if everyone agrees to treat the new extended one similarly to 
how they would treat the old internal reach with internal metrics, 
then we're fine, but if some folks continue with the external metric 
concept, encoding it in undocumented ways, then we'll have some
interworking problems. My motivation was just to nail it
down one way or the other... deprecate external metric type,
or continue with it but document how to encode it inside the
new extended reachability TLV so implementations will interwork. 

Thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 16:36:26 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08859
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 16:36:25 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA65907;
	Wed, 6 Jun 2001 14:21:08 -0700 (PDT)
Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA65895
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 14:20:11 -0700 (PDT)
Message-ID: <EB5FFC72F183D411B3820006295734296AEF20@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'David Hudek'" <dhudek@ma.ultranet.com>, isis-wg@spider.juniper.net
Subject: RE: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0EEC7.FD536EE0"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 16:33:48 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EEC7.FD536EE0
Content-Type: text/plain;
	charset="iso-8859-1"

 
> I believe that the worst metric for an internal reachability would
> not be preferred over a better metric in an external reachability
> if that external reachability metric was of internal type (?)  I'm
> basing that on my reading of the NOTE on page 29 of rfc1195,
> where it says, if I'm interpreting it correctly :-), that
> internal routes from Internal Reachability (presumably with internal
> metric type since external metric type is illegal there) and external
> routes from External Reachability with metric type internal,
> are treated identically for the purpose of the order of preference
> of routes, and the Dijkstra calc.
> 
> The terminology of all this can get quite confusing, with
> the terms external and internal applying to both reachability 
> as well as the metric type. Looking back, I wish they
> could have used a different term for the metric type :-)

David -
	Have you had a chance to look over RFC 2966?
This is probably the clearest discussion of the various 
combinations of infernal and extortion around.  

	http://ietf.org/rfc/rfc2966.txt

- jeff parker

------_=_NextPart_001_01C0EEC7.FD536EE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; I believe that the worst metric for an internal =
reachability would</FONT>
<BR><FONT SIZE=3D2>&gt; not be preferred over a better metric in an =
external reachability</FONT>
<BR><FONT SIZE=3D2>&gt; if that external reachability metric was of =
internal type (?)&nbsp; I'm</FONT>
<BR><FONT SIZE=3D2>&gt; basing that on my reading of the NOTE on page =
29 of rfc1195,</FONT>
<BR><FONT SIZE=3D2>&gt; where it says, if I'm interpreting it correctly =
:-), that</FONT>
<BR><FONT SIZE=3D2>&gt; internal routes from Internal Reachability =
(presumably with internal</FONT>
<BR><FONT SIZE=3D2>&gt; metric type since external metric type is =
illegal there) and external</FONT>
<BR><FONT SIZE=3D2>&gt; routes from External Reachability with metric =
type internal,</FONT>
<BR><FONT SIZE=3D2>&gt; are treated identically for the purpose of the =
order of preference</FONT>
<BR><FONT SIZE=3D2>&gt; of routes, and the Dijkstra calc.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The terminology of all this can get quite =
confusing, with</FONT>
<BR><FONT SIZE=3D2>&gt; the terms external and internal applying to =
both reachability </FONT>
<BR><FONT SIZE=3D2>&gt; as well as the metric type. Looking back, I =
wish they</FONT>
<BR><FONT SIZE=3D2>&gt; could have used a different term for the metric =
type :-)</FONT>
</P>

<P><FONT SIZE=3D2>David -</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Have you =
had a chance to look over RFC 2966?</FONT>
<BR><FONT SIZE=3D2>This is probably the clearest discussion of the =
various </FONT>
<BR><FONT SIZE=3D2>combinations of infernal and extortion around.&nbsp; =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2><A =
HREF=3D"http://ietf.org/rfc/rfc2966.txt" =
TARGET=3D"_blank">http://ietf.org/rfc/rfc2966.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>- jeff parker</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EEC7.FD536EE0--
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 18:18:25 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09937
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 18:18:24 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA66362;
	Wed, 6 Jun 2001 16:03:09 -0700 (PDT)
Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA66350
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 16:02:33 -0700 (PDT)
Received: (from henk@localhost)
	by redd3174.procket.com (8.11.0/8.9.3) id f56MFnS00779;
	Wed, 6 Jun 2001 15:15:49 -0700
From: Henk Smit <henk@Procket.com>
Message-Id: <200106062215.f56MFnS00779@redd3174.procket.com>
X-Confidential: Procket Confidential/Need to know
Subject: Re: [Isis-wg] History of the External Metric Type?
To: dhudek@ma.ultranet.com (David Hudek)
Cc: isis-wg@spider.juniper.net
In-Reply-To: <3B1458C1.B37EC7A2@ma.ultranet.com> from "David Hudek" at May 29, 2001 07:19:45 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 15:15:49 -0700 (PDT)
Content-Transfer-Encoding: 7bit


      Hello Dave,

> Before embarking on an ISIS implementation, I've been perusing 
> the wg mail archives, and I want to make sure I understand the 
> current status of the (effectively deprecated?) 
> "external metric type" indication (or perhaps more clearly, 
> the non-comparable metric type indication).

  I don't think the internal/external metric-type has been
 totally deprecated. It is still in the spec. And in fact,
 I tried to clarify it a little in rfc2966.

> The following is my current understanding... please
> let me know if it's correct or if I've gone delusional  ;-)
> (and if the latter, what the real situation is, thanks :-) )
> 
> When the spec was first defined, it was thought that
> users might want to inject routes into ISIS from
> other sources, and those other routes might come in
> two flavors: 
>     a) those using metrics which are directly comparable
>        with the metrics used by ISIS, and 
>     b) those using metrics which are NOT comparable
>        with the metrics used by ISIS.
> The "metric type" indication was defined as a mechanism
> for distinguishing between these two types, with
> the comparable metrics being identified as 
> "internal metric type", and the non-comparable metrics
> being identified as "external metric type"
>
> Only the internal metric type was valid for IP Internal 
> Reachability information. Either internal or external
> metric type would be valid for IP External Reachability
> information. IP External Reachability info using
> internal metric type would be treated similarly
> to Internal Reachability info, but IP External Reachability
> info would be less preferred if it used external
> metric type instead.

  Correct.

> Then, the RealWorld(TM) intervened  :-)
> 
> In the dominant early implementation (presumably cisco's),
> the internal/external metric type field was accidentally ignored,
> and all IP Reachability was treated as having internal
> metric type. 

  Yes. But there were in fact three things wrong:
 1) older IOS ignored the internal/external-metric bit on receipt
 2) older IOS would not mask out the first two bits (reserved and
    I/E bit), so during SPF, it would just use the 8-bit value.
 3) when setting the I/E bit (doable via route-maps), it would set
    the wrong bit: it would set bit 8, in stead of bit 7.

  The result would be that if you would manually set the I/E bit,
 the metric would be increased by 128 (2^7). And when the receiving
 routers do their SPF computation, they would handle the prefix as
 if it had a way larger metric. By accident, the results would be
 pretty similar to what you would have gotten if you would have
 just given those prefixes lower preference because of the I/E bit.
 Lucky.

  Maybe if anyone is interested, cisco people can explain the current
 behaviour.

> No one complained.
> 
> It is presumed (known??) that this is because customers never 
> actually made use of the external metric type capability, rather 
> than because they did try to use it but then never noticed odd 
> but still workable routes chosen because of comparing what were 
> intended to be incomparable metrics. 

  IMHO relying on redistribution and detailled redistribution features
 in particular, often points towards a bad network design. (Again, this
 is just my opinion). Leaking all specific routes is often not necessary.
 And if it is, it should be *reachability* information, not necessarily
 *routing* information. Using typical redistribution would cause all
 traffic to go to the closest redistribution-points. If you make metrics
 be advertised between routing domains to force some "further-exit routing"
 behaviour, you are making life more complex than probably necessary.
 Also, leaking metrics between routing domains will make it more likely
 that routing instability in one domain will cause instability in the
 other domain.

  Plus ISPs (the typical users of Integrated IS-IS), often carry as
 much information in BGP as they can. So if you *have* to redistribute
 something from outside your network, they rather redistribute it into
 BGP, in stead of their IGP.

> As long as every interworking implementation calculated things
> in the same manner, loops were avoided, and things worked out
> in a manner satisfactory to the customers.
> 
> Subsequent implementations by others either also ignored the 
> external metric type, or provided a configurable knob to turn 
> its recognition on/off for compatibility purposes and everyone 
> was(is) just turning it off. So far there has apparently not been
> any hue and cry for the restoration of the capability, and
> as a practical matter everyone is fine with only using
> comparable metrics.

  FYI, about 2 years ago, there was one cisco customer that wanted the
 I/E metric bit to work. (Both for IP and CLNS routing). A knob
 was added to turn on the correct behaviour. (My excuses to the list
 for this vendor specific information).

> Given that IP External Reachability with internal metrics
> is treated similarly to IP Internal Reachability, and that
> IP External Reachability with external metrics is not actually used
> in practice, there no longer appears to be any significant difference
> between IP Internal/External Reachability, and so no longer
> any need for separate TLVs.

  Exactly.
 I have never really understood the need for both TLV128 and TLV130.

  This was also one of the reasons why we decided to not carry the
 I/E metric bit semantics forward into TLV135 (the new IP prefix TLV
 defined in the IS-IS TE extensions draft). (The most important
 reason was of course the fact that we had no bits left, and did not
 want to spend another byte per prefix).

> Given all that, and being practical folks, as new enhancements
> were proposed, they were(are) no longer explicitly including the
> capability of distinguishing between internal/external metric type.
> For instance, (if I'm reading it correctly) 
> the ISIS extensions for TE draft-rfc intentionally
> leaves out any internal/external metric type, as well as
> lumping together all IP Reachability into one (extended) type.
> Going forward, the net effect seems to be a deprecation of the 
> comparable/noncomparable metric idea, in favor of all IP reachability 
> info using a single comparable metric type.

  Correct.
 It remains to be seen how long the old TLV128/TLV130 will stay around.
 My guess is it will be a long time .....

> There exists the possibility for subTLVs in the IP Extended
> Reachability, 
> but so far no-one has publicly defined any subTLVs to revive the 
> internal/external (comparable/noncomparable) metric type distinction.
> 
> The above is my best guess as to the current state of
> affairs, treating what had been implied in some earlier emails
> as explicitly true. How far off am I ?  :-)

  You are correct.

> Assuming that the above isn't too far off the mark,
> assuming that implementations will not properly interwork if
> they calculate routes differently (and that they will calculate
> routes differently if one recognizes external metrics and
> treats them differently from internal, while another does not
> recognize external metrics or does but still treats them the same
> as internal),

  See my explication about how interpreting the metric field as a simple
 8-bit value in many cases gives a similar result as interpreting the
 I/E bit in the correct way.

> would it be reasonable for the external
> metric type to be "officially" deprecated and implementers
> strongly encouraged to ignore the external metric type if
> encountered (a "send yours as internal only, and ignore theirs"
> sort of deal), treating all as internal metric type ?

  I have no opinion on that.
  And by judging the (lack of) responses to your email, nobody else
 on this list seems to care in particular for one way or another.

  I'm afaid you'll have to implement the I/E bit semantics, even
 though none of your customers will use it. Sorry. :-)

      henk.

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 18:28:17 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10008
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 18:28:14 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA66429;
	Wed, 6 Jun 2001 16:13:09 -0700 (PDT)
Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA66417
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 16:12:25 -0700 (PDT)
Received: (from henk@localhost)
	by redd3174.procket.com (8.11.0/8.9.3) id f56MPgn00796;
	Wed, 6 Jun 2001 15:25:42 -0700
From: Henk Smit <henk@Procket.com>
Message-Id: <200106062225.f56MPgn00796@redd3174.procket.com>
X-Confidential: Procket Confidential/Need to know
Subject: Re: [Isis-wg] Summary Address
To: purush_isis@rediffmail.com (Purushothaman NandaKumaran)
Cc: isis-wg@spider.juniper.net (isis-wg@external.juniper.net)
In-Reply-To: <20010606074246.16361.qmail@mailweb25.rediffmail.com> from "Purushothaman  NandaKumaran" at Jun 06, 2001 07:42:46 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 15:25:42 -0700 (PDT)
Content-Transfer-Encoding: 7bit


> I have some doubts in advertising summary routes.
> 
> 1) Whether the configured summary address will go as IP internal or
>     external reachability information in the generated LSP's?

  Not defined anywhere, AFAIK.

> 2) If some redistributed routes fall under the summary route
>     (redistributed routes will be sent as IP external reachability
>     information) and if some level 1 routes also > fall under the same
>     summary route (level 1 to level 2 which should go as IP internal
>     reachability information) > then how should we advertise that summary
>     route?

  Not defined anywhere, AFAIK.

> Please clarify my doubts.

  See RFC1195.
 We quote the relevant section in rfc2966.

   RFC 1195 states this quite clearly in the note in paragraph 3.10.2,
   item 2c).  This document does not alter this rule of preference.

       NOTE: Internal routes (routes to destinations announced in the
       "IP Internal Reachability Information" field), and external
       routes using internal metrics (routes to destinations announced
       in the "IP External Reachability Information" field, with a
       metric of type "internal") are treated identically for the
       purpose of the order of preference of routes, and the Dijkstra
       calculation.

  So for route computation, it doesn't matter if you advertise your
 summaries as TVL128 or TVL130. So if it doesn't create routing loops,
 doesn't create suboptimal routing, and doesn't create interoperability
 problems, this problem is non-relevant. Some routers can advertise their
 summaries in TVL128, some might advertise summaries in TVL130. No problem.

  Pick whatever you like best .....
 Hope this helps.

       henk.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 18:34:49 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10047
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 18:34:49 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA66521;
	Wed, 6 Jun 2001 16:20:09 -0700 (PDT)
Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA66506
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 16:19:59 -0700 (PDT)
Received: (from henk@localhost)
	by redd3174.procket.com (8.11.0/8.9.3) id f56MWeU00814;
	Wed, 6 Jun 2001 15:32:40 -0700
From: Henk Smit <henk@Procket.com>
Message-Id: <200106062232.f56MWeU00814@redd3174.procket.com>
X-Confidential: Procket Confidential/Need to know
Subject: Re: [Isis-wg] Summary Address
To: jparker@axiowave.com (Jeff Parker)
Cc: purush_isis@rediffmail.com ('Purushothaman NandaKumaran'),
        isis-wg@spider.juniper.net ('isis-wg@spider.juniper.net')
In-Reply-To: <EB5FFC72F183D411B3820006295734296AEF02@r2d2.axiowave.com> from "Jeff Parker" at Jun 06, 2001 09:54:49 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 15:32:40 -0700 (PDT)
Content-Transfer-Encoding: 7bit


> As to point 1, I would assume that routes preserve 'type',
> but I can't cite chapter and verse to defend this.  

  Would be nice if you do this, but only for administrative
 purposes, like debugging. No need to bother if all you care
 about is preventing routing loops and interoperability.

  Come to think of it, the subject of summaries might become
 a little more tricky once you have to deal with L2->L1 leaked
 routes.

     henk.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 18:55:20 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10213
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 18:55:19 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA66635;
	Wed, 6 Jun 2001 16:40:09 -0700 (PDT)
Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA66615
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 16:39:18 -0700 (PDT)
Message-ID: <EB5FFC72F183D411B3820006295734296AEF30@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Henk Smit'" <henk@Procket.com>, Jeff Parker <jparker@axiowave.com>
Cc: purush_isis@rediffmail.com, isis-wg@spider.juniper.net
Subject: RE: [Isis-wg] Summary Address
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0EEDB.5B175C40"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 18:52:25 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EEDB.5B175C40
Content-Type: text/plain;
	charset="iso-8859-1"


>   Come to think of it, the subject of summaries might become
>  a little more tricky once you have to deal with L2->L1 leaked
>  routes.
> 
>      henk.

I would assume we should prohibit a L2->L1 route from being
summarized in L1.  

- jdp 

------_=_NextPart_001_01C0EEDB.5B175C40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [Isis-wg] Summary Address</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp; Come to think of it, the subject of summaries might become</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; a little more tricky once you have to deal with L2-&gt;L1 leaked</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; routes.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; henk.</FONT>
</P>

<P><FONT SIZE=2>I would assume we should prohibit a L2-&gt;L1 route from being</FONT>
<BR><FONT SIZE=2>summarized in L1.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>- jdp </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EEDB.5B175C40--
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 19:23:40 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10513
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 19:23:40 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA00419;
	Wed, 6 Jun 2001 16:22:10 -0700 (PDT)
Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA00403
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 16:21:49 -0700 (PDT)
Received: (from henk@localhost)
	by redd3174.procket.com (8.11.0/8.9.3) id f56NLBe01001;
	Wed, 6 Jun 2001 16:21:11 -0700
From: Henk Smit <henk@Procket.com>
Message-Id: <200106062321.f56NLBe01001@redd3174.procket.com>
X-Confidential: Procket Confidential/Need to know
Subject: Re: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt
To: dhudek@ma.ultranet.com (David Hudek)
Cc: isis-wg@spider.juniper.net
In-Reply-To: <3B1D92CC.9E0DC03@ma.ultranet.com> from "David Hudek" at Jun 05, 2001 07:17:48 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 16:21:11 -0700 (PDT)
Content-Transfer-Encoding: 7bit


> The latest ISIS TE draft I could find is the one mentioned in the 
> subject. Assuming that's the latest, or that a later one has 
> similar treatment (non-treatment) of external metric type, I'd like
> to offer the following comments/suggestions.

  Yes, version 02 is the lastest.
 I have been planning on releasing a 03 version for a long time.
 It will only have marginal changes (wording, not really semantics).
 RealSoonNow (sorry for the delay ....).

> First, let me say I'm no big fan of the external metric type, and 
> it wouldn't bother me if it were to just fade away.

  If the whole world moves to TLV22 and TVL135, the old TLVs TLV128
 and TLV130 might go away. But I don't see that happening. So whatever
 we decide to do in the future, the fact will always remain that you
 will have to implement the old behaviour from RFC1195, for backwards
 compatability. No matter what.

> However, I'm more concerned with implementations' interoperability,
> and so if it is going away, I'd like to see it do so in an orderly 
> manner. If it's not going away, I'd like to see it defined in the 
> relevant message. 

  RFC1195 defines behaviour.
 I tried to clarify all route and metric types, and their preferences
 in RFC2966. I assume you read RFC2966. If not, please read it and
 tell us what parts you think are not clear. (I'm sorry if I messed
 up and blew the chance we had to clarify it).

> It's troubling to read of some folks just picking undocumented random
> bits in the message to indicate metric type,
> while others do nothing and ignore it,

  Are you refering to the old cisco behaviour of picking bit-8 as
 the I/E bit, in stead of bit-7 ? That is clearly a bug, not picking
 random undocumented bits.

> and some talk of using an unspecified subTLV.

  This has been suggested to people who wanted I/E metric-type semantics
 in TLV135. That doesn't meant they implemented it, or their customers
 deployed it. I would assume that if anyone would implent something like
 this, they would try to document it before letting their customers
 deploy it on a grand scale.

> Besides other nice stuff, the new Extended TLV uses a wider metric. 
> To my knowledge, no official subTLVs have been defined for it,

  Correct.

> and it intentionally makes no mention of the metric type. The rationale 
> mentioned so far for this omission is that no one is using the 
> non-comparable "external" metric type,

  Correct. Plus we didn't have a spare bit. Plus we (the draft authors)
 didn't like to add complexity with little gain. So far no one has been
 able to convince the working group that we absolutely need I/E metric-type.

> and implementers could just 
> assume that info supplied via the Extended IP Reachability TLV
> should be treated as though it had comparable "internal" metrics.

  No sure what you mean here ?
 TLV128/TLV130 are to be seen totally disjunct from TLV135.
 Networks should not be combining them. (Maybe they can be flooded
 in parallel while a network migrates from the old to the new TLVs,
 but you should *never* have some routers use the old metrics during
 SPF, and some other routers the new metrics).

> However, that sort of advice has only been given via the mailing list 
> and is not part of the (draft) rfc itself, where a future implementer 
> could readily find it.

  I tried to clarify all route-types and metric-types from RFC1195,
 plus "route leaking" in RFC2966. The TE-extensions TLVs are totally
 disjunct from that.

> Also, it is not clear that the rationale is 
> correct, since at least one person posted to the list in the past that 
> they intended to make use of some otherwise unused bit to indicate the
> external metric type in their implementation. Others have mentioned 
> using an undocumented subTLV type.

  As long as they don't post a draft, and don't pass the requirements to
 turn the draft into an RFC (even an experimental rfc), they can not
 go tell their customers anything else but that they have implemented
 a proprietary extension. Nothing wrong with proprietary extensions, but
 customers might decide not to bother with the hassle.

> Can we decide if external metric type is *actually required*
> (seems to be some disagreement?), and either:
> 
>     a) explicitly deprecate it in the TE spec.
>        Some verbiage to the effect that the external metric
>        type is no longer supported, and any metrics
>        received via the Extended IP Reachability TLV
>        MUST be treated as having comparable ("internal")
>        metrics (is there anyone on the list who would
>        strongly oppose such a thing?)
> 
>        OR
> 
>     b) explicitly specify a subTLV in which to convey the
>        metric type. For a stake in the ground, how about
>        something like the following (using least sig bit
>        in the value as internal/external type, other bits
>        sent as zero and ignored upon receipt), and since
>        we only need one bit and it seems so wasteful to
>        spend 3 octets to convey one bit's worth of data,
>        possibly generalize the new subTLV into an
>        "Extended Control Info" type for future general use 
>        of the other bits if needed? :
> 
>        Extended Control Type SubTLV
>           Sub-TLV Type:     1
>           Sub-TLV Length:   1
> 	  Sub-TLV Values:   0 if metric is comparable (internal type)
>                             1 if metric is non-comparable (external
> type)
> 
>        If someone really really demanded symmetry with the
>        old TLVs, one could use the second least sig bit
>        to indicate internal or external reachability,
>        but it's not clear that buys you anything?...
>        (but for completeness, could use these values instead,
>         with the upper 6 bits reserved, zeroed on send, ignored on
> receipt)
>           00 - metric is internal reach/comparable metric type
>           01 - metric is internal reach/non-comparable metric type
> (illegal?)
>           10 - metric is external reach/comparable metric type
>           11 - metric is external reach/non-comparable metric type)
> 
> 
> If it's true that there's no real justification for external metric
> type,
> then I'd favor (a). If there are valid reasons for having it, then I'd 
> favor something along the lines of (b) with things at least nailed down 
> sufficiently for an implementation.

  When you write an ISIS implementation that is supposed to be compatible
 with RFC1195 and RFC2966, you better implement external metric. Sorry.
 When you implement the extensions from the te-draft, you can forget
 about I/E metrics. If you wanna be compatible with both, you better
 implement both algorithms. Not really rocket-science, IMHO, just a
 small matter of coding. :-)

   Hope this helps,

       henk.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun  6 22:10:22 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12861
	for <isis-archive@odin.ietf.org>; Wed, 6 Jun 2001 22:10:22 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA01439;
	Wed, 6 Jun 2001 19:09:09 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA01427
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 19:08:50 -0700 (PDT)
Received: from tot-ntc-ta.proxy.aol.com (tot-ntc-ta.proxy.aol.com [198.81.16.1])
	  by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id WAA17927 for <isis-wg@external.juniper.net>;
	  Wed, 6 Jun 2001 22:01:38 -0400 (EDT)
Received: from ma.ultranet.com (ACB57F4C.ipt.aol.com [172.181.127.76])
	by tot-ntc-ta.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f5721ad25192
	for <isis-wg@external.juniper.net>; Wed, 6 Jun 2001 19:01:36 -0700 (PDT)
Message-ID: <3B1F0B0C.36CA2B5B@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 06 Jun 2001 22:03:08 -0700
Content-Transfer-Encoding: 7bit

Hi Henk,

Thanks for the info. Regarding the metric types,
as a new reader of the draft, I interpreted the new
Extended Reach as the successor to the old 128/130
and assumed (always dangerous! :-)) that the old
semantics applied to the new TLV unless otherwise
noted (and then wondered where the darn metric type info 
had hidden :-)). I wonder, since there is already some
text about how the new Extended Reachability differs 
from the old TLVs (e.g., wider metric, upDown bit, 
different prefix encoding), and given that there have 
been a few folks asking about the metric type, could 
perhaps a simple sentence about no differing metric type 
support be added?  No biggie since I now understand the 
intent, but it might help in the future.

>> and implementers could just 
>> assume that info supplied via the Extended IP Reachability TLV
>> should be treated as though it had comparable "internal" metrics.
>
>  No sure what you mean here ?
> TLV128/TLV130 are to be seen totally disjunct from TLV135.
> Networks should not be combining them. (Maybe they can be flooded
> in parallel while a network migrates from the old to the new TLVs,
> but you should *never* have some routers use the old metrics during
> SPF, and some other routers the new metrics).

What I was trying to get at here is the question of what
the preference rules should be in an environment where there 
is no longer such a thing as a metric type (since the existing 
rules take the metric type into account, but the new Extended Reach 
has no metric type information). What I think was suggested
was to take the old preference rules, throw out
those that keyed off of external metric type, and
use those rules that only depended on internal metric type
as though the metric in the Extended Reach is
comparable (as though internal type). 

If I've read RFC2966 properly, it appears that the only 
key pieces of information in the preference rules are
the LSP Level, the UpDown bit, and the metric type
(other info, such as TLV type boils away)... yielding
something like the following:

Pref 1: L1 IntMet UD0 (128 or 130 a dont-care)
Pref 2: L2 IntMet UD0 (128 or 130 a dont-care)
Pref 3: L1 IntMet UD1 (128 or 130 a dont-care)
Pref 4: L1 ExtMet UD0 
Pref 5: L2 ExtMet UD0 
Pref 6: L1 ExtMet UD1 

where UD# is updown status 0 or 1, IntMet/ExtMet are
internal/external metric type.

Is it envisioned that the preference rules after
switching to the Extended Reach will be like the
first three, so something like
   Pref 1: L1 UD0 
   Pref 2: L2 UD0 
   Pref 3: L1 UD1 

or is something different planned?
Is there any documentation that discusses
what the preference rules should be when running
with the new Extended Metric TLV?

Thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Thu Jun  7 00:30:04 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15470
	for <isis-archive@odin.ietf.org>; Thu, 7 Jun 2001 00:30:04 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA02043;
	Wed, 6 Jun 2001 21:27:09 -0700 (PDT)
Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA02031
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 21:26:14 -0700 (PDT)
Received: (from henk@localhost)
	by redd3174.procket.com (8.11.0/8.9.3) id f574PgZ01488;
	Wed, 6 Jun 2001 21:25:42 -0700
From: Henk Smit <henk@Procket.com>
Message-Id: <200106070425.f574PgZ01488@redd3174.procket.com>
X-Confidential: Procket Confidential/Need to know
Subject: Re: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt
To: dhudek@ma.ultranet.com (David Hudek)
Cc: isis-wg@spider.juniper.net
In-Reply-To: <3B1F0B0C.36CA2B5B@ma.ultranet.com> from "David Hudek" at Jun 06, 2001 10:03:08 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 21:25:41 -0700 (PDT)
Content-Transfer-Encoding: 7bit


> I wonder, since there is already some
> text about how the new Extended Reachability differs 
> from the old TLVs (e.g., wider metric, upDown bit, 
> different prefix encoding), and given that there have 
> been a few folks asking about the metric type, could 
> perhaps a simple sentence about no differing metric type 
> support be added?  No biggie since I now understand the 
> intent, but it might help in the future.

  OK, will do.

> What I was trying to get at here is the question of what
> the preference rules should be in an environment where there 
> is no longer such a thing as a metric type (since the existing 
> rules take the metric type into account, but the new Extended Reach 
> has no metric type information). What I think was suggested
> was to take the old preference rules, throw out
> those that keyed off of external metric type, and
> use those rules that only depended on internal metric type
> as though the metric in the Extended Reach is
> comparable (as though internal type). 

  Yes. Everything the same order, just simplified by having less
 types of routes. 

> If I've read RFC2966 properly, it appears that the only 
> key pieces of information in the preference rules are
> the LSP Level, the UpDown bit, and the metric type
> (other info, such as TLV type boils away)... yielding
> something like the following:
> 
> Pref 1: L1 IntMet UD0 (128 or 130 a dont-care)
> Pref 2: L2 IntMet UD0 (128 or 130 a dont-care)
> Pref 3: L1 IntMet UD1 (128 or 130 a dont-care)
> Pref 4: L1 ExtMet UD0 
> Pref 5: L2 ExtMet UD0 
> Pref 6: L1 ExtMet UD1 
> 
> where UD# is updown status 0 or 1, IntMet/ExtMet are
> internal/external metric type.

  I think RFC2966 is very precise on that. See paragraph 3.2, called
 Order of preference for all types of IP routes in IS-IS.

--snip----

     Based on these assumptions, this document defines the following route
      preferences.

       1) L1 intra-area routes with internal metric
          L1 external routes with internal metric
       2) L2 intra-area routes with internal metric
          L2 external routes with internal metric
          L1->L2 inter-area routes with internal metric
          L1->L2 inter-area external routes with internal metric
       3) L2->L1 inter-area routes with internal metric
          L2->L1 inter-area external routes with internal metric
       4) L1 external routes with external metric
       5) L2 external routes with external metric
          L1->L2 inter-area external routes with external metric
       6) L2->L1 inter-area external routes with external metric

--snip----

  So that is very similar to what you describe.


> Is it envisioned that the preference rules after
> switching to the Extended Reach will be like the
> first three, so something like
>    Pref 1: L1 UD0 
>    Pref 2: L2 UD0 
>    Pref 3: L1 UD1 

  Correct. Otherwise you get routing loops.

> or is something different planned?
> Is there any documentation that discusses
> what the preference rules should be when running
> with the new Extended Metric TLV?

  I had thought it was clear. I will add some text in the upcoming
 version of the draft.

     henk.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Thu Jun  7 00:33:49 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15501
	for <isis-archive@odin.ietf.org>; Thu, 7 Jun 2001 00:33:49 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA02080;
	Wed, 6 Jun 2001 21:31:10 -0700 (PDT)
Received: from mailweb4.rediffmail.com ([202.54.124.149])
	by external.juniper.net (8.9.3/8.9.3) with SMTP id VAA02046
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 21:27:35 -0700 (PDT)
Received: (qmail 16050 invoked by uid 510); 7 Jun 2001 04:32:37 -0000
Message-ID: <20010607043237.16049.qmail@mailweb4.rediffmail.com>
Received: from unknown (202.108.17.86) by rediffmail.com via HTTP; 07 Jun 2001 04:32:37 -0000
MIME-Version: 1.0
To: "henk@Procket.com" <henk@Procket.com>
Subject:  Re: Re: [Isis-wg] Summary Address
CC: "isis-wg@spider.juniper.net (isis-wg@external.juniper.net)" <isis-wg@spider.juniper.net>
From: "Purushothaman  NandaKumaran" <purush_isis@rediffmail.com>
Content-ID: <Thu_Jun__7_10_02_37_IST_2001_0@mailweb4.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: 7 Jun 2001 04:32:37 -0000
Content-Transfer-Encoding: 7bit

Hi all,
Thanks for replying.
My doubt got extended.
What happens if some external route with external metric falls on that summary route?
Can we make metric and metric type configurable in the summary address table of the mib and leave the problem to the administrator?
thanks
with best regards,
Purush

------------- Original Message --------------
Henk Smit <henk@Procket.com> wrote:
To:purush_isis@rediffmail.com (Purushothaman NandaKumaran)
From:Henk Smit <henk@Procket.com>
Date:Wed, 6 Jun 2001 15:25:42 -0700 (PDT)
CC:isis-wg@spider.juniper.net (isis-wg@external.juniper.net)
Subject:Re: [Isis-wg] Summary Address


> I have some doubts in advertising summary routes.
> 
> 1) Whether the configured summary address will go as IP internal or
>     external reachability information in the generated LSP's?

  Not defined anywhere, AFAIK.

> 2) If some redistributed routes fall under the summary route
>     (redistributed routes will be sent as IP external reachability
>     information) and if some level 1 routes also > fall under the same
>     summary route (level 1 to level 2 which should go as IP internal
>     reachability information) > then how should we advertise that summary
>     route?

  Not defined anywhere, AFAIK.

> Please clarify my doubts.

  See RFC1195.
 We quote the relevant section in rfc2966.

   RFC 1195 states this quite clearly in the note in paragraph 3.10.2,
   item 2c).  This document does not alter this rule of preference.

       NOTE: Internal routes (routes to destinations announced in the
       "IP Internal Reachability Information" field), and external
       routes using internal metrics (routes to destinations announced
       in the "IP External Reachability Information" field, with a
       metric of type "internal") are treated identically for the
       purpose of the order of preference of routes, and the Dijkstra
       calculation.

  So for route computation, it doesn't matter if you advertise your
 summaries as TVL128 or TVL130. So if it doesn't create routing loops,
 doesn't create suboptimal routing, and doesn't create interoperability
 problems, this problem is non-relevant. Some routers can advertise their
 summaries in TVL128, some might advertise summaries in TVL130. No problem.

  Pick whatever you like best .....
 Hope this helps.

       henk.

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com




_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Thu Jun  7 00:43:28 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15554
	for <isis-archive@odin.ietf.org>; Thu, 7 Jun 2001 00:43:27 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA02169;
	Wed, 6 Jun 2001 21:41:10 -0700 (PDT)
Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA02157
	for <isis-wg@spider.juniper.net>; Wed, 6 Jun 2001 21:40:56 -0700 (PDT)
Received: (from henk@localhost)
	by redd3174.procket.com (8.11.0/8.9.3) id f574eHJ01545;
	Wed, 6 Jun 2001 21:40:17 -0700
From: Henk Smit <henk@Procket.com>
Message-Id: <200106070440.f574eHJ01545@redd3174.procket.com>
X-Confidential: Procket Confidential/Need to know
Subject: Re: Re: [Isis-wg] Summary Address
To: purush_isis@rediffmail.com (Purushothaman NandaKumaran)
Cc: isis-wg@spider.juniper.net
In-Reply-To: <20010607043237.16049.qmail@mailweb4.rediffmail.com> from "Purushothaman  NandaKumaran" at Jun 07, 2001 04:32:37 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 6 Jun 2001 21:40:17 -0700 (PDT)
Content-Transfer-Encoding: 7bit


> What happens if some external route with external metric falls on
> that summary route?

  Summary-addresses are advertised in combination with a metric.
 If you have 10 routes that are more specific to that summary-address,
 each route with a different metric, what metric will you choose to be
 advertised for the summary ?
  Answer is simple: you take the lowest metric of all metrics associated
 with all the more specifics.

  Apply that rule to the internal/external metric-type situation .....

  You can view internal metrics as metrics that are always lower (better)
 than any external metrics. So if you apply the rule above to the
 internal/external metric-type situation, it is easy to see that if
 a summary has some specifics with internal metric and some specifics
 with external metric, the logic forces you to advertise the summary
 with an internal metric.

> Can we make metric and metric type configurable in the summary
> address table of the mib and leave the problem to the administrator?

  Ugh. A very cowardly solution. :-) ;-)
 As I explain above, there is no need to leave this unsolved. 

     henk.

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Thu Jun  7 13:54:59 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11515
	for <isis-archive@odin.ietf.org>; Thu, 7 Jun 2001 13:54:58 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA05496;
	Thu, 7 Jun 2001 10:53:10 -0700 (PDT)
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA05484
	for <isis-wg@spider.juniper.net>; Thu, 7 Jun 2001 10:52:45 -0700 (PDT)
Received: from tot-wg.proxy.aol.com (tot-wg.proxy.aol.com [205.188.196.1])
	  by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id NAA27536 for <isis-wg@external.juniper.net>;
	  Thu, 7 Jun 2001 13:52:04 -0400 (EDT)
Received: from ma.ultranet.com (ACBAA0A4.ipt.aol.com [172.186.160.164])
	by tot-wg.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f57Hq2C17730
	for <isis-wg@external.juniper.net>; Thu, 7 Jun 2001 13:52:02 -0400 (EDT)
Message-ID: <3B1FE9D0.4DE63A00@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt
References: <200106070425.f574PgZ01488@redd3174.procket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Thu, 07 Jun 2001 13:53:36 -0700
Content-Transfer-Encoding: 7bit

Henk Smit wrote:
> > Is it envisioned that the preference rules after
> > switching to the Extended Reach will be like the
> > first three, so something like
> >    Pref 1: L1 UD0
> >    Pref 2: L2 UD0
> >    Pref 3: L1 UD1
> 
>   Correct. Otherwise you get routing loops.
> 
> > or is something different planned?
> > Is there any documentation that discusses
> > what the preference rules should be when running
> > with the new Extended Metric TLV?
> 
>  I had thought it was clear. I will add some text in the upcoming
>  version of the draft.

Great, thanks...

It certainly is the reasonable pref order, and is implied
in several places, but I think that making it crystal clear with 
an explicit statement would be a GoodThing

Either stating them for the new Extended Reachability
universe, or a simple statement that the preference
rules in rfc2966 will apply using the interpretation that
routes learned via the Extended Reach must be treated
as though they had an internal metric type for the
purpose of preference calculations ?

Otherwise, someone could argue that the preference order
is unspecified, since none of the rules mentioned earlier
--snip----
     Based on these assumptions, this document defines the following
route
     preferences.
       1) L1 intra-area routes with internal metric
          L1 external routes with internal metric
       2) L2 intra-area routes with internal metric
          L2 external routes with internal metric
          L1->L2 inter-area routes with internal metric
          L1->L2 inter-area external routes with internal metric
       3) L2->L1 inter-area routes with internal metric
          L2->L1 inter-area external routes with internal metric
       4) L1 external routes with external metric
       5) L2 external routes with external metric
          L1->L2 inter-area external routes with external metric
       6) L2->L1 inter-area external routes with external metric
--snip----
actually apply, since none of them match an unspecified metric type
(all require either internal or external for a match), and
the Extended Reach currently has an unspecified metric type.

The ordering for Extended Reach is strongly implied by the 
first and fourth assumptions in the paragraph prior to the
above rule set, but after painful experiences with some other 
protocols where things were assumed or implied but not specified,
I suppose I've become paranoid :-)  

Thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Thu Jun  7 20:54:14 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16813
	for <isis-archive@odin.ietf.org>; Thu, 7 Jun 2001 20:54:13 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA07143;
	Thu, 7 Jun 2001 17:52:09 -0700 (PDT)
Received: from yarilo.pluris.com ([208.227.9.200])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA07131
	for <isis-wg@spider.juniper.net>; Thu, 7 Jun 2001 17:51:36 -0700 (PDT)
Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA27760;
	Thu, 7 Jun 2001 17:50:29 -0700 (PDT)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <LM1KGA03>; Thu, 7 Jun 2001 17:50:28 -0700
Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A412@avalon.pluris.com>
From: Les  Ginsberg <ginsberg@pluris.com>
To: "'Tony Przygienda'" <prz@net4u.ch>, isis-wg@spider.juniper.net
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Isis-wg] TLV Assignment Conflict
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Thu, 7 Jun 2001 17:50:25 -0700


> 2. Optional checksums goes last call, no comments since a while,
>    implementation works from all I heard.
> 



Sorry for the VERY belated response here, but I just noticed this issue on a
recent review of the revised second edition draft of ISO 10589.

There is a TLV assignment conflict between the TLV assigned in
<draft-ietf-isis-wg-snp-checksum-01.txt>

     TLV Type = 12

and the new TLVs introduced by the SIF work on mismatched LSPBufferSize
which were assigned

   TLV Type 12 - originatingL1LSPBufferSize
   TLV Type 13 - originatingL2LSPBufferSize

As a matter of history, the SIF proposal was published in 1998 both within
SIF and to this group. The new TLVs are now part of the revised Second
Edition draft of ISO 10589 which is pretty much in its final form and
winding its way through the ISO approval process. 

I would not begin to speculate on the number of implementations affected by
a change to one or the other - but clearly some folks are going to be
affected by whichever TLV is reassigned.

Given that no entity/person has taken responsibility for assigning TLV
codes, I suppose this was inevitable - and I am not sure how this gets
resolved - but clearly it needs to be resolved. 

It is unfortunate that no one, including myself, ever noticed this before,
but...

   Les




_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun  8 13:42:16 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17979
	for <isis-archive@odin.ietf.org>; Fri, 8 Jun 2001 13:42:15 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA11231;
	Fri, 8 Jun 2001 10:41:10 -0700 (PDT)
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA11219
	for <isis-wg@spider.juniper.net>; Fri, 8 Jun 2001 10:40:56 -0700 (PDT)
Received: from tot-wh1-wg.proxy.aol.com (tot-wh1-wg.proxy.aol.com [205.188.196.3])
	  by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id NAA00681 for <isis-wg@external.juniper.net>;
	  Fri, 8 Jun 2001 13:40:35 -0400 (EDT)
Received: from ma.ultranet.com (AC8C80AA.ipt.aol.com [172.140.128.170])
	by tot-wh1-wg.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f58HeVX26396
	for <isis-wg@external.juniper.net>; Fri, 8 Jun 2001 13:40:31 -0400 (EDT)
Message-ID: <3B213895.F816FAAF@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04.txt]
References: <EB5FFC72F183D411B3820006295734296AEEE9@r2d2.axiowave.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 08 Jun 2001 13:41:57 -0700
Content-Transfer-Encoding: 7bit

> Jeff Parker wrote:
> Any comments from the list about the relevance
> of summaries from {L1, L2} into {L1, L2}?
> (That is, which of the four possibilities make sense)
> Does it make sense to summarize L2 into L1?

I'll take a stab at this...

Of the possible combinations {L1,L2} into {L1,L2},
I believe that L1->L2 and L2->L1 are already
specified (in rfc1195 and rfc2966) 

I'm not sure L1->L1 or L2->L2 makes sense?
At least, I can't find any specification for
L1->L1 or L2->L2 summarization in the ISIS rfcs.

As far as I know, only two of the four combinations
are "legal"

That brings up the question of other combinations,
though, which as far as I know, have been implementation
dependent?  Would it be a good or bad idea to
standardize them a bit and possibly include
them in the ISIS MIB? Such as summarizing other
protocols' routes when injecting/redistributing
them into a particular level of ISIS.
Say, one wanted to inject BGP routes into L2 ISIS,
but was willing to sacrifice some accuracy for
better scalability by summarizing those routes first.
I don't see a mechanism in the MIB for doing that?
One might have four summarization types: L1ToL2,
L2ToL1, OtherProtToL1, OtherProtToL2.
But that opens a can of worms... what if one
wanted different rules for different "other" protocols...
would there need to be separate types for each
and every other protocol to L1 and L2 ISIS...
or would just one type which applied to all
other protocols be satisfactory?

Thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun  8 14:11:15 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18385
	for <isis-archive@odin.ietf.org>; Fri, 8 Jun 2001 14:11:14 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA11379;
	Fri, 8 Jun 2001 11:10:09 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA11364
	for <isis-wg@spider.juniper.net>; Fri, 8 Jun 2001 11:09:55 -0700 (PDT)
Received: from tot-wg.proxy.aol.com (tot-wg.proxy.aol.com [205.188.196.1])
	  by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id OAA23941 for <isis-wg@external.juniper.net>;
	  Fri, 8 Jun 2001 14:09:27 -0400 (EDT)
Received: from ma.ultranet.com (AC8C80AA.ipt.aol.com [172.140.128.170])
	by tot-wg.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f58I9FC04070
	for <isis-wg@external.juniper.net>; Fri, 8 Jun 2001 14:09:16 -0400 (EDT)
Message-ID: <3B213F53.3585C578@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04.txt]
References: <EB5FFC72F183D411B3820006295734296AEEE9@r2d2.axiowave.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 08 Jun 2001 14:10:43 -0700
Content-Transfer-Encoding: 7bit


There was discussion on another thread ("Summary Address")
that might affect the MIB as well...

In discussing how one ought to advertise a summary address,
a suggestion was made (paraphrasing here...)
to advertise the summary address using the lowest metric
from among those routes that matched the summary.

My understanding from rfc1195 (section 3.2) was that one should 
instead advertise the summary using a set metric which was 
manually configured (and the draft MIB has such a field...
the isisSummAddrDefaultMetric)

Actually, 1195 does use the word "may" in there somewhere :-)
so there's a fair amount of leeway in how folks implement it.

I was wondering if it might not be a good idea to make
it explicit how one was summarizing, and perhaps add to
the MIB either a control knob (telling ISIS how to
summarize:  a)use configured metric as specified in
the isisSummAddrTable, b)ignore it and aggressively use the 
smallest metric from among the routes which match,
or c)ignore it and conservatively use the largest metric
from among the routes which match), or alternatively a
read-only value in which the ISIS implementation just
tells which scheme it is using but cannot be told
to act differently.

I think a network administrator might be confused/upset
if they set the metric value in the table, assuming it
would be used, but then the implementations do something 
different. If neither the control knob nor the information 
field seem appropriate, perhaps the text surrounding
the metric field in the summary table should be
modified to say that this is only a suggested metric
and that implementations may do something different?

Thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sun Jun 10 20:03:41 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14845
	for <isis-archive@odin.ietf.org>; Sun, 10 Jun 2001 20:03:40 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA25840;
	Sun, 10 Jun 2001 17:01:09 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA25828
	for <isis-wg@spider.juniper.net>; Sun, 10 Jun 2001 17:00:11 -0700 (PDT)
Received: from tot-tj.proxy.aol.com (tot-tj.proxy.aol.com [152.163.213.131])
	  by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id TAA17645 for <isis-wg@external.juniper.net>;
	  Sun, 10 Jun 2001 19:59:05 -0400 (EDT)
Received: from ma.ultranet.com (AC933417.ipt.aol.com [172.147.52.23])
	by tot-tj.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f5ANx4h19977
	for <isis-wg@external.juniper.net>; Sun, 10 Jun 2001 19:59:04 -0400 (EDT)
Message-ID: <3B243454.482C3C41@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Subject: [Isis-wg] Other than 6 octet ID ?
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sun, 10 Jun 2001 20:00:36 -0700
Content-Transfer-Encoding: 7bit

Hi all,

As I understand it, the ISIS specification allows the ID field 
of a NET to vary from between 1 to 8 octets, with the constraint 
that everyone within a routing domain must use the same ID size.

Is anyone anywhere actually using an ID size other than 6 octets?
Would it be correct to say that as a practical matter the
ID is fixed at 6 octets?  Or are alternate ID sizes commonly
deployed in real networks?

adTHANKSvance,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Mon Jun 11 08:56:50 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09026
	for <isis-archive@odin.ietf.org>; Mon, 11 Jun 2001 08:56:50 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA28958;
	Mon, 11 Jun 2001 05:54:09 -0700 (PDT)
Received: from cisco.com (jaws.cisco.com [198.135.0.150])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA28946
	for <isis-wg@spider.juniper.net>; Mon, 11 Jun 2001 05:53:10 -0700 (PDT)
Received: from mshand-w2k.cisco.com ([161.44.134.15])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA26034;
	Mon, 11 Jun 2001 13:52:04 +0100 (BST)
Message-Id: <4.3.2.7.2.20010611134855.03469d70@jaws.cisco.com>
X-Sender: mshand@jaws.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: David Hudek <dhudek@ma.ultranet.com>
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] Other than 6 octet ID ?
Cc: isis-wg@spider.juniper.net
In-Reply-To: <3B243454.482C3C41@ma.ultranet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Mon, 11 Jun 2001 13:49:44 +0100

At 20:00 10/06/2001 -0700, David Hudek wrote:
>Hi all,
>
>As I understand it, the ISIS specification allows the ID field
>of a NET to vary from between 1 to 8 octets, with the constraint
>that everyone within a routing domain must use the same ID size.
>
>Is anyone anywhere actually using an ID size other than 6 octets?
>Would it be correct to say that as a practical matter the
>ID is fixed at 6 octets?

I believe that is the case, unless someone can prove me wrong.

         Mike

>   Or are alternate ID sizes commonly
>deployed in real networks?
>
>adTHANKSvance,
>dave h
>_______________________________________________
>Isis-wg mailing list  -  Isis-wg@external.juniper.net
>http://external.juniper.net/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 12 12:15:22 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18482
	for <isis-archive@odin.ietf.org>; Tue, 12 Jun 2001 12:15:21 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA35367;
	Tue, 12 Jun 2001 09:13:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA35355
	for <isis-wg@spider.juniper.net>; Tue, 12 Jun 2001 09:12:07 -0700 (PDT)
Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f5CGAkw05151
	for <isis-wg@juniper.net>; Tue, 12 Jun 2001 09:10:46 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (qmail 55928 invoked from network); 12 Jun 2001 16:11:26 -0000
Received: from unknown (HELO NEIL) ([216.27.158.30]) (envelope-sender <Larmer@CommSense.Net>)
          by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <isis-wg@juniper.net>; 12 Jun 2001 16:11:26 -0000
From: "Ken Larmer" <Larmer@commsense.net>
To: "Isis-Wg@Juniper. Net" <isis-wg@juniper.net>
Message-ID: <FFEPKFEJDGEONDOGKAHCAEKECBAA.Larmer@CommSense.Net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Subject: [Isis-wg] L2 LSP Area Address TLV
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 12 Jun 2001 12:12:04 -0400
Content-Transfer-Encoding: 8bit

Hi,

	I am in doubt about the use of the L2 LSP Area Address TLV?

ISO-10589-06n1704 states the following:

7.3.9 Generation of level 2 LSPs (non-pseudonode)

-	In the Area Addresses option — the set of partitionAreaAddresses for this
intermediate system as described in 7.2.10.3

7.2.10.3 Computation of partition area addresses

For systems which do not implement partition repair, the value of
partitionAreaAddresses is identical to the value computed for areaAddresses
as described in 7.2.11.

7.2.11 Computation of area addresses

A Level 1 or Level 2 Intermediate System shall compute the values of
areaAddresses (the set of area addresses for this Level 1 area), by forming
the union of the sets of manualAreaAddresses reported in the Area Addresses
field of all Level 1 LSPs with LSP number zero in the local Intermediate
system’s link state database.

NOTES

18 This includes all source systems, whether currently reachable or not. It
also includes the local Intermediate system’s own Level 1 LSP with LSP
number zero.

7.1.5 Manual area addresses

...Each level 1 IS distributes its manualAreaAddresses in its Level 1 LSP’s
Area Addresses field, thus allowing level 2 ISs to create a composite list
of all area addresses in use within a given area. Level 2 ISs in turn
advertise the composite list throughout the level 2 subdomain by including
it in their Level 2 LSP’s Area Addresses field, thus distributing
information on all the area addresses associated with the entire routeing
domain. ...

7.2.9.2 Setting the attached flag in level 2 intermediate systems

When executing the level 2 decision process for each supported metric, level
2 IS shall ascertain whether or not it can reach any destinations outside
its area using that metric.  The IS considers itself attached if either:

a)	it can reach at least one other area using the coresponding routeing
metric, or
b)	it has at least one enabled reachable address prefix with the
corresponding metric defined.

Otherwise the IS considers itself not attached.

END OF ISO-10589 REFERENCES:



	What I am seeing on a well known implementation of Int IS-IS is that when
an IS has no L1 adjacencies, the L2 LSP being generated does not contain the
Area Address TLV. The spec states that an LSP should be generated but not
transmitted unless it has an adjacency! So there should always be a L1 LSP
number = 0 for each IS with IS-type = L1 or L1/L2.

1. Is this the correct behavior or should the area address TLV always be
present in an L2 LSP?
2. What is the Area Address TLV used for when contained within a L2 LSP? I
can think of the following two purposes:
	a Calculation of NSAP based routes and subsequent forwarding of CLNS
packets.
	b. Determining if an IS is connected to another L2 area as stated above?

So, should each L2 LSP contain an Area Address TLV regardless of the L1
adjacencies it possesses. If not, I would think (as I have observed) this
would break the rules for determining when to set the Attached bit!

Cheers,
Ken Larmer

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 12 12:44:43 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19073
	for <isis-archive@odin.ietf.org>; Tue, 12 Jun 2001 12:44:42 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA35577;
	Tue, 12 Jun 2001 09:43:10 -0700 (PDT)
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA35565
	for <isis-wg@spider.juniper.net>; Tue, 12 Jun 2001 09:42:53 -0700 (PDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19)
	id <MY7D54CN>; Tue, 12 Jun 2001 12:42:12 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB359CDBC3@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'mike shand'" <mshand@cisco.com>, David Hudek <dhudek@ma.ultranet.com>
Cc: isis-wg@spider.juniper.net
Subject: RE: [Isis-wg] Other than 6 octet ID ?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 12 Jun 2001 12:42:11 -0400

I recall Radia saying at one point that the variable length system ID was a
bad idea.  I wonder if the new 10589 spec will change this to make it static
at 6 octets?

 -chris

> -----Original Message-----
> From: mike shand [mailto:mshand@cisco.com]
> Sent: Monday, June 11, 2001 8:50 AM
> To: David Hudek
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Other than 6 octet ID ?
> 
> 
> At 20:00 10/06/2001 -0700, David Hudek wrote:
> >Hi all,
> >
> >As I understand it, the ISIS specification allows the ID field
> >of a NET to vary from between 1 to 8 octets, with the constraint
> >that everyone within a routing domain must use the same ID size.
> >
> >Is anyone anywhere actually using an ID size other than 6 octets?
> >Would it be correct to say that as a practical matter the
> >ID is fixed at 6 octets?
> 
> I believe that is the case, unless someone can prove me wrong.
> 
>          Mike
> 
> >   Or are alternate ID sizes commonly
> >deployed in real networks?
> >
> >adTHANKSvance,
> >dave h
> >_______________________________________________
> >Isis-wg mailing list  -  Isis-wg@external.juniper.net
> >http://external.juniper.net/mailman/listinfo/isis-wg
> 
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 12 13:02:43 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19579
	for <isis-archive@odin.ietf.org>; Tue, 12 Jun 2001 13:02:42 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA35717;
	Tue, 12 Jun 2001 10:01:10 -0700 (PDT)
Received: from cisco.com (jaws.cisco.com [198.135.0.150])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA35705
	for <isis-wg@spider.juniper.net>; Tue, 12 Jun 2001 10:00:25 -0700 (PDT)
Received: from mshand-w2k.cisco.com ([161.44.134.15])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA23505;
	Tue, 12 Jun 2001 17:59:08 +0100 (BST)
Message-Id: <4.3.2.7.2.20010612175635.03448340@jaws.cisco.com>
X-Sender: mshand@jaws.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Martin, Christian" <cmartin@gnilink.net>
From: mike shand <mshand@cisco.com>
Subject: RE: [Isis-wg] Other than 6 octet ID ?
Cc: David Hudek <dhudek@ma.ultranet.com>, isis-wg@spider.juniper.net
In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDBC3@entmail.gnilink.com
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 12 Jun 2001 17:59:45 +0100

At 12:42 12/06/2001 -0400, Martin, Christian wrote:
>I recall Radia saying at one point that the variable length system ID was a
>bad idea.  I wonder if the new 10589 spec will change this to make it static
>at 6 octets?

Of course it was a bad idea, but at the time there were those on the ISO 
committee who wanted it. There were actually two camps. Those who wanted a 
shorter ID (3 octets as I recall), and those who wanted a longer (8 
octets). The only way to get the standards to progress was to accommodate 
them in such a way that it didn't change the normal 6 octet usage.

However, I'd be very surprised in V2 could reverse this. It really doesn't 
matter provided that nobody implements it.

         Mike



>  -chris
>
> > -----Original Message-----
> > From: mike shand [mailto:mshand@cisco.com]
> > Sent: Monday, June 11, 2001 8:50 AM
> > To: David Hudek
> > Cc: isis-wg@spider.juniper.net
> > Subject: Re: [Isis-wg] Other than 6 octet ID ?
> >
> >
> > At 20:00 10/06/2001 -0700, David Hudek wrote:
> > >Hi all,
> > >
> > >As I understand it, the ISIS specification allows the ID field
> > >of a NET to vary from between 1 to 8 octets, with the constraint
> > >that everyone within a routing domain must use the same ID size.
> > >
> > >Is anyone anywhere actually using an ID size other than 6 octets?
> > >Would it be correct to say that as a practical matter the
> > >ID is fixed at 6 octets?
> >
> > I believe that is the case, unless someone can prove me wrong.
> >
> >          Mike
> >
> > >   Or are alternate ID sizes commonly
> > >deployed in real networks?
> > >
> > >adTHANKSvance,
> > >dave h
> > >_______________________________________________
> > >Isis-wg mailing list  -  Isis-wg@external.juniper.net
> > >http://external.juniper.net/mailman/listinfo/isis-wg
> >
> > _______________________________________________
> > Isis-wg mailing list  -  Isis-wg@external.juniper.net
> > http://external.juniper.net/mailman/listinfo/isis-wg
> >

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 12 13:12:11 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19834
	for <isis-archive@odin.ietf.org>; Tue, 12 Jun 2001 13:12:09 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA35805;
	Tue, 12 Jun 2001 10:10:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA35790
	for <isis-wg@spider.juniper.net>; Tue, 12 Jun 2001 10:09:37 -0700 (PDT)
Received: from cisco.com (jaws.cisco.com [198.135.0.150])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5CH8Fw08720
	for <isis-wg@juniper.net>; Tue, 12 Jun 2001 10:08:16 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mshand-w2k.cisco.com ([161.44.134.15])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA24262;
	Tue, 12 Jun 2001 18:08:41 +0100 (BST)
Message-Id: <4.3.2.7.2.20010612180449.033ae008@jaws.cisco.com>
X-Sender: mshand@jaws.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Ken Larmer" <Larmer@commsense.net>
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] L2 LSP Area Address TLV
Cc: "Isis-Wg@Juniper. Net" <isis-wg@juniper.net>
In-Reply-To: <FFEPKFEJDGEONDOGKAHCAEKECBAA.Larmer@CommSense.Net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id KAA35791
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 12 Jun 2001 18:09:15 +0100
Content-Transfer-Encoding: 8bit

Ken,
         While what you describe is the "correct" behaviour, there are some 
advantages to not advertising the area addresses of an isolated L1 router, 
since this give some rudimentary protection against area partitioning. The 
thought is that there is probably some other larger portion of the L1 area, 
and not advertising the area address for this stub, prevents traffic for 
the area being erroneously directed to this sub-functional router.

Of course if this really is the ONLY router in the L1 area, then you might 
actually
  want the traffic.

I think most well known IS-IS implementations probably have a way to turn 
off this feature if required.

         Mike


At 12:12 12/06/2001 -0400, Ken Larmer wrote:
>Hi,
>
>         I am in doubt about the use of the L2 LSP Area Address TLV?
>
>ISO-10589-06n1704 states the following:
>
>7.3.9 Generation of level 2 LSPs (non-pseudonode)
>
>-       In the Area Addresses option — the set of partitionAreaAddresses 
>for this
>intermediate system as described in 7.2.10.3
>
>7.2.10.3 Computation of partition area addresses
>
>For systems which do not implement partition repair, the value of
>partitionAreaAddresses is identical to the value computed for areaAddresses
>as described in 7.2.11.
>
>7.2.11 Computation of area addresses
>
>A Level 1 or Level 2 Intermediate System shall compute the values of
>areaAddresses (the set of area addresses for this Level 1 area), by forming
>the union of the sets of manualAreaAddresses reported in the Area Addresses
>field of all Level 1 LSPs with LSP number zero in the local Intermediate
>system’s link state database.
>
>NOTES
>
>18 This includes all source systems, whether currently reachable or not. It
>also includes the local Intermediate system’s own Level 1 LSP with LSP
>number zero.
>
>7.1.5 Manual area addresses
>
>...Each level 1 IS distributes its manualAreaAddresses in its Level 1 LSP’s
>Area Addresses field, thus allowing level 2 ISs to create a composite list
>of all area addresses in use within a given area. Level 2 ISs in turn
>advertise the composite list throughout the level 2 subdomain by including
>it in their Level 2 LSP’s Area Addresses field, thus distributing
>information on all the area addresses associated with the entire routeing
>domain. ...
>
>7.2.9.2 Setting the attached flag in level 2 intermediate systems
>
>When executing the level 2 decision process for each supported metric, level
>2 IS shall ascertain whether or not it can reach any destinations outside
>its area using that metric.  The IS considers itself attached if either:
>
>a)      it can reach at least one other area using the coresponding routeing
>metric, or
>b)      it has at least one enabled reachable address prefix with the
>corresponding metric defined.
>
>Otherwise the IS considers itself not attached.
>
>END OF ISO-10589 REFERENCES:
>
>
>
>         What I am seeing on a well known implementation of Int IS-IS is 
> that when
>an IS has no L1 adjacencies, the L2 LSP being generated does not contain the
>Area Address TLV. The spec states that an LSP should be generated but not
>transmitted unless it has an adjacency! So there should always be a L1 LSP
>number = 0 for each IS with IS-type = L1 or L1/L2.
>
>1. Is this the correct behavior or should the area address TLV always be
>present in an L2 LSP?
>2. What is the Area Address TLV used for when contained within a L2 LSP? I
>can think of the following two purposes:
>         a Calculation of NSAP based routes and subsequent forwarding of CLNS
>packets.
>         b. Determining if an IS is connected to another L2 area as stated 
> above?
>
>So, should each L2 LSP contain an Area Address TLV regardless of the L1
>adjacencies it possesses. If not, I would think (as I have observed) this
>would break the rules for determining when to set the Attached bit!
>
>Cheers,
>Ken Larmer
>
>_______________________________________________
>Isis-wg mailing list  -  Isis-wg@external.juniper.net
>http://external.juniper.net/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 12 14:35:21 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22017
	for <isis-archive@odin.ietf.org>; Tue, 12 Jun 2001 14:35:21 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA36208;
	Tue, 12 Jun 2001 11:28:09 -0700 (PDT)
Received: from cactus.cisco.com (cactus.cisco.com [161.44.19.100])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA36196
	for <isis-wg@spider.juniper.net>; Tue, 12 Jun 2001 11:27:45 -0700 (PDT)
Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-134-131.cisco.com [64.101.134.131])
	by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA12941;
	Tue, 12 Jun 2001 11:26:27 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010612130429.02163120@cactus.cisco.com>
X-Sender: mbartell@cactus.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Martin, Christian" <cmartin@gnilink.net>
From: Micah Bartell <mbartell@cisco.com>
Subject: RE: [Isis-wg] Other than 6 octet ID ?
Cc: "'mike shand'" <mshand@cisco.com>, David Hudek <dhudek@ma.ultranet.com>,
        isis-wg@spider.juniper.net
In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDBC3@entmail.gnilink.com
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 12 Jun 2001 13:26:24 -0500

Christian,

Section 7.1.3.2 will read:

ID     System identifier  a variable length field from 1 to 8 octets 
(inclusive). Each routeing domain employing this protocol shall select a 
single size for the ID field and all Intermediate systems in the routeing 
domain shall use this length for the system IDs of all systems in the 
routeing domain.

The set of ID lengths supported by an implementation is an implementation 
choice, provided that at least one value in the permitted range can be 
accepted. The routeing domain administrator must ensure that all ISs 
included in a routeing domain are able to use the ID length chosen for that 
domain.

As you can see, we are still allowing variable length, but it is 
implementation dependent on what size you support.  It just so happens that 
6 is what everyone supports.  Variable length systemID's are definitely of 
questionable value, but since we have not had an issue with it, it is 
easier to let it just remain.

/mpb

At 12:42 06/12/2001 -0400, Martin, Christian wrote:
>I recall Radia saying at one point that the variable length system ID was a
>bad idea.  I wonder if the new 10589 spec will change this to make it static
>at 6 octets?
>
>  -chris
>
> > -----Original Message-----
> > From: mike shand [mailto:mshand@cisco.com]
> > Sent: Monday, June 11, 2001 8:50 AM
> > To: David Hudek
> > Cc: isis-wg@spider.juniper.net
> > Subject: Re: [Isis-wg] Other than 6 octet ID ?
> >
> >
> > At 20:00 10/06/2001 -0700, David Hudek wrote:
> > >Hi all,
> > >
> > >As I understand it, the ISIS specification allows the ID field
> > >of a NET to vary from between 1 to 8 octets, with the constraint
> > >that everyone within a routing domain must use the same ID size.
> > >
> > >Is anyone anywhere actually using an ID size other than 6 octets?
> > >Would it be correct to say that as a practical matter the
> > >ID is fixed at 6 octets?
> >
> > I believe that is the case, unless someone can prove me wrong.
> >
> >          Mike
> >
> > >   Or are alternate ID sizes commonly
> > >deployed in real networks?
> > >
> > >adTHANKSvance,
> > >dave h
> > >_______________________________________________
> > >Isis-wg mailing list  -  Isis-wg@external.juniper.net
> > >http://external.juniper.net/mailman/listinfo/isis-wg
> >
> > _______________________________________________
> > Isis-wg mailing list  -  Isis-wg@external.juniper.net
> > http://external.juniper.net/mailman/listinfo/isis-wg
> >
>_______________________________________________
>Isis-wg mailing list  -  Isis-wg@external.juniper.net
>http://external.juniper.net/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 13 05:45:57 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17880
	for <isis-archive@odin.ietf.org>; Wed, 13 Jun 2001 05:45:56 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA39841;
	Wed, 13 Jun 2001 02:43:10 -0700 (PDT)
Received: from mailweb29.rediffmail.com ([203.199.83.149])
	by external.juniper.net (8.9.3/8.9.3) with SMTP id CAA39829
	for <isis-wg@spider.juniper.net>; Wed, 13 Jun 2001 02:42:42 -0700 (PDT)
Received: (qmail 8145 invoked by uid 510); 13 Jun 2001 09:44:55 -0000
Message-ID: <20010613094455.8144.qmail@mailweb29.rediffmail.com>
Received: from unknown (61.135.52.237) by rediffmail.com via HTTP; 13 Jun 2001 09:44:55 -0000
MIME-Version: 1.0
To: "isis-wg@spider.juniper.net" <isis-wg@spider.juniper.net>
From: "Purushothaman  NandaKumaran" <purush_isis@rediffmail.com>
Content-ID: <Wed_Jun_13_15_14_55_IST_2001_0@mailweb29.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [Isis-wg] External Metrics
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: 13 Jun 2001 09:44:55 -0000
Content-Transfer-Encoding: 7bit

Hi All,

This doubt is regarding external reachability TLV's information going in the LSPS with the external metric type. 

In what situation a router will originate this kind of TLVs?. (If it is based on configuration please tell me when the administrator wants to send such routes as external metrics)

Is it anyway related to the Type 1 and Type 2 external metrics in OSPF context?. That is the route is in another autonomous system and the metric to the destination is not correctly predictable.

Thanks in Advance,
with best regards,
Purush

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com




_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 13 20:24:53 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03843
	for <isis-archive@odin.ietf.org>; Wed, 13 Jun 2001 20:24:50 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA43413;
	Wed, 13 Jun 2001 17:22:09 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA30053
	for <isis-wg@spider.juniper.net>; Mon, 11 Jun 2001 10:30:40 -0700 (PDT)
Received: from bcn.East.Sun.COM ([129.148.75.4])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23876
	for <isis-wg@spider.juniper.net>; Mon, 11 Jun 2001 10:30:04 -0700 (PDT)
Received: from elm (elm [129.148.75.61])
	by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA06541
	for <isis-wg@spider.juniper.net>; Mon, 11 Jun 2001 13:29:58 -0400 (EDT)
Message-Id: <200106111729.NAA06541@bcn.East.Sun.COM>
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Subject: Re: [Isis-wg] Other than 6 octet ID ?
To: isis-wg@spider.juniper.net
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: nHBUNN6lbnV33TQfxUZ13g==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Mon, 11 Jun 2001 13:29:58 -0400 (EDT)


	At 20:00 10/06/2001 -0700, David Hudek wrote:
	>Hi all,
	>
	>As I understand it, the ISIS specification allows the ID field
	>of a NET to vary from between 1 to 8 octets, with the constraint
	>that everyone within a routing domain must use the same ID size.
	>
	>Is anyone anywhere actually using an ID size other than 6 octets?
	>Would it be correct to say that as a practical matter the
	>ID is fixed at 6 octets?
	
That is a frill that I was unhappy about ISO adding. It's not clear why
it would be useful, and it certainly won't work if nodes within
a domain are configured for different ID sizes. It would be nice
if it could be set to be constant 6, and remove the field in the LSP
that states what you think the ID size is, and remove all
mention of it in the spec
like the size of things being IDlength+2.

I'd also advocate for doing the same for number of area addresses,
and fix that at 3.

Radia

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 13 20:28:39 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03856
	for <isis-archive@odin.ietf.org>; Wed, 13 Jun 2001 20:28:37 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA43444;
	Wed, 13 Jun 2001 17:26:50 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA38452
	for <isis-wg@spider.juniper.net>; Tue, 12 Jun 2001 21:19:57 -0700 (PDT)
Received: from mailweb14.rediffmail.com ([203.199.83.26])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f5D4ITw33076
	for <isis-wg@juniper.net>; Tue, 12 Jun 2001 21:18:30 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (qmail 32261 invoked by uid 510); 13 Jun 2001 04:20:34 -0000
Message-ID: <20010613042034.32260.qmail@mailweb14.rediffmail.com>
Received: from unknown (61.135.52.237) by rediffmail.com via HTTP; 13 Jun 2001 04:20:34 -0000
MIME-Version: 1.0
To: "isis-wg@juniper.net" <isis-wg@juniper.net>
From: "Lakshminarayanan  R" <narayananl@rediffmail.com>
Content-ID: <Wed_Jun_13_09_50_34_IST_2001_0@mailweb14.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [Isis-wg] IP Unnumbered !
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: 13 Jun 2001 04:20:34 -0000
Content-Transfer-Encoding: 7bit

hi,

1) Is there any draft/rfc/materials about IP unnumbered implementation for Is-Is ?

2) Can we have one numbered side and leave the otherside un-numbered in Is-Is ? 

3) Why an Un-numbered interface cannot be pinged directly?

4) Can we associate an alternate IP address for an un-nmbered interface if suppose the primary address goes down?

5) Can Is-Is supports multiple un-numbered interfaces associated with a single broadcast IP address ?

6) How the Is-Is decision module distinguishes the route updation of a default route with an unnumbered interface whose associated broadcast address gone down(i.e.: it's become 0.0.0.0)?

I believe some basic questions may not be relevant to Is-Is working group! but if i get answered for all, it'll be very helpful for my understanding !!


Thanks in advance,
lakshminarayan r 



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com




_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 13 20:31:40 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03891
	for <isis-archive@odin.ietf.org>; Wed, 13 Jun 2001 20:31:38 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA43476;
	Wed, 13 Jun 2001 17:29:52 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA39942
	for <isis-wg@spider.juniper.net>; Wed, 13 Jun 2001 02:55:58 -0700 (PDT)
Received: from mailweb20.rediffmail.com ([203.199.83.144])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f5D9sTw39588
	for <isis-wg@juniper.net>; Wed, 13 Jun 2001 02:54:29 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (qmail 26955 invoked by uid 510); 13 Jun 2001 09:58:39 -0000
Message-ID: <20010613095839.26953.qmail@mailweb20.rediffmail.com>
Received: from unknown (61.135.52.237) by rediffmail.com via HTTP; 13 Jun 2001 09:58:39 -0000
MIME-Version: 1.0
To: "isis-wg@juniper.net" <isis-wg@juniper.net>
From: "Lakshminarayanan  R" <narayananl@rediffmail.com>
Content-ID: <Wed_Jun_13_15_28_39_IST_2001_0@mailweb20.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [Isis-wg] IP Unnumbered !
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: 13 Jun 2001 09:58:39 -0000
Content-Transfer-Encoding: 7bit



hi,

1) Is there any draft/rfc/materials about IP unnumbered implementation for Is-Is ?

2) Can we have one numbered side and leave the otherside un-numbered in Is-Is ? 

3) Why an Un-numbered interface cannot be pinged directly?

4) Can we associate an alternate IP address for an un-nmbered interface if suppose the primary address goes down?

5) Can Is-Is supports multiple un-numbered interfaces associated with a single broadcast IP address ?

6) How the Is-Is decision module distinguishes the route updation of a default route with an unnumbered interface whose associated broadcast address gone down(i.e.: it's become 0.0.0.0)?

I believe some basic questions may not be relevant to Is-Is working group! but if i get answered for all, it'll be very helpful for my understanding !!


Thanks in advance,
lakshminarayan r 



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com




_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 15 20:44:40 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02311
	for <isis-archive@odin.ietf.org>; Fri, 15 Jun 2001 20:44:39 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA55038;
	Fri, 15 Jun 2001 17:43:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA55026
	for <isis-wg@spider.juniper.net>; Fri, 15 Jun 2001 17:42:05 -0700 (PDT)
Received: from alpha-tli.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5G0e9w59228
	for <isis-wg@juniper.net>; Fri, 15 Jun 2001 17:40:09 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by alpha-tli.procket.com (8.9.3/8.9.3) id RAA31076;
	Fri, 15 Jun 2001 17:41:00 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15146.43803.917819.341025@alpha-tli.procket.com>
To: isis-wg@juniper.net
X-Mailer: VM 6.75 under Emacs 20.5.1
Subject: [Isis-wg] Jumbo frames...
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 15 Jun 2001 17:40:59 -0700 (PDT)
Content-Transfer-Encoding: 7bit


Folks,

You may recall that a LONG time ago we sent
draft-kaplan-isis-ext-eth-02.txt up to the IESG for submission as an
Informational RFC.

Well, it got stuck in the IESG.  They felt that it was necessary to consult
with the IEEE.  It has since come back to us, with the comments from the
IEEE.  The authors have attached those comments and their responses to
those comments as appendicies to the draft.

We would like to again move this revised copy (attached) forward.  We would
like to propose:

a) That this now become a WG draft. [We didn't bother before.]
b) That the IESG publish this as an Informational RFC.

In the interests of rapid closure, please comment by 17:01 PDT, 6/22.  A
copy will also be submitted to the Secretariat for publication as an ID.

Tony


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


Network Working Group					Jed Kaplan
Internet Draft						P.J. Singh
Expiration Date: November 1999				Allegro Networks, Inc.
 
							Mike O'Dell

							John Hayes
							Archduke Design, Inc.

							Ted Schroeder
							Alteon WebSystems, Inc.

							Daemon Morrell
							Juniper Networks, Inc.

							Jennifer Hsu
	
						
	          Extended Ethernet Frame Size Support 

		    draft-ietf-isis-ext-eth-00.txt


1. Status of this Memo

	This document is an Internet-Draft and is in full conformance with 
	all provisions of Section 10 of RFC2026.

	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.

	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other
        documents at any time. It is inappropriate to use Internet-Drafts
        as reference material or to cite them other than as "work in
        progress."

	The list of current Internet-Drafts can be accessed at 
	http://www.ietf.org/ietf/lid-abstracts.txt

	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html


2. Abstract

	This document presents an extension to current Ethernet Frame 
	specifications for hardware and frame format to support payloads 
        greater than 1500 Bytes for Type interpretation and Length 
	interpretation frames. This is useful for Gigabit Ethernet
        technology, providing a means to carry large MTU packets without
        fragmentation over a high-speed broadcast network.

3. Overview
	
	There are two fundamental frame types defined for Ethernet:
	Type interpretation [IEEE-ISO] [RFC894] and Length interpretation 
	[IEEE-ISO]. Length interpretation headers may be followed by a 
	Logical Link Control header, 802.2 [IEEE802.2]. Both types of 
	encapsulations can co-exist on the same media at the same time. 
	Encodings for Type interpretation and Length interpretation
	frames evolved such that, as long as payloads were less than 1500
	bytes, Type interpretation frames could always be distinguished from
	Length interpretation frames.

	However, when the payload is greater than 1500 bytes frames may 
	not be uniquely distinguishable as conforming to Type
        interpretation or Length interpretation formats. This document
        extends the Ethernet frame format to allow Type interpretation or
        Length interpretation frame payloads larger than 1500 bytes to be
        uniquely distinguished.

4. Ethernet Frame Formats

	A. Type interpretation
		
		+----+----+------+------+-----+
		| DA | SA | Type | Data | FCS |
		+----+----+------+------+-----+
	  
		DA      Destination MAC Address (6 bytes)
		SA      Source MAC Address      (6 bytes)
		Type    Protocol Type           (2 bytes)
		Data    Protocol Data           (46 - 1500 bytes)
		FCS     Frame Checksum          (4 bytes)

	B. Length interpretation and derivatives

		+----+----+------+------+-----+
		| DA | SA | Len  | Data | FCS |
		+----+----+------+------+-----+

		DA      Destination MAC Address (6 bytes)
		SA      Source MAC Address      (6 bytes)
		Len     Length of Data field    (2 bytes)
		Data    Protocol Data           (46 - 1500 bytes)
		FCS     Frame Checksum          (4 bytes)
	  
	The derivatives include LLC (802.2) and SNAP which prefix the
	data field with an LLC header.  In these instances the Len field
	then corresponds to the combined size of both the data portion
	of the frame and the LLC header.
	
	On reception, the two formats are differentiated based on the
	magnitude of the Type/Length field, as follows:

	> 1536 bytes:   value corresponds to a type field.  The frame is an
			Ethernet II frame, with type values starting at 1536

			(600 hex).

	<= maxValidFrame bytes:  value corresponds to a length field.  The 
			frame is an IEEE 802.3 format (or derivative) with a

			maximum data length of 1500 bytes.

5. Problem with Large Length interpretation Frames in the presence of Type 
   Interpretation Frames

	Some protocols commonly used in the Internet have no reserved
        Ethertype.  An example is the set of ISO Network layer protocols,
        of which ISIS is a member. Such protocols are only defined to use
        the IEEE 802.3/802.2 encoding, and so their packets are limited in
        length to 1500 bytes. 

 	Type Interpretation frames have no length field. Protocols
        encapsulated in Type interpretation frames, such as IP, are not
        limited in length to 1500 bytes by framing.

6. Proposed Ethernet Frame Extension

	Large Length interpretation and Type interpretation frames can be 
	supported by the following:
	
	+  Define an Ethertype for 802.3, 0x8870, and encode large frames
	   (where the data field is greater than 1500 bytes), exclusive of 
	   the Destination MAC address, Source MAC address, and Data length 
	   fields, within Type interpretation frames.

	   Large 802.3/802.2 frames would have the following fields:
 
		+----+----+------+------+------+------+------+-----+
		| DA | SA | Type | DSAP | SSAP | Ctrl | Data | FCS |
		+----+----+------+------+------+------+------+-----+
		                  === 802.2 Header ===

		DA      Destination MAC Address                (6 bytes)
		SA      Source MAC Address                     (6 bytes)
		Type    0x8870 (Ethertype)                     (2 bytes)
		DSAP    802.2 Destination Service Access Point (1 byte)
		SSAP    802.2 Source Service Access Point      (1 byte)
		Ctrl    802.2 Control Field                    (1 byte)
		Data    Protocol Data                          (46 bytes)
		FCS     Frame Checksum                         (4 bytes)
	  
	+  Allow Type interpretation frames to have payloads greater than 
           1500 bytes.

	There is no loss of information from 802.3/802.2 frames. Although 
        the 802.3 length field is missing, the frame length is known by 
        virtue of the frame being accepted by the network interface.

	In this manner, all Type interpretation frames, including large Length 
	interpretation frames, can be longer than 1500 bytes, yet are
        uniquely identified.


7. References

[IEEE-ISO] IEEE Std. 802.3 [2000 Edition], ISO/IEC 8802-3:2000.

[RFC894] IETF RFC 894

[IEEE802] IEEE Std 802

[IEEE802.3Z] IEEE Std 802.3z

[802.3X] IEEE Std. 802.3X [March 20, 1997], sec 4.2.7.1.

[EXT.FRAME] "Use of Extended Frame Sizes in Ethernet Networks", draft 2.1, 
            Alteon Networks, Inc.


8. Author's Addresses

Jed Kaplan
Allegro Networks, Inc.
12700 Failr Lakes Circle
Suite 100
Fairfax, Va 22033
email: jkaplan@allegronetworks.com

P.J. Singh
Allegro Networks, Inc.
6399 San Ignacio Blvd.
San Jose, Ca. 95119
408-281-5500
email: pjsingh@allegronetworks.com

Mike O'Dell
email: mo@ccr.net

John Hayes
Archduke Design, Inc.
24700 Skyland Road
Los Gatos, CA 95033
(408) 691-6891
email: hayes@archdukedesign.com

Ted Schroeder
email: ted@alteon.com

Daemon Morrell
Juniper Networks, Inc.
12343-D Sunrise Valley Drive
Reston, VA 20191
email: dmorrell@juniper.net

Jennifer Hsu
jhsu@mur.com


9. Appendix 1. Following is the response from the IEEE to 
   draft-kaplan-isis-ext-eth-02.txt. 

	From:   Geoff Thompson, Chair, IEEE 802.3
	To:     Scott O. Bradner, IETF
	Re:     802.3 Position on Extended Ethernet Frame Size Support

	Scott-

	This is in response to your query for a position regarding the
	publication of Extended Ethernet Frame Size Support -
	draft-kaplan-isis-ext-eth-02.txt - as an informational RFC. This
	response was approved in concept and draft by 802.3 during its
	closing plenary at Hilton Head on March 15. The final form was
	drafted by myself and reviewed by an ad hoc that was formed during
	our closing plenary. It should be considered the position of the
	802.3 Working Group.

	The response is composed of two parts, specific comments on the
	draft and general comments on the use of jumbo frames in Ethernet
	networks, however, virtually all traffic uses the type/length field
	as a type field. It seems unlikely that the implementations using
	the length format would take advantage of longer
	packets. Therefore, the draft conveys a very limited value.

	Specific comments on: Extended Ethernet Frame Size Support -
	draft-kaplan-isis-ext-eth-02.txt

	The draft makes no mention that extended frames are not likely to be
	successfully handled by Ethernet equipment unless the network is 
	composed entirely of equipment that is specifically designed, beyond
	the specifications of the Ethernet Standard, to relay extended size 
	frames.

	In section 2, Abstract, the document asserts that it presents an
	extension to the "current Ethernet Frame Standards to support
	payloads greater than 1500 bytes..." Neither the original Ethernet
	specification (it was not a "Standard") nor IEEE Std. 802.3 is a
	"frame standard". They are, rather, complete specifications for
	hardware and frame format with the expectation that parameters from
	one portion of the standard can be taken as a given in other
	portions of the Standard. Moreover, this draft is not an
	"extension" to those documents but rather a proposal to violate
	specific provisions of those documents.

	In section 3, the draft refers to "Ethernet II [ETH] and points to
	the reference [ETH] The reference, as cited, is incorrect or
	incomplete.

	Ethernet II would seem to point to Ethernet Version 2.0. That would 
	specifically not be "version 1.0...September 1980". The citation in 
	fact points to 2 different documents and fails to note that the 
	November 1982 edition is in fact Version 2.0. Further, both of these

	are obsolete references and have been superceded by IEEE Std. 802.3 
	and ISO/IEC 8802-3. The current version of these Standards is IEEE 
	Std. 802.3 [2000 Edition] and ISO/IEC 8802-3 : 2000.

	The details of section 4 are badly out of date. IEEE Std.  802.3
	has included both Type and Length encoded packets ever since the
	adoption of IEEE Std. 802.3x on March 20, 1997. The current text of
	the 802.3 text covering this reads:
	================================================================
	3.2.6 Length/Type Field
	This two-octet field takes one of two meanings,depending on  its 
	numeric value. For numerical evaluation, the first octet is the most
	significant octet of this field.
	  a)If the value of this field is less than or equal to the value of
	    maxValidFrame (as specified in 4.2.7.1), then the Length/Type
	    field indicates the number of MAC client data octets contained
	    in the subsequent data field of the frame (Length interpretation).
	  b)If the value of this field is greater than or equal to 1536 
	    decimal (equal to 0600 hexadecimal),then the Length/Type field 
          indicates the nature of the MAC client protocol (Type 
          interpretation). The Length and Type interpretations of this 
          field are mutually exclusive.
	================================================================
  	Please note that any value over "the value of maxValidFrame" is NOT
	a valid value for encoding length. Additionally, the values between
	maxValidFrame and "1536 decimal" are undefined in the Ethernet
	standard.  The behavior of equipment at these values is not
	specified and can not be depended on. The draft implies that these
	values are valid type fields. This is not true. These values are
	not valid for either Type or Length.

	Section 4 Re: "...are not limited in length to 1500 bytes by
	framing." While this seems to be true, it is not necessarily true
	for a number of sometimes subtle reasons, some of which are noted
	in the "General" section below.

	Section 5: Regarding the statement "Although the 802.3 length field
	is missing, the frame length is missing, the frame length is known
	by virtue of the frame being accepted by the network interface."
	This statement is not correct. Many Ethernet interfaces,
	particularly those of relay equipment, accept frames without regard
	for packet type or content. There is no reasonable expectation that
	standards based Ethernet/802.3 equipment will reject the proposed
	frames. They may very well accept the frame and corrupt it before
	passing it on. This corruption may consist of truncation or
	alteration of the data within the packet.

	General comments on the use of jumbo frames in Ethernet networks:

	Consideration #1: The expectation of no more than 15-1600 bytes
	between frames and an interpacket gap before the next frame is
	deeply ingrained throughout the design and implementation of
	standardized Ethernet/802.3 hardware. This shows up in buffer
	allocation schemes, clock skew and tolerance compensation and fifo
	design.

	Consideration #2: For some Ethernet/802.3 hardware (repeaters are
	one specific example) it is not possible to design compliant
	equipment which meets all of the requirements and will still pass
	extra long frames.  Further, since clock frequency may vary with
	time and temperature, equipment may successfully pass long frames
	at times and corrupt them at other times.  Therefore, attempts to
	verify the ability to send long frames over a path may produce
	inaccurate results.

	Consideration #3: The error checking mechanism embodied in the 4
	byte checksum has not been well characterized at greater frame
	lengths, but is known to degrade. Therefore the data reliability of
	transfers in long frame transfers will have a greater rate of
	undetected frame errors.

	Consideration #4: The length of frames proposed by this draft can
	not be assured to pass through standards conformant hardware. The
	huge value of Ethernet/802.3 systems in the data networking
	universe is their standardization and the resulting assurance that
	systems will all interoperate. No such assurance can be provided
	for oversize frames with both the current broadly accepted standard
	and the large installed base ofstandards based equipment.

	In summary with regard to greatly longer frames for Ethernet, much
	of the gear produced today would be intolerant of greatly longer
	frames.  There is no way proposed to distinguish between frame
	types in the network as they arrive from the media. Bridges might
	and repeaters would drop or truncate frames (and cause errors doing
	so) right and left for uncharacterized reasons. It would be a
	mess. What might seem okay for small carefully characterized
	networks would be enormously difficult or impossible to do across
	the Standard.

	The choice of frame size for Ethernet packets is really the domain
	of 802.3 (CSMA/CD) and 802.1 (Bridging, VLANs). The only time the
	frame size has been modified over the history of the Standard was
	in order to increase maximum length by four bytes in order to
	accommodate VLANs, 802.1 initiated this work and 802.3 also
	modified the Ethernet standard to include these few extra
	bytes. The people with the experience dealing with this sort of
	thing attend IEEE 802.  It's easy to define a new ethertype, but
	it's not too easy to figure out what happens when these
	non-standard frames are given to standardized transmission
	equipment e.g. bridges.  We would expect discussions of this type
	to take place in both 802.3 & 802.1.

	The giant frame issue has been mentioned several times over the
	years in 802.3, discussed in the back halls and considered each
	time we move to a higher speed. It has never had consensus support
	in that context.  It has never been brought forward as a separate
	proposal. Backward compatibility has always been more important
	than ease of performance improvement. The problem is that the
	change is very easy to do in the standard and hard to do in the
	world. It is just like changing the gauge on railroad tracks. All
	you have to do is change one line in the standard, never mind all
	of the rails you have to move.

	The Kaplan draft is just meant for carrying IS-IS routing protocol
	frames (the IS-IS working group is the intended sponsor of this
	draft).  We expect those vendors supporting the larger frame will
	support this will show up and support this proposal. Those vendors
	not supporting the larger frame as well as those protecting the
	installed base will not support this activity nor having this sort
	of item standardized outside IEEE 802.3.

	With best regards,

	Geoff Thompson, Chair, IEEE 802.3



10. Appendix 2. Comments from the draft's authors. 

	With respect to Consideration #2, paragraph 1:

	With the advent of full duplex ethernet and higher speed ethernet
	phys, transcievers have gone from transmitting when they have data
	ready send to transmitting constantly, sending IDLEs when they have
	nothing to send. Any clock drift due to time and temperature will
	affect the system without regard to the frame lengths being used.

	With respect to Consideration #3, paragraph 1:

	The error checking mechanism of ethernet (CRC-32) was characterized
	by R. Jain, "Error Characteristics of Fiber Distributed Data
	Interface (FDDI)," IEEE Transactions on Communications, Vol. 38,
	No. 8, August 1990,
	pp. 1244-1252. http://www.cis.ohio-state.edu/~jain/papers/xie1.htm

	FDDI and Ethernet use the same error checking mechanism; CRC-32.
	The probability of undetected errors remains constant for frame
	sizes between 3007 and 91639 bits (approximately 376 to 11455
	bytes).  Setting the maximum size of jumbo frames to 9018 bytes
	falls well within this range.  There is no increase in undetected
	errors when using jumbo frames and the existing CRC-32 as the error
	detection mechanism.

	With respect to Consideration #4, paragraph 1:

	This proposal provides a workable mechanism to identify and 
	handle jumbo frames through systems that do support jumbo frames.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 15 22:11:33 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03800
	for <isis-archive@odin.ietf.org>; Fri, 15 Jun 2001 22:11:32 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA55434;
	Fri, 15 Jun 2001 19:08:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA55275
	for <isis-wg@spider.juniper.net>; Fri, 15 Jun 2001 18:33:01 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5G1V5w60050
	for <isis-wg@juniper.net>; Fri, 15 Jun 2001 18:31:05 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id 2D0EC8266E; Fri, 15 Jun 2001 21:31:36 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010615212420.009d2730@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: Tony Li <tli@procket.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] Jumbo frames...
Cc: isis-wg@juniper.net
In-Reply-To: <15146.43803.917819.341025@alpha-tli.procket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 15 Jun 2001 21:27:53 -0400

At 20:40 15/06/01, Tony Li wrote:
>You may recall that a LONG time ago we sent
>draft-kaplan-isis-ext-eth-02.txt up to the IESG for submission as an
>Informational RFC.
>
>Well, it got stuck in the IESG.  They felt that it was necessary to consult
>with the IEEE.  It has since come back to us, with the comments from the
>IEEE.  The authors have attached those comments and their responses to
>those comments as appendicies to the draft.
>
>We would like to again move this revised copy (attached) forward.  We would
>like to propose:
>
>a) That this now become a WG draft. [We didn't bother before.]
>b) That the IESG publish this as an Informational RFC.
>
>In the interests of rapid closure, please comment by 17:01 PDT, 6/22.  A
>copy will also be submitted to the Secretariat for publication as an ID.

        With all respect, the draft is incomplete.  We ought to
specify a default IP MTU for Ethernet jumbograms.  This will
help those vendors who choose to implement jumbograms do so
in a way that maximises interoperability.

        I would propose 9180 bytes as the default IP MTU on grounds
that it is pretty widely implemented by Ethernet vendors and that
there is operational experience indicating that the 9K size is
particularly useful for servers.  Possibly relevant is the *rationale*
in RFC-1626, which spec'd the same MTU for ATM AAL5.  ATM itself,
of course, is not relevant here.

Ran
rja@inet.org

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 16 03:26:37 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22082
	for <isis-archive@odin.ietf.org>; Sat, 16 Jun 2001 03:26:36 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA56685;
	Sat, 16 Jun 2001 00:25:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA56670
	for <isis-wg@spider.juniper.net>; Sat, 16 Jun 2001 00:24:17 -0700 (PDT)
Received: from redcs1.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5G7MIw63970
	for <isis-wg@juniper.net>; Sat, 16 Jun 2001 00:22:18 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by redcs1.procket.com (8.9.3/8.9.3) id AAA12581;
	Sat, 16 Jun 2001 00:22:50 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15147.2378.397394.142911@redcs1.procket.com>
To: RJ Atkinson <rja@inet.org>
Cc: Tony Li <tli@Procket.com>, isis-wg@juniper.net
Subject: Re: [Isis-wg] Jumbo frames...
In-Reply-To: <5.1.0.14.2.20010615212420.009d2730@10.30.15.2>
References: <15146.43803.917819.341025@alpha-tli.procket.com>
	<5.1.0.14.2.20010615212420.009d2730@10.30.15.2>
X-Mailer: VM 6.75 under Emacs 20.5.1
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 16 Jun 2001 00:22:50 -0700 (PDT)
Content-Transfer-Encoding: 7bit


 |         With all respect, the draft is incomplete.  We ought to
 | specify a default IP MTU for Ethernet jumbograms.  This will
 | help those vendors who choose to implement jumbograms do so
 | in a way that maximises interoperability.
 | 
 |         I would propose 9180 bytes as the default IP MTU on grounds
 | that it is pretty widely implemented by Ethernet vendors and that
 | there is operational experience indicating that the 9K size is
 | particularly useful for servers.  Possibly relevant is the *rationale*
 | in RFC-1626, which spec'd the same MTU for ATM AAL5.  ATM itself,
 | of course, is not relevant here.


Ran is very much correct when he says that ATM is not relevant.  So is its
MTU.  Experience building networking equipment for a 9180 byte MTU says
that it is extremely painful and costly.  Given that the predominant media
for the forseeable future are POS and Ethernet (of various speeds), plus
the fact that there are an insignificant number of IP hosts running with an
MTU higher than that of FDDI, it seems more useful to use the POS/FDDI MTU
of 4470.

If, of course, folks want to specify a default MTU at all.

Tony

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 16 09:38:44 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24220
	for <isis-archive@odin.ietf.org>; Sat, 16 Jun 2001 09:38:44 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA60239;
	Sat, 16 Jun 2001 06:37:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA60227
	for <isis-wg@spider.juniper.net>; Sat, 16 Jun 2001 06:36:35 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5GDYYw68601
	for <isis-wg@juniper.net>; Sat, 16 Jun 2001 06:34:34 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.extremenetworks.com (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id BAB568266E
	for <isis-wg@juniper.net>; Sat, 16 Jun 2001 09:35:24 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010616091659.00ac9ec0@10.30.15.2>
X-Sender: rja@nowhere (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: isis-wg@juniper.net
From: Ran Atkinson <rja@extremenetworks.com>
Subject: Re: [Isis-wg] Jumbo frames...
In-Reply-To: <15147.2378.397394.142911@redcs1.procket.com>
References: <5.1.0.14.2.20010615212420.009d2730@10.30.15.2>
 <15146.43803.917819.341025@alpha-tli.procket.com>
 <5.1.0.14.2.20010615212420.009d2730@10.30.15.2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 16 Jun 2001 09:31:43 -0400

At 03:22 16/06/01, Tony Li wrote:
>Ran is very much correct when he says that ATM is not relevant.  So 
>is its MTU.  Experience building networking equipment for a 9180 byte 
>MTU says that it is extremely painful and costly.  Given that the 
>predominant media for the forseeable future are POS and Ethernet 
>(of various speeds), plus the fact that there are an insignificant 
>number of IP hosts running with an MTU higher than that of FDDI, 
>it seems more useful to use the POS/FDDI MTU of 4470.

        The FDDI MTU is equally irrelevant as ATM since it isn't
widely deployed anyplace (not even exchange points now a days).  
POS MTU is configurable in any event.

        Most Gigabit Ethernet products sold today **already** 
support the 9180 byte IP MTU.  In fact, it isn't hard to either
implement or support (at least for some of us).  The main exception 
is that some cisco Ethernet products support 9180 byte MTU, while 
others only support a 4470 byte MTU today (different product design 
teams within cisco apparently don't talk with each other).  PAIX, 
LINX, and several other exchange points have already deployed equipment
that supports the 9180 byte IP MTU over Ethernet.  Some operators
are using this today at those exchange points.

        So a majority of Gigabit Ethernet vendors disagree
with tli's assertion that such an MTU is too painful and costly
to implement.  Further, the trend is for Ethernet-based exchange 
points to support the 9180 byte IP MTU.  

        The *rationale* for the 9180 byte MTU, present in RFC-1626,
is in fact still relevant.  For while this happens by accident
to be a draft within the IS-IS WG, the scope of the document goes
very far beyond IS-IS or even the Routing Area.  In fact the 
reason IEEE got a bit upset was partly that a jumbogram won't work
properly on a pure CSMA/CD deployment of Ethernet and partly
that the draft describes a purely layer-2 feature outside the usual
scope of IETF.  Now, in practice, IEEE has its head in the sand
on this issue, vendors have deployed the 9K MTU already, and there
is value in documenting deployed practice so that interoperability
can more easily be ensured.

        In any event, tli's gripes about pain and cost aren't terribly 
relevant in an Informational RFC which is non-binding in the first 
place.  No one is required to pay any attention to an Informational
RFC.  It either is useful and gets deployed xor it isn't useful and
gets ignored.

Ran

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 16 09:54:52 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24260
	for <isis-archive@odin.ietf.org>; Sat, 16 Jun 2001 09:54:50 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA60355;
	Sat, 16 Jun 2001 06:54:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA60343
	for <isis-wg@spider.juniper.net>; Sat, 16 Jun 2001 06:53:55 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5GDpsw68676
	for <isis-wg@juniper.net>; Sat, 16 Jun 2001 06:51:54 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.extremenetworks.com (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id 9AC5A8266E
	for <isis-wg@juniper.net>; Sat, 16 Jun 2001 09:52:44 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
X-Sender: rja@nowhere (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: isis-wg@juniper.net
From: Ran Atkinson <rja@extremenetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [Isis-wg] More vendor data on IP/GigE MTU
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 16 Jun 2001 09:49:02 -0400


	A quick check reveals that GigE host adapters from Intel, 3COM,
and Broadcom all support a 9K MTU.  Further, widely used inexpensive
commodity chipsets, such as the Intel LXT1000 and Broadcom BCM-5701, 
are specifically designed to support the 9K IP/GigE MTU (confirmed
just now by reviewing those data sheets).

	WindowsNT, Windows2000, and WindowsXP all support the 9K MTU.
Many other server vendors also support the 9K MTU for IP/GigE.

	I'm unaware of (and unable to locate quickly) any 10/100 Ethernet
products that support anything other than the standard 1518 byte MTU.
Data on any specific 10/100 products that support an MTU larger than 
1518 (+ allowance for 802.1q VLAN tags && 802.1p precedence) would 
be interesting to me at least.

Cheers,

Ran
rja@inet.org


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 16 17:44:08 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26298
	for <isis-archive@odin.ietf.org>; Sat, 16 Jun 2001 17:44:07 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA62213;
	Sat, 16 Jun 2001 14:44:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA62201
	for <isis-wg@spider.juniper.net>; Sat, 16 Jun 2001 14:43:40 -0700 (PDT)
Received: from redcs1.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5GLfaw73023
	for <isis-wg@juniper.net>; Sat, 16 Jun 2001 14:41:36 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by redcs1.procket.com (8.9.3/8.9.3) id OAA10460;
	Sat, 16 Jun 2001 14:42:28 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15147.53956.476731.291265@redcs1.procket.com>
To: Ran Atkinson <rja@extremenetworks.com>
Cc: isis-wg@juniper.net
Subject: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
X-Mailer: VM 6.75 under Emacs 20.5.1
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 16 Jun 2001 14:42:28 -0700 (PDT)
Content-Transfer-Encoding: 7bit


Ran,

Apparently we're trying to solve different problems.  

I'm trying to eliminate the need to do high speed fragmentation in the
backbone of the Internet.  Having multiple MTU sizes is not a good thing
for anyone and it causes unnecessary inefficiencies for both the router and
the end host that has to do the reassembly.  

From that perspective, adding another MTU size to the Internet simply
increases the need for fragmentation.  Server sends 9180B packet to
router A.  Router A fragments to 4470B to get through a POS link.
Somewhere down the path, router B fragments down to 1500B to actually
deliver to the user over 10BaseT.  How did this help?

The rationale in RFC 1626 is flawed.  At the very least, modern NFS runs
over TCP, not UDP.  The rest of the RFC has no compelling rationale for a
larger MTU.  RFC 1626 does get one thing right, tho:

       Fragmentation of IP datagrams is known to be highly
       undesirable. [KM87] 

Do you no longer agree with this?

Tony
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 16 17:59:16 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26395
	for <isis-archive@odin.ietf.org>; Sat, 16 Jun 2001 17:59:15 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA62323;
	Sat, 16 Jun 2001 14:59:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA62311
	for <isis-wg@spider.juniper.net>; Sat, 16 Jun 2001 14:58:22 -0700 (PDT)
Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5GLuHw73137
	for <isis-wg@juniper.net>; Sat, 16 Jun 2001 14:56:17 -0700 (PDT)
X-JNPR-Received-From: outside
Received: by freesbee.wheel.dk (Postfix, from userid 1001)
	id 9666F5D79; Sat, 16 Jun 2001 23:57:09 +0200 (CEST)
From: Jesper Skriver <jesper@skriver.dk>
To: Tony Li <tli@Procket.com>
Cc: Ran Atkinson <rja@extremenetworks.com>, isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
Message-ID: <20010616235709.B71941@skriver.dk>
References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <15147.53956.476731.291265@redcs1.procket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15147.53956.476731.291265@redcs1.procket.com>; from tli@Procket.com on Sat, Jun 16, 2001 at 02:42:28PM -0700
X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5  5EB4 22AB F0EC F956 1C31
X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 16 Jun 2001 23:57:09 +0200

On Sat, Jun 16, 2001 at 02:42:28PM -0700, Tony Li wrote:
> 
> Ran,
> 
> Apparently we're trying to solve different problems.  
> 
> I'm trying to eliminate the need to do high speed fragmentation in the
> backbone of the Internet.  Having multiple MTU sizes is not a good thing
> for anyone and it causes unnecessary inefficiencies for both the router and
> the end host that has to do the reassembly.  
> 
> From that perspective, adding another MTU size to the Internet simply
> increases the need for fragmentation.  Server sends 9180B packet to
> router A.  Router A fragments to 4470B to get through a POS link.

pMTUd is what's used generally, so fragmentation by routers isn't
seen much in real life.

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:    Network manager   @ AS3292 (Tele Danmark DataNetworks)
Private: FreeBSD committer @ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 16 18:16:14 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26453
	for <isis-archive@odin.ietf.org>; Sat, 16 Jun 2001 18:16:14 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA62457;
	Sat, 16 Jun 2001 15:16:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA62445
	for <isis-wg@spider.juniper.net>; Sat, 16 Jun 2001 15:15:15 -0700 (PDT)
Received: from redcs1.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5GMDBw73241
	for <isis-wg@juniper.net>; Sat, 16 Jun 2001 15:13:11 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by redcs1.procket.com (8.9.3/8.9.3) id PAA28890;
	Sat, 16 Jun 2001 15:13:56 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15147.55844.423463.777557@redcs1.procket.com>
To: Jesper Skriver <jesper@skriver.dk>
Cc: Tony Li <tli@Procket.com>, Ran Atkinson <rja@extremenetworks.com>,
        isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <20010616235709.B71941@skriver.dk>
References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
	<15147.53956.476731.291265@redcs1.procket.com>
	<20010616235709.B71941@skriver.dk>
X-Mailer: VM 6.75 under Emacs 20.5.1
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 16 Jun 2001 15:13:56 -0700 (PDT)
Content-Transfer-Encoding: 7bit



 | pMTUd is what's used generally, so fragmentation by routers isn't
 | seen much in real life.


If that were true, then my life would be a GOOD bit easier.  Sigh.

Tony
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sun Jun 17 08:04:30 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09150
	for <isis-archive@odin.ietf.org>; Sun, 17 Jun 2001 08:04:28 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA65882;
	Sun, 17 Jun 2001 05:04:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA65870
	for <isis-wg@spider.juniper.net>; Sun, 17 Jun 2001 05:03:43 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5HC1Ww79116
	for <isis-wg@juniper.net>; Sun, 17 Jun 2001 05:01:33 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5HC0pH29988;
	Sun, 17 Jun 2001 05:00:51 -0700 (PDT)
Received: from cisco.com (ams-clip-vpn-dhcp6.cisco.com [10.50.0.5])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id AEZ08027 (AUTH rraszuk);
	Sun, 17 Jun 2001 05:02:23 -0700 (PDT)
Message-ID: <3B2C9BE1.29B461AD@cisco.com>
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jesper Skriver <jesper@skriver.dk>
CC: Tony Li <tli@procket.com>, Ran Atkinson <rja@extremenetworks.com>,
        isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <15147.53956.476731.291265@redcs1.procket.com> <20010616235709.B71941@skriver.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sun, 17 Jun 2001 05:00:33 -0700
Content-Transfer-Encoding: 7bit

Jesper,
 
> pMTUd is what's used generally, so fragmentation by routers isn't
> seen much in real life.

Well I am not sure what is your definition of "real life", but at least
in mine the fragmentation is a nightmare of each customer deploying mpls
in his network. By adding 4 or 8 bytes to already maxed ethernet frame
you either must support jumbo frames or fragment. 

As a contrary I would say that MTU path discovery almost never works :).
In 90 % of cases I have seen this is due to misconfigured firewalls (or
as security team say: "configure very tightly" ;). The rest 10% of pmtud
reasons for failures can be found here:
http://www.cisco.com/warp/public/105/38.shtml

R.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sun Jun 17 08:19:08 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09235
	for <isis-archive@odin.ietf.org>; Sun, 17 Jun 2001 08:19:06 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA65970;
	Sun, 17 Jun 2001 05:19:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA65958
	for <isis-wg@spider.juniper.net>; Sun, 17 Jun 2001 05:18:35 -0700 (PDT)
Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5HCGOw79196
	for <isis-wg@juniper.net>; Sun, 17 Jun 2001 05:16:24 -0700 (PDT)
X-JNPR-Received-From: outside
Received: by freesbee.wheel.dk (Postfix, from userid 1001)
	id 3339B5D6A; Sun, 17 Jun 2001 14:17:18 +0200 (CEST)
From: Jesper Skriver <jesper@skriver.dk>
To: Robert Raszuk <raszuk@cisco.com>
Cc: Tony Li <tli@procket.com>, Ran Atkinson <rja@extremenetworks.com>,
        isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
Message-ID: <20010617141718.A5183@skriver.dk>
References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <15147.53956.476731.291265@redcs1.procket.com> <20010616235709.B71941@skriver.dk> <3B2C9BE1.29B461AD@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B2C9BE1.29B461AD@cisco.com>; from raszuk@cisco.com on Sun, Jun 17, 2001 at 05:00:33AM -0700
X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5  5EB4 22AB F0EC F956 1C31
X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sun, 17 Jun 2001 14:17:18 +0200

On Sun, Jun 17, 2001 at 05:00:33AM -0700, Robert Raszuk wrote:
> Jesper,
>  
> > pMTUd is what's used generally, so fragmentation by routers isn't
> > seen much in real life.
> 
> Well I am not sure what is your definition of "real life", but at least
> in mine the fragmentation is a nightmare of each customer deploying mpls
> in his network. By adding 4 or 8 bytes to already maxed ethernet frame
> you either must support jumbo frames or fragment. 

Yes, you need to be able to support atleast 1508 bytes to avoid
fragmentation, but again allmost all modern operating systems do path MTU
discovery ...

> As a contrary I would say that MTU path discovery almost never works :).

As said most OS's have it enabled, and if it doesn't work, there
will be no connectivity, as the routers can't fragment the
packets, and yes I have seen the misconfigured packet filters and
firewall's, it's a pain, but saying that pMTUd almost never work,
is not a accurate statement.

And as most/all OS's have pMTUd enabled, the routers won't have to
do much fragmentation.

> In 90 % of cases I have seen this is due to misconfigured firewalls (or
> as security team say: "configure very tightly" ;). The rest 10% of pmtud
> reasons for failures can be found here:
> http://www.cisco.com/warp/public/105/38.shtml

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:    Network manager   @ AS3292 (Tele Danmark DataNetworks)
Private: FreeBSD committer @ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Mon Jun 18 05:45:09 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02520
	for <isis-archive@odin.ietf.org>; Mon, 18 Jun 2001 05:45:08 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA71107;
	Mon, 18 Jun 2001 02:45:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA71092
	for <isis-wg@spider.juniper.net>; Mon, 18 Jun 2001 02:44:42 -0700 (PDT)
Received: from redcs1.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5I9gNw91944
	for <isis-wg@juniper.net>; Mon, 18 Jun 2001 02:42:23 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by redcs1.procket.com (8.9.3/8.9.3) id CAA06088;
	Mon, 18 Jun 2001 02:43:19 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15149.52535.103197.207393@redcs1.procket.com>
To: RJ Atkinson <rja@inet.org>
Cc: Tony Li <tli@Procket.com>, isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
	<5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
X-Mailer: VM 6.75 under Emacs 20.5.1
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Mon, 18 Jun 2001 02:43:19 -0700 (PDT)
Content-Transfer-Encoding: 7bit


 |         Au contraire.  I fully agree with this.  It is precisely
 | for this reason that we should settle on 9180.  9180 is already
 | quite widely deployed and supported in the Gigabit Ethernet world.
 | Having a 9180 end-to-end MTU supported, which this draft can
 | greatly facilitate, will reduce current fragmentation of 9180
 | into smaller packets (for situations where PMTU is not in use
 | or has been broken somehow).  POS is has a configurable MTU.
 | FDDI is effectively dead, so we ought not limit ourselves to
 | the 4K MTU of FDDI.


Well, unfortunately, no one let all of the manufacturers of POS links in on
your little plan.  The default as shipped is 4470 and I don't know of a
single one that has the buffering to support 9180.

Also, 9180 is NOT necessary to support page flipping.  4470 would seem to
very nicely support a single 4k page.

I agree that NFS over UDP isn't dead yet.  But I sure don't think we should
be optimizing the entire Internet to support a protocol that we're trying
to kill off.

Tony
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 13:09:32 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27464
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 13:09:31 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA78646;
	Tue, 19 Jun 2001 10:09:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA69057
	for <isis-wg@spider.juniper.net>; Sun, 17 Jun 2001 18:34:07 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5I1Vpw85337
	for <isis-wg@juniper.net>; Sun, 17 Jun 2001 18:31:51 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id 3C83A8266E; Sun, 17 Jun 2001 21:32:22 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: Tony Li <tli@Procket.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
Cc: isis-wg@juniper.net
In-Reply-To: <15147.53956.476731.291265@redcs1.procket.com>
References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
 <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sun, 17 Jun 2001 21:28:39 -0400

At 17:42 16/06/01, Tony Li wrote:
>I'm trying to eliminate the need to do high speed fragmentation in the
>backbone of the Internet.  Having multiple MTU sizes is not a good thing
>for anyone and it causes unnecessary inefficiencies for both the router 
>and the end host that has to do the reassembly.  

        The above is a fine rationale for not supporting any form of
jumbogram and just using an end-to-end MTU of 1518 bytes.
Its not consistent with the draft, however.

>From that perspective, adding another MTU size to the Internet simply
>increases the need for fragmentation.  Server sends 9180B packet to
>router A.  Router A fragments to 4470B to get through a POS link.

        Of course, POS links are configurable.  Many, even in Internet
core routers, happen to be configured for 1518 bytes.  See above.

>Somewhere down the path, router B fragments down to 1500B to actually
>deliver to the user over 10BaseT.  How did this help?
>
>The rationale in RFC 1626 is flawed.  At the very least, modern NFS runs
>over TCP, not UDP.  The rest of the RFC has no compelling rationale for a
>larger MTU.  

        Page flipping in servers is a significant performance advantage.
Further, per-packet overhead costs dominate per-byte costs in most
systems.  So having a larger MTU significantly improves the throughput
in practice.  This advantage is not changed by use of NFS/TCP vice 
NFS/UDP.  While  I'm a big fan of NFS/TCP, it has not (in practice) 
eliminated broad use of NFS/TCP.

>RFC 1626 does get one thing right, tho:
>
>       Fragmentation of IP datagrams is known to be highly
>       undesirable. [KM87] 
>
>Do you no longer agree with this?

        Au contraire.  I fully agree with this.  It is precisely
for this reason that we should settle on 9180.  9180 is already
quite widely deployed and supported in the Gigabit Ethernet world.
Having a 9180 end-to-end MTU supported, which this draft can
greatly facilitate, will reduce current fragmentation of 9180
into smaller packets (for situations where PMTU is not in use
or has been broken somehow).  POS is has a configurable MTU.
FDDI is effectively dead, so we ought not limit ourselves to
the 4K MTU of FDDI.

Cheers,

Ran

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 13:11:41 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27541
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 13:11:40 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA78674;
	Tue, 19 Jun 2001 10:12:16 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA71997
	for <isis-wg@spider.juniper.net>; Mon, 18 Jun 2001 06:18:44 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5IDGOw95477
	for <isis-wg@juniper.net>; Mon, 18 Jun 2001 06:16:24 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id 1DB8B8266E
	for <isis-wg@juniper.net>; Mon, 18 Jun 2001 09:17:15 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010618090255.00a0fad0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: isis-wg@juniper.net
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <15149.52535.103197.207393@redcs1.procket.com>
References: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
 <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
 <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Mon, 18 Jun 2001 09:13:32 -0400

At 05:43 18/06/01, Tony Li wrote:
>Well, unfortunately, no one let all of the manufacturers of POS links 
>in on your little plan.  The default as shipped is 4470 and 
>I don't know of a single one that has the buffering to support 9180.

        I know of some POS interfaces that do have RTT ms of
buffering for a 9180 byte MTU.  I don't know if these are the
ones that you built or not, perhaps not given your comment.
Big fast routers with 9180 byte MTU on their GigE interfaces
do exist off the shelf from multiple vendors today.

>Also, 9180 is NOT necessary to support page flipping.  
>4470 would seem to very nicely support a single 4k page.

        True, but 8K pages are commonly used these days, not 4K,
so its of much less benefit than it was in the FDDI era.

>I agree that NFS over UDP isn't dead yet.  But I sure don't think 
>we should be optimizing the entire Internet to support a protocol 
>that we're trying to kill off.

        I didn't know you were on a crusade to kill off NFS.  Over
in other IETF WGs, there are efforts to improve NFS.  As noted
before, page flipping means that 9180 is the right size for
NFS/TCP as well.  Even if one isn't running NFS, the per-packet
overhead in most end systems means that the only way to get 1 Gbps
through a GigE interface is to support large jumbograms.  This
is why the de facto MTU for GigE jumbograms is 9180 bytes.

        More generally, *most* Gigabit Ethernet products that have
shipped in the past 3 years *already* support the 9180 MTU, including
big fast routers with GigE interfaces.  So you forgot to tell the rest 
of the world about your plan for 4470 to be the standard MTU.  This 
means that fragmentation is *already* inevitable on GigE links
(if PMTU is turned off or broken in some way).  My main goal is
to document widely deployed existing practice.  I happen to agree
with the reasons that such is the existing practice as well
(obvious to anyone reading this thread).

        As I noted at the outset, an Informational RFC is totally
non-binding (and the content of standards-track RFCs are pretty 
frequently ignored as well), so I don't see why you are getting
spun up.  

        I think your perspective and mine are pretty well established
at this point (and neither seems to have changed since the prior
conversation when RFC-1626 was an I-D :-).  It would be much more 
useful and productive (IMHO) to hear from other folks here on the list, 
to see if there is consensus one way or the other (perhaps we're both
confused :-).

Cheers,

Ran
rja@inet.org

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 13:13:35 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27621
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 13:13:34 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA78703;
	Tue, 19 Jun 2001 10:13:54 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA74836
	for <isis-wg@spider.juniper.net>; Mon, 18 Jun 2001 18:36:10 -0700 (PDT)
Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5J1Xhw27624
	for <isis-wg@juniper.net>; Mon, 18 Jun 2001 18:33:44 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from ns (mjyang.etri.re.kr [129.254.194.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id MSGMTARK; Tue, 19 Jun 2001 10:32:41 +0900
Message-ID: <001601c0f862$45b2c0c0$37c2fe81@etri.re.kr>
From: "mjyang" <mjyang@etri.re.kr>
To: <isis-wg@juniper.net>
Organization: ETRI
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01C0F8AD.B57A5DA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: [Isis-wg] Help] Figure2 in RFC 1195
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 10:50:52 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C0F8AD.B57A5DA0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGkuLg0KDQpJIGFtIGJlZ2lubmVyIGZvciBJUy1JUy4uDQpJIHdhbnQgdG8gZ2V0IHRoZSBmaWd1
cmUgMihFeGFtcGxlIHJvdXRpbm5nIGRvbWFpbikgaW4gUkZDIDExOTUNCmFuZCBtb3JlIHN0cnVj
dHVyZSBkaWFncmFtIGFuZCBmaWd1cmVzIGFib3V0IElTLUlTIGlmIGFueS4uDQpUaGFuayB5b3Uu
Lg0KDQotLS0tLS0tLS0tLS0tLS0tLQ0KTWlqdW5nIFlhbmcgLyBFVFJJIA0KVEVMOiArODItNDIt
ODYwLTQ5MjIgDQpGQVg6ICs4Mi00Mi04NjAtNTQ0MCANCkUtbWFpbDogbWp5YW5nQGV0cmkucmUu
a3IgDQoNCg==

------=_NextPart_000_0013_01C0F8AD.B57A5DA0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLi48L0ZP
TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBhbSBiZWdp
bm5lciBmb3IgSVMtSVMuLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgd2FudCB0
byBnZXQgdGhlIGZpZ3VyZSAyKEV4YW1wbGUgcm91dGlubmcgZG9tYWluKSBpbiBSRkMgDQoxMTk1
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YW5kIG1vcmUgc3RydWN0dXJlIGRpYWdy
YW0gYW5kIGZpZ3VyZXMgYWJvdXQgSVMtSVMgaWYgDQphbnkuLjwvRk9OVD48L0RJVj4NCjxESVY+
PEZPTlQgc2l6ZT0yPlRoYW5rIHlvdS4uPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N
CjxESVY+PEZPTlQgc2l6ZT0yPi0tLS0tLS0tLS0tLS0tLS0tPEJSPk1panVuZyBZYW5nIC8gRVRS
SSA8QlI+VEVMOiANCis4Mi00Mi04NjAtNDkyMiA8QlI+RkFYOiArODItNDItODYwLTU0NDAgPEJS
PkUtbWFpbDogPEEgDQpocmVmPSJtYWlsdG86bWp5YW5nQGV0cmkucmUua3IiPm1qeWFuZ0BldHJp
LnJlLmtyPC9BPiANCjxCUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0013_01C0F8AD.B57A5DA0--

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 13:16:36 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27711
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 13:16:34 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA78744;
	Tue, 19 Jun 2001 10:15:32 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA76328
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 00:51:56 -0700 (PDT)
Received: from WS0005.indiatimes.com ([203.199.93.15])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5J7nQw34464
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 00:49:27 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from 192.168.57.15 (a3 [192.168.57.23])
	by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id MAA02637
	for "workgroup"<isis-wg@juniper.net>; Tue, 19 Jun 2001 12:55:03 +0530
From: "Sivakumar A" <sivaa@indiatimes.com>
Message-Id: <200106190725.MAA02637@WS0005.indiatimes.com>
To: "workgroup"<isis-wg@juniper.net>
Reply-To: "Sivakumar A"<sivaa@indiatimes.com>
X-URL: http://indiatimes.com
Content-Type: multipart/alternative;
	   boundary="=_MAILER_ATTACH_BOUNDARY1_20016192138201571825916"
MIME-Version: 1.0
Subject: [Isis-wg] request for a draft
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 13:08:20 +0530

--=_MAILER_ATTACH_BOUNDARY1_20016192138201571825916
Content-Type: text/plain; charset=us-ascii

Hi all,


Please update me on the following draft. I am unable to get the draft. 


Callon R W., " Use of OSI IS-IS for Routing in TCP/IP and dual environments" Internet draft &lt;draft-ietf-isis-tcpip-00&gt;, January 1993.


also updat me on ISO/IEC 10589 latest version.


Thanks in advance


Regards,


Sivakumar A
Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com

--=_MAILER_ATTACH_BOUNDARY1_20016192138201571825916
Content-Type: text/html; charset=us-ascii

<P>Hi all,</P>
<P>Please&nbsp;update me on the following draft. I am unable to get the draft. </P>
<P>Callon R W., " Use of OSI IS-IS for Routing in TCP/IP and dual environments" Internet draft &lt;draft-ietf-isis-tcpip-00&gt;, January 1993.</P>
<P>also updat me on ISO/IEC 10589 latest version.</P>
<P>Thanks in advance</P>
<P>Regards,</P>
<P>Sivakumar A</P>
<hr><font face="Arial" size="2"><b>Get Your Private, Free E-mail from Indiatimes at  </font><a href="http://email.indiatimes.com"><font face="Arial" size="2">http://email.indiatimes.com</font></a></b><br>Buy Music, Video, CD-ROM and Audio-Books from <A href="http://www.planetmonline.com">http://www.planetmonline.com</A>

--=_MAILER_ATTACH_BOUNDARY1_20016192138201571825916--

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 13:16:51 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27723
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 13:16:49 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA78788;
	Tue, 19 Jun 2001 10:17:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA77325
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 04:29:13 -0700 (PDT)
Received: from cisco.com (uzura.cisco.com [64.102.17.77])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JBQhw38742
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 04:26:43 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.66.28])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA07415;
	Tue, 19 Jun 2001 07:27:10 -0400 (EDT)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Tony Li <tli@procket.com>
cc: RJ Atkinson <rja@inet.org>, isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <15149.52535.103197.207393@redcs1.procket.com>
Message-ID: <Pine.GSO.4.21.0106190714540.9678-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 07:27:32 -0400 (EDT)


All of the pos links I've checked are 4470 mtu, so that's what
I'd go with. I don't see where the 9180 is gaining you much more,
at least until media that support this sort of mtu are widely
deployed. We can always push a change to this in the future, if
it would be advantageous to do so.

In the meantime, let's not beg for more fragmentation than we
already have.

:-)

Russ

On Mon, 18 Jun 2001, Tony Li wrote:

> 
>  |         Au contraire.  I fully agree with this.  It is precisely
>  | for this reason that we should settle on 9180.  9180 is already
>  | quite widely deployed and supported in the Gigabit Ethernet world.
>  | Having a 9180 end-to-end MTU supported, which this draft can
>  | greatly facilitate, will reduce current fragmentation of 9180
>  | into smaller packets (for situations where PMTU is not in use
>  | or has been broken somehow).  POS is has a configurable MTU.
>  | FDDI is effectively dead, so we ought not limit ourselves to
>  | the 4K MTU of FDDI.
> 
> 
> Well, unfortunately, no one let all of the manufacturers of POS links in on
> your little plan.  The default as shipped is 4470 and I don't know of a
> single one that has the buffering to support 9180.
> 
> Also, 9180 is NOT necessary to support page flipping.  4470 would seem to
> very nicely support a single 4k page.
> 
> I agree that NFS over UDP isn't dead yet.  But I sure don't think we should
> be optimizing the entire Internet to support a protocol that we're trying
> to kill off.
> 
> Tony
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
> 

_____________________________
riw@cisco.com <>< Grace Alone

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 13:27:23 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28015
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 13:27:21 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA78896;
	Tue, 19 Jun 2001 10:28:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA78882
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 10:27:14 -0700 (PDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JHOfw51347
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 10:24:42 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5JHOE403363;
	Tue, 19 Jun 2001 13:24:14 -0400 (EDT)
Received: from mwg-2k-loan1.cisco.com (dhcp-64-102-83-122.cisco.com [64.102.83.122])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AJZ04007;
	Tue, 19 Jun 2001 13:25:40 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010619132353.0190b458@dingdong.cisco.com>
X-Sender: jlearman@dingdong.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Sivakumar A"<sivaa@indiatimes.com>
From: Jeff Learman <jlearman@cisco.com>
Subject: Re: [Isis-wg] request for a draft
Cc: "workgroup"<isis-wg@juniper.net>
In-Reply-To: <200106190725.MAA02637@WS0005.indiatimes.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 13:25:40 -0400


I believe that would be RFC-1195, which is no longer a draft (!)

To get a copy of an ISO document, you'll need to contact your
country's representative agency for ISO documents (ANSI in the US,
if I remember correctly.)

Regards,
Jeff

At 03:38 AM 6/19/2001, Sivakumar A wrote:

>Hi all,
>
>Please update me on the following draft. I am unable to get the draft. 
>
>Callon R W., " Use of OSI IS-IS for Routing in TCP/IP and dual environments" Internet draft <draft-ietf-isis-tcpip-00>, January 1993.
>
>also updat me on ISO/IEC 10589 latest version.
>
>Thanks in advance
>
>Regards,
>
>Sivakumar A
>
>----------
>Get Your Private, Free E-mail from Indiatimes at <http://email.indiatimes.com>http://email.indiatimes.com
>Buy Music, Video, CD-ROM and Audio-Books from <http://www.planetmonline.com>http://www.planetmonline.com 

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 13:55:49 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28862
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 13:55:48 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA79220;
	Tue, 19 Jun 2001 10:56:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA79203
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 10:55:19 -0700 (PDT)
Received: from slim.equipecom.com (ns2.equipecom.com [209.6.39.130])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JHqkw52844
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 10:52:46 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from eccexch01.equipecom.com (eccexch01.equipecom.com [172.17.1.11])
	by slim.equipecom.com (8.11.0/8.11.0) with ESMTP id f5JHrgJ07861;
	Tue, 19 Jun 2001 13:53:42 -0400 (EDT)
Received: by eccexch01.equipecom.com with Internet Mail Service (5.5.2653.19)
	id <L0CJ3KCW>; Tue, 19 Jun 2001 13:53:00 -0400
Message-ID: <E39BEBA2095FD411B77800D0B781FC168F2034@eccexch01.equipecom.com>
From: George Matey <gmatey@equipecom.com>
To: "'Jeff Learman'" <jlearman@cisco.com>,
        Sivakumar A
	 <sivaa@indiatimes.com>
Cc: workgroup <isis-wg@juniper.net>
Subject: RE: [Isis-wg] request for a draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 13:52:59 -0400



ISO/IEC 10589, and its companion documents, are publicly available at:
http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvai
lableStandards.htm

--
George


> -----Original Message-----
> From: Jeff Learman [mailto:jlearman@cisco.com]
> Sent: Tuesday, June 19, 2001 1:26 PM
> To: Sivakumar A
> Cc: workgroup
> Subject: Re: [Isis-wg] request for a draft
> 
> 
> 
> I believe that would be RFC-1195, which is no longer a draft (!)
> 
> To get a copy of an ISO document, you'll need to contact your
> country's representative agency for ISO documents (ANSI in the US,
> if I remember correctly.)
> 
> Regards,
> Jeff
> 
> At 03:38 AM 6/19/2001, Sivakumar A wrote:
> 
> >Hi all,
> >
> >Please update me on the following draft. I am unable to get 
> the draft. 
> >
> >Callon R W., " Use of OSI IS-IS for Routing in TCP/IP and 
> dual environments" Internet draft <draft-ietf-isis-tcpip-00>, 
> January 1993.
> >
> >also updat me on ISO/IEC 10589 latest version.
> >
> >Thanks in advance
> >
> >Regards,
> >
> >Sivakumar A
> >
> >----------
> >Get Your Private, Free E-mail from Indiatimes at 
<http://email.indiatimes.com>http://email.indiatimes.com
>Buy Music, Video, CD-ROM and Audio-Books from
<http://www.planetmonline.com>http://www.planetmonline.com 

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 14:21:00 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29623
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 14:20:59 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA79372;
	Tue, 19 Jun 2001 11:21:11 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA79360
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 11:20:36 -0700 (PDT)
Received: from tot-wa.proxy.aol.com (tot-wa.proxy.aol.com [205.188.192.1])
	  by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id OAA02823 for <isis-wg@external.juniper.net>;
	  Tue, 19 Jun 2001 14:18:40 -0400 (EDT)
Received: from ma.ultranet.com (AC8B0160.ipt.aol.com [172.139.1.96])
	by tot-wa.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f5JIIdi29601
	for <isis-wg@external.juniper.net>; Tue, 19 Jun 2001 14:18:39 -0400 (EDT)
Message-ID: <3B2FC21F.4430786@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] request for a draft
References: <4.3.2.7.2.20010619132353.0190b458@dingdong.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 14:20:31 -0700
Content-Transfer-Encoding: 7bit


Yes, in the US, ANSI (www.ansi.org) has electronic versions 
(pdf files) available for sale, and Global Engineering Documents
(global.ihs.com) has paper copies for sale. 
The electronic ones are cheaper :-)

dave h

Jeff Learman wrote:
> To get a copy of an ISO document, you'll need to contact your
> country's representative agency for ISO documents (ANSI in the US,
> if I remember correctly.)
> Regards,
> Jeff
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 14:28:49 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29742
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 14:28:48 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA79413;
	Tue, 19 Jun 2001 11:25:10 -0700 (PDT)
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA79398
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 11:24:48 -0700 (PDT)
Received: from tot-wa.proxy.aol.com (tot-wa.proxy.aol.com [205.188.192.1])
	  by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id OAA25006 for <isis-wg@external.juniper.net>;
	  Tue, 19 Jun 2001 14:22:22 -0400 (EDT)
Received: from ma.ultranet.com (AC8B0160.ipt.aol.com [172.139.1.96])
	by tot-wa.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f5JIMKi22669
	for <isis-wg@external.juniper.net>; Tue, 19 Jun 2001 14:22:20 -0400 (EDT)
Message-ID: <3B2FC2FD.5FCD502C@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] request for a draft
References: <E39BEBA2095FD411B77800D0B781FC168F2034@eccexch01.equipecom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 14:24:13 -0700
Content-Transfer-Encoding: 7bit


Wow, I didn't know they were available for free now!
Please ignore my last email about ansi and global eng docs.

dave h

George Matey wrote:
> 
> ISO/IEC 10589, and its companion documents, are publicly available at:
> http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvai
> lableStandards.htm
> George
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 15:14:24 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01109
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 15:14:24 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA79755;
	Tue, 19 Jun 2001 12:15:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA79739
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 12:14:32 -0700 (PDT)
Received: from tcb.net (tcb.net [205.168.100.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JJBww56643
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 12:11:58 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1])
	by tcb.net (8.9.3/8.9.3) with ESMTP id MAA00676
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 12:13:02 -0600
Message-Id: <200106191813.MAA00676@tcb.net>
X-Mailer: exmh version 2.0.3
To: isis-wg@juniper.net
From: Danny McPherson <danny@ambernetworks.com>
Reply-To: danny@ambernetworks.com
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 12:13:02 -0600


> All of the pos links I've checked are 4470 mtu, so that's what
> I'd go with. I don't see where the 9180 is gaining you much more,
> at least until media that support this sort of mtu are widely
> deployed. We can always push a change to this in the future, if
> it would be advantageous to do so.

Agreed, and I for one am ot aware of SPs configuring their 
POS links with smaller MTUs.  

I'd also like to hear from other GE switch/router vendors
that agree with Ran that 9180 is 'de facto', we've only heard 
from one thus far (i.e., Ran's).

-danny

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 15:34:01 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01774
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 15:34:01 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA79888;
	Tue, 19 Jun 2001 12:34:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA79876
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 12:33:16 -0700 (PDT)
Received: from redcs1.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JJUhw57480
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 12:30:43 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by redcs1.procket.com (8.9.3/8.9.3) id MAA27252;
	Tue, 19 Jun 2001 12:31:33 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15151.43157.504408.482017@redcs1.procket.com>
To: RJ Atkinson <rja@inet.org>
Cc: isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <5.1.0.14.2.20010618090255.00a0fad0@10.30.15.2>
References: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
	<5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
	<5.1.0.14.2.20010618090255.00a0fad0@10.30.15.2>
X-Mailer: VM 6.75 under Emacs 20.5.1
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 12:31:33 -0700 (PDT)
Content-Transfer-Encoding: 7bit


Ran,

 | >I agree that NFS over UDP isn't dead yet.  But I sure don't think 
 | >we should be optimizing the entire Internet to support a protocol 
 | >that we're trying to kill off.
 | 
 |         I didn't know you were on a crusade to kill off NFS.  


Only the UDP transport.


 | So you forgot to tell the rest 
 | of the world about your plan for 4470 to be the standard MTU.  


Yup, I assumed that this draft would have made it obvious.  Obviously not.
Oh well.  ;-) 


 |         As I noted at the outset, an Informational RFC is totally
 | non-binding (and the content of standards-track RFCs are pretty 
 | frequently ignored as well), so I don't see why you are getting
 | spun up.  


From the level of invective, you seem to be the one getting spun up.

As to it being Informational, we both know that that's a canard.  This is
what will get deployed and used.  We should agree, because it will become
reality.


 |         I think your perspective and mine are pretty well established
 | at this point (and neither seems to have changed since the prior
 | conversation when RFC-1626 was an I-D :-).  It would be much more 
 | useful and productive (IMHO) to hear from other folks here on the list, 
 | to see if there is consensus one way or the other (perhaps we're both
 | confused :-).

<WG co-chair>
I agree completely.  We've now heard from three parties, including
ourselves and not one of the authors of the draft.  This will be an
incredibly rough consensus given the importance of this.

I'll also point out that this difference of opinion also makes it obvious
that the draft DOES need to include some comment as to what the default MTU
should be.  We should not be moving forward without some decision.
</WG co-chair>

Tony
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 15:50:54 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02343
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 15:50:53 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA80029;
	Tue, 19 Jun 2001 12:51:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA80017
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 12:50:34 -0700 (PDT)
Received: from redcs1.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JJm0w58247
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 12:48:01 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by redcs1.procket.com (8.9.3/8.9.3) id MAA25882;
	Tue, 19 Jun 2001 12:48:50 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15151.44194.820031.284764@redcs1.procket.com>
To: RJ Atkinson <rja@inet.org>
Cc: Tony Li <tli@Procket.com>, isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
	<5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
X-Mailer: VM 6.75 under Emacs 20.5.1
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 12:48:50 -0700 (PDT)
Content-Transfer-Encoding: 7bit


 | >I'm trying to eliminate the need to do high speed fragmentation in the
 | >backbone of the Internet.  Having multiple MTU sizes is not a good thing
 | >for anyone and it causes unnecessary inefficiencies for both the router 
 | >and the end host that has to do the reassembly.  
 | 
 |         The above is a fine rationale for not supporting any form of
 | jumbogram and just using an end-to-end MTU of 1518 bytes.
 | Its not consistent with the draft, however.


The draft can be changed.


 | >From that perspective, adding another MTU size to the Internet simply
 | >increases the need for fragmentation.  Server sends 9180B packet to
 | >router A.  Router A fragments to 4470B to get through a POS link.
 | 
 |         Of course, POS links are configurable.  Many, even in Internet
 | core routers, happen to be configured for 1518 bytes.  See above.


Not all POS links can be configured upwards.  Please pardon a short
digression into hardware design.

When designing a store-and-forward device, an interface will have a number
of buffers that it will receive frames into before passing them on for
further processing.  Typically, there will need to be at least two of those
buffers (double buffering) to sustain packet rate and most commonly three.
This gives one buffer for the incoming packet, one for the packet being
handed off into the guts of the system and another just to insure that we
don't get into a bad race condition when both packets are swapping roles at
the same time.

Such buffers are typically on-chip and thus are relatively expensive.  They
also need to be MTU sized.  The combination of these two factors generally
push designers to want a smaller MTU.  It makes the hardware more
efficient, which in turn makes the system more efficient.

Obviously, there are other hardware designs that are possible.  One can do
scatter-gather, for example.  However, that makes the hardware more
complicated, not less.  It seems to me that if we want our systems to have
the peak performance, we should be optimizing them to be efficient and
simple. 


 |         Page flipping in servers is a significant performance advantage.


I agree.  However, we can't use this argument alone to track the evolving
page sizes in processors.  Over the years, we've seen the page size
increase (wasn't the VAX 512B?) and we will not be able to change the MTU
of the Internet to match.  There will always be something bigger.

At the same time, we know that 1500B is inconvenient for everyone.  Even
having the MTU be half or a quarter of the page size would be better as the
driver could then still do page flipping at its external boundary.

 | It is precisely
 | for this reason that we should settle on 9180.  9180 is already
 | quite widely deployed and supported in the Gigabit Ethernet world.
 | Having a 9180 end-to-end MTU supported, which this draft can
 | greatly facilitate, will reduce current fragmentation of 9180
 | into smaller packets (for situations where PMTU is not in use
 | or has been broken somehow).  POS is has a configurable MTU.


Again, there are many POS links in the world which will not work at 9180,
so this is not a deployable solution.  You can come down.  We can't go up.
It's that simple.

Tony
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 16:00:24 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02674
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 16:00:23 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80158;
	Tue, 19 Jun 2001 13:00:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA80135
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 12:59:20 -0700 (PDT)
Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JJujw58611
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 12:56:46 -0700 (PDT)
X-JNPR-Received-From: outside
Message-ID: <EB5FFC72F183D411B3820006295734296AF02F@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Tony Li'" <tli@procket.com>, RJ Atkinson <rja@inet.org>
Cc: isis-wg@juniper.net
Subject: RE: [Isis-wg] More vendor data on IP/GigE MTU
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 15:57:26 -0400

Ran, Tony -

	I remember the history behind this showing up in IS-IS,
but suspect that some who may be interested in the outcome 
might not be watching the IS-IS list for a decision about MTU.  
I'm not sure where it should go, but I suspect that even if 
we get {N-1, 1, 0} consensus on one view or another, it will 
be judged moot unless we get this before a wider venue: some 
group in Transport or IP, perhaps.  

	Is there a lurking AD with an opinion?  

- jeff parker
- axiowave networks
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 16:01:52 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02733
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 16:01:50 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80190;
	Tue, 19 Jun 2001 13:02:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80164
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 13:00:57 -0700 (PDT)
Received: from mx3out.umbc.edu (mx3out.umbc.edu [130.85.253.53])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JJwNw58648
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 12:58:23 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11])
	by mx3out.umbc.edu (8.11.3/8.11.3) with ESMTP id f5JJxO114507;
	Tue, 19 Jun 2001 15:59:24 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id PAA12503268;
	Tue, 19 Jun 2001 15:59:23 -0400 (EDT)
X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs
From: Vijay Gill <vijay@umbc.edu>
X-X-Sender:  <vijay@irix2.gl.umbc.edu>
To: Tony Li <tli@Procket.com>
cc: RJ Atkinson <rja@inet.org>, <isis-wg@juniper.net>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <15151.43157.504408.482017@redcs1.procket.com>
Message-ID: <Pine.SGI.4.31L.02.0106191552170.11964316-100000@irix2.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 15:59:23 -0400

On Tue, 19 Jun 2001, Tony Li wrote:

>
>  | So you forgot to tell the rest
>  | of the world about your plan for 4470 to be the standard MTU.
>
>
> Yup, I assumed that this draft would have made it obvious.  Obviously not.
> Oh well.  ;-)

Most of the backbone devices that go into networks that I have some
familiarity with are required to support at least 4470 MTU (+ whatever
overhead for labels, et al is needed). Reasons for this are varied but in
general tend to be something along the lines of datacenter to datacenter
traffic and OC-x connected customers with servers doing jumbos on gigabit
ethernet devices wanting to talk to other branch offices, and therefore
we'd like to avoid fragmentation if possible.

As an overall percentage of traffic, this is negligible, but thats what I
ask for from an operational perspective.  I don't care if someone supports
9k jumbos, but I do care that my pos and gige boxes can support 4470 MTU.

/vijay

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 16:32:42 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03993
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 16:32:40 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80520;
	Tue, 19 Jun 2001 13:32:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80508
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 13:31:16 -0700 (PDT)
Received: from mx3out.umbc.edu (mx3out.umbc.edu [130.85.253.53])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JKSgw60152
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 13:28:42 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11])
	by mx3out.umbc.edu (8.11.3/8.11.3) with ESMTP id f5JKTg115219;
	Tue, 19 Jun 2001 16:29:43 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id QAA11936088;
	Tue, 19 Jun 2001 16:29:42 -0400 (EDT)
X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs
From: Vijay Gill <vijay@umbc.edu>
X-X-Sender:  <vijay@irix2.gl.umbc.edu>
To: RJ Atkinson <rja@inet.org>
cc: Tony Li <tli@Procket.com>, <isis-wg@juniper.net>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
Message-ID: <Pine.SGI.4.31L.02.0106191623230.11964316-100000@irix2.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 16:29:42 -0400

On Sun, 17 Jun 2001, RJ Atkinson wrote:

>         Au contraire.  I fully agree with this.  It is precisely
> for this reason that we should settle on 9180.  9180 is already
> quite widely deployed and supported in the Gigabit Ethernet world.
> Having a 9180 end-to-end MTU supported, which this draft can
> greatly facilitate, will reduce current fragmentation of 9180
> into smaller packets (for situations where PMTU is not in use
> or has been broken somehow).  POS is has a configurable MTU.
> FDDI is effectively dead, so we ought not limit ourselves to
> the 4K MTU of FDDI.

Ran, for various reasons, including some I sent earlier to the list, from
an operational perspective, I've never seen any demand for > 4470+overhead
MTU. Therefore, any devices that go into networks that I've worked on have
been required to support an MTU of ~4470, and I do not see this changing
in the future. The amount of traffic at even 4470 is fairly small, but
there have been customers who have asked for a 4k MTU. I see no
operational customer based demand to go greater than 4k, and I suspect
this will be true for a while.

/vijay


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 17:59:55 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06151
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 17:59:54 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA81005;
	Tue, 19 Jun 2001 15:00:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA80593
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 13:39:57 -0700 (PDT)
Received: from poker.allegronetworks.com (poker.allegronetworks.com [63.127.26.5])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JKbNw60600
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 13:37:23 -0700 (PDT)
X-JNPR-Received-From: outside
Received: by poker.allegronetworks.com with Internet Mail Service (5.5.2650.21)
	id <NF3K5GBC>; Tue, 19 Jun 2001 16:38:24 -0400
Message-ID: <0850602E0461D511B54B00E0B1041F550230E9@poker.allegronetworks.com>
From: Jed Kaplan <jkaplan@allegronetworks.com>
To: "'isis-wg@juniper.net'" <isis-wg@juniper.net>
Cc: Jed Kaplan <jkaplan@allegronetworks.com>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F8FF.C92C81A0"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 16:38:24 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F8FF.C92C81A0
Content-Type: text/plain;
	charset="iso-8859-1"

With respect to default IP MTU, although the draft did not specify a value,
4470 was desired; to be able to avoid fragmenting
large FDDI packets in some of the authors' ISP networks.

Its not clear which is needed more (or less), large FDDI or (somewhat large)
ATM. In the time between writing the draft and now,
another reason for jumbo frames became clear -  to avoid fragmenting MPLS
packets.  pMTUd rarely works.

Without more input on the predominance of FDDI vs ATM, 4470 seems the
correct choice for default.

-Jed

Jed Kaplan
Allegro Networks
12700 Fair Lakes Circle, Suite 100
Fairfax, Va 22022
email: jkaplan@allegronetworks.com
ph: (703) 802-2348


------_=_NextPart_001_01C0F8FF.C92C81A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Re: [Isis-wg] More vendor data on IP/GigE MTU</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">With respect to default IP MTU, =
although the draft did not specify a value, 4470 was desired; to be =
able to avoid fragmenting</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">large FDDI packets in some of the =
authors' ISP networks.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Its not clear which is needed more (or =
less), large FDDI or (somewhat large) ATM. In the time between writing =
the draft and now,</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">another reason for jumbo frames became =
clear -&nbsp; to avoid fragmenting MPLS packets.&nbsp; pMTUd rarely =
works.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Without more input on the predominance =
of FDDI vs ATM, 4470 seems the correct choice for default.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-Jed</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Jed Kaplan</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Allegro Networks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">12700 Fair Lakes Circle, Suite =
100</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Fairfax, Va 22022</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">email: =
jkaplan@allegronetworks.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ph: (703) 802-2348</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0F8FF.C92C81A0--
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 18:02:19 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06297
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 18:02:19 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA81035;
	Tue, 19 Jun 2001 15:03:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA81011
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 15:00:41 -0700 (PDT)
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5JLw7w64148
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 14:58:07 -0700 (PDT)
X-JNPR-Received-From: outside
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19)
	id <MY7D6AY4>; Tue, 19 Jun 2001 17:59:06 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB359CDBF8@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'Vijay Gill'" <vijay@umbc.edu>, RJ Atkinson <rja@inet.org>
Cc: Tony Li <tli@Procket.com>, isis-wg@juniper.net
Subject: RE: [Isis-wg] More vendor data on IP/GigE MTU
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 17:59:06 -0400

From discussions I've had with folks that were closely involved with Cisco
from the late 80's into the mid 90's, the 4470 MTU was decided upon to
support Token Ring/FDDI-HSSI-Token Ring/FDDI connectivity without
fragmentation.  This MTU was carried over to the PODS3/POS cards in order to
reuse system designs/components, as well as allow for a migration to these
technolgies while preserving the aforementioned environment.  As such, it
would seem that the idea was/should be to have the WAN link MTU be >= to the
largest LAN MTU that is commonplace.  In the early/mid 90's, TR and FDDI
were more common than jumbo-GE/10GE are today, relatively speaking.  Today,
however, there are very few LANs utilizing either of these technologies
(except perhaps big SNA shops).  So logic would dictate that we not reinvent
the wheel, keep it simple, and continue to support 1500 (or 4k if needed).

As to Vijay's point about >4k MTU traffic being fairly smaall, I think that
data provided by providers would indicate that the majority of 4k packets
are BGP updates, and this generally only occurs during session flaps (where
updates can be aggregated because of matching path attribs and
MinAdvertisementInterval is ignored).  As far as customer traffic, 'fairly'
is an understatement.  Words like diminishingly, vanishingly,
infinitessimally, and nil fit the bill nicely, in fact.  The only exception
would be the various tunneling mechanisms in use today (MPLS, GRE, L2TP),
and this still only adds a few hundred bytes, max.

The only need for 9k MTUs would be server-to-server traffic (I am still
waiting for my OC-3 connection to my home and my 10GE NIC for my PC ;>).  If
this has to be done across the Internet at large, then the argument is moot
as this requirement is not going to drive every ISP to change all the
POS/DS3 MTUs in their networks.  If the WAN is under the control of the
operator from end-to-end, then this small subset of hardware purchasers need
to make enough of a stink to get their respective vendors to allow for 9k
buffer allocation, in hardware, on the respective WAN interfaces.  I doubt
this will happen without serious clout (clout = $$$), especially given
Tony's quite fascinating discussion on interface hardware design.

So, we have a few choices:

1) Leave the MTU at 9k as it has been deployed and allow PMTUD to determine
MTU's.  For those vendors that wish to support 9180k MTUs on routers, design
a WAN interface that allows for 9k MTUs to get around fragmentation.
2) Set the MTU to 4470 to match the thousands of deployed links that are in
use today.  
3) Restandardize the PPP/HDLC framing for use over POS to 9180 and force all
the hardware vendors into compliance.
4) Scrap the whole jumbogram idea altogether.

As I see it, these are ranked in order of preference, and perhaps in order
of likeliness as well.

An Operator's Perspective,
-chris



> 
> Ran, for various reasons, including some I sent earlier to 
> the list, from
> an operational perspective, I've never seen any demand for > 
> 4470+overhead
> MTU. Therefore, any devices that go into networks that I've 
> worked on have
> been required to support an MTU of ~4470, and I do not see 
> this changing
> in the future. The amount of traffic at even 4470 is fairly small, but
> there have been customers who have asked for a 4k MTU. I see no
> operational customer based demand to go greater than 4k, and I suspect
> this will be true for a while.
> 
> /vijay
> 
> 
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 19 22:05:20 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11280
	for <isis-archive@odin.ietf.org>; Tue, 19 Jun 2001 22:05:19 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA82133;
	Tue, 19 Jun 2001 19:05:12 -0700 (PDT)
Received: from ligarius-fe0.ultra.net (ligarius-fe0.ultra.net [146.115.8.189])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA82110
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 19:04:12 -0700 (PDT)
Received: from ma.ultranet.com (216-164-248-226.s2702.apx1.sbo.ma.dialup.rcn.com [216.164.248.226]) by ligarius-fe0.ultra.net (8.8.8/ult/n26500/mtc.v2) with ESMTP id WAA03802 for <isis-wg@external.juniper.net>; Tue, 19 Jun 2001 22:02:37 -0400 (EDT)
Message-ID: <3B302EDF.4717E787@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Isis-wg] Whither draft-ietf-isis-hmac-nn.txt ?
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 22:04:31 -0700
Content-Transfer-Encoding: 7bit

Hi all,

Whatever happened to draft-ietf-isis-hmac-01.txt ?
It seems to have expired, and doesn't seem to have
graduated into an official RFC yet? The last
thing I could find mentioning it said it was stable
and clear for implementation (back in Aug of last year)...
was the work abandoned?

adTHANKSvance,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 01:27:36 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16049
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 01:27:36 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA82969;
	Tue, 19 Jun 2001 22:28:10 -0700 (PDT)
Received: from pltn13.pbi.net (mta8.pltn13.pbi.net [64.164.98.22])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA82957
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 22:27:32 -0700 (PDT)
Received: from redback.com ([63.200.51.77])
 by mta8.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001))
 with ESMTP id <0GF7007YLQ2CCF@mta8.pltn13.pbi.net> for
 isis-wg@spider.juniper.net; Tue, 19 Jun 2001 22:03:49 -0700 (PDT)
From: Tony Przygienda <prz@redback.com>
Subject: Re: [Isis-wg] Whither draft-ietf-isis-hmac-nn.txt ?
To: David Hudek <dhudek@ma.ultranet.com>
Cc: isis-wg@spider.juniper.net
Message-id: <3B302AD9.D72AD6C3@redback.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <3B302EDF.4717E787@ma.ultranet.com>
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 21:47:21 -0700
Content-Transfer-Encoding: 7BIT

David Hudek wrote:

> Hi all,
>
> Whatever happened to draft-ietf-isis-hmac-01.txt ?
> It seems to have expired, and doesn't seem to have
> graduated into an official RFC yet? The last
> thing I could find mentioning it said it was stable
> and clear for implementation (back in Aug of last year)...
> was the work abandoned?

RJA is working on a new version that should have been
forthcoming since a while. Funny enough, it's implemented
and deployed already ;-) by some leading vendors ...

    thanks

    -- tony



_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 04:54:24 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00830
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 04:54:22 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA83845;
	Wed, 20 Jun 2001 01:55:10 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA83830
	for <isis-wg@spider.juniper.net>; Wed, 20 Jun 2001 01:54:50 -0700 (PDT)
Received: from cisco.com (jaws.cisco.com [198.135.0.150])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5K8qAw80438
	for <isis-wg@juniper.net>; Wed, 20 Jun 2001 01:52:11 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp19.cisco.com [144.254.108.86])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA01816;
	Wed, 20 Jun 2001 09:53:06 +0100 (BST)
Message-Id: <4.3.2.7.2.20010620095304.032ee270@jaws.cisco.com>
X-Sender: mshand@jaws.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "mjyang" <mjyang@etri.re.kr>
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] Help] Figure2 in RFC 1195
Cc: <isis-wg@juniper.net>
In-Reply-To: <001601c0f862$45b2c0c0$37c2fe81@etri.re.kr>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 20 Jun 2001 09:53:40 +0100

<html>
At 10:50 19/06/2001 +0900, mjyang wrote:<br>
<blockquote type=cite cite><font size=2>Hi..</font><br>
&nbsp;<br>
<font size=2>I am beginner for IS-IS..</font><br>
<font size=2>I want to get the figure 2(Example routinng domain) in RFC
1195</font><br>
<font size=2>and more structure diagram and figures about IS-IS if
any..</font><br>
<font size=2>Thank you..</font></blockquote><br>
Try the postScript version<br>
<br>
<a href="ftp://ftp.isi.edu/in-notes/rfc1195.ps" eudora="autourl">ftp://ftp.isi.edu/in-notes/rfc1195.ps<br>
<br>
<br>
</a><blockquote type=cite cite>&nbsp;<br>
<font size=2>-----------------<br>
Mijung Yang / ETRI <br>
TEL: +82-42-860-4922 <br>
FAX: +82-42-860-5440 <br>
E-mail: <a href="mailto:mjyang@etri.re.kr">mjyang@etri.re.kr</a>
</font></blockquote></html>

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 06:52:30 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01990
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 06:52:29 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA84519;
	Wed, 20 Jun 2001 03:53:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA84507
	for <isis-wg@spider.juniper.net>; Wed, 20 Jun 2001 03:52:26 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5KAnkw82524
	for <isis-wg@juniper.net>; Wed, 20 Jun 2001 03:49:46 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01820;
	Wed, 20 Jun 2001 06:50:14 -0400 (EDT)
Message-Id: <200106201050.GAA01820@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: isis-wg@juniper.net
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-eth-00.txt
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 20 Jun 2001 06:50:13 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title		: Extended Ethernet Frame Size Support
	Author(s)	: J. Kaplan et al.
	Filename	: draft-ietf-isis-ext-eth-00.txt
	Pages		: 
	Date		: 19-Jun-01
	
This document presents an extension to current Ethernet Frame 
specifications for hardware and frame format to support payloads 
greater than 1500 Bytes for Type interpretation and Length 
interpretation frames. This is useful for Gigabit Ethernet
technology, providing a means to carry large MTU packets without
fragmentation over a high-speed broadcast network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-isis-ext-eth-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-isis-ext-eth-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010619113121.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-isis-ext-eth-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-isis-ext-eth-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010619113121.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 15:00:09 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18227
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:00:08 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA86684;
	Wed, 20 Jun 2001 12:00:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA81943
	for <isis-wg@spider.juniper.net>; Tue, 19 Jun 2001 18:30:36 -0700 (PDT)
Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5K1S0w71474
	for <isis-wg@juniper.net>; Tue, 19 Jun 2001 18:28:00 -0700 (PDT)
X-JNPR-Received-From: outside
Received: by overlord.e-gerbil.net (Postfix, from userid 1001)
	id BFD92E4DF0; Tue, 19 Jun 2001 21:29:01 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by overlord.e-gerbil.net (Postfix) with ESMTP
	id 98DDFE4B8C; Tue, 19 Jun 2001 21:29:01 -0400 (EDT)
From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: RJ Atkinson <rja@inet.org>
Cc: isis-wg@juniper.net
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
Message-ID: <Pine.BSF.4.21.0106192111140.29677-100000@overlord.e-gerbil.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 19 Jun 2001 21:29:01 -0400 (EDT)

On Mon, Jun 18, 2001 at 09:13:32AM -0400, RJ Atkinson wrote:
>
> >Also, 9180 is NOT necessary to support page flipping.
> >4470 would seem to very nicely support a single 4k page.
>
>         True, but 8K pages are commonly used these days, not 4K,
> so its of much less benefit than it was in the FDDI era.

Not really, but they will probably be more common w/IA64 and other
architectures, which will probably NOT want to use 4K pages.

>         More generally, *most* Gigabit Ethernet products that have
> shipped in the past 3 years *already* support the 9180 MTU, including
> big fast routers with GigE interfaces.  So you forgot to tell the rest
> of the world about your plan for 4470 to be the standard MTU.  This
> means that fragmentation is *already* inevitable on GigE links (if
> PMTU is turned off or broken in some way).  My main goal is to
> document widely deployed existing practice.  I happen to agree with
> the reasons that such is the existing practice as well (obvious to
> anyone reading this thread).

In my experience, most GigE vendors do NOT support 9180. I've seen all
kinds of numbers all around that, and some not even close depending on the
product line or specific hardware.

>         As I noted at the outset, an Informational RFC is totally
> non-binding (and the content of standards-track RFCs are pretty
> frequently ignored as well), so I don't see why you are getting
> spun up.

I think the most useful thing this could do is establish a definition for
"real" jumbo frame support. At this point I don't really care what it is,
8192 and some bytes for headers, 9180 is fine, but we need a STANDARD. Any
such document should also spend time covering the benefits of jumbo frame
support, since it seems that a number of people just don't "get it".

I have to admit I really don't understand the IEEE. GigE/10GE is going to
be far more common on a router or at an exchange point then on a host for
a long time. There are simply too many legitimate reasons to desire
support for a common larger frame size on non-host ethernet to reject the
concept on the basis of someone's hardon for what their 1985 copy of
Merriam Webster says for "WAN" and "LAN".

Perhaps it would also be useful to focus on fixing Path MTU Discovery. For
example, it might make sense to inform the sender about fragmentation in
the TCP ACK, to prevent misconfigured icmp filters or rate limits. If
PMTUD worked right, we would be able to support the most optimal MTU size
seemlessly.

-- 
Richard A Steenbergen <ras@e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 15:02:46 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18426
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:02:45 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA86709;
	Wed, 20 Jun 2001 12:03:41 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA85084
	for <isis-wg@spider.juniper.net>; Wed, 20 Jun 2001 05:53:06 -0700 (PDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id CA1768266E; Wed, 20 Jun 2001 08:51:11 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010620084531.00a15890@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: Tony Przygienda <prz@redback.com>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] Whither draft-ietf-isis-hmac-nn.txt ?
Cc: isis-wg@spider.juniper.net
In-Reply-To: <3B302AD9.D72AD6C3@redback.com>
References: <3B302EDF.4717E787@ma.ultranet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 20 Jun 2001 08:47:25 -0400

At 00:47 20/06/01, Tony Przygienda wrote:
>RJA is working on a new version that should have been
>forthcoming since a while. Funny enough, it's implemented
>and deployed already ;-) by some leading vendors ...

        The draft I recently came up with didn't get past
the small set of editors.  So an edit spin is currently in
progress to try to fix the identified bugs.  With luck,
that version will get past the internal editors and appear 
as an I-D.

        Operator feedback during the past long while has had 
substantial impact on this draft's technical content.

Ran

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 15:04:28 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18487
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:04:26 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA86739;
	Wed, 20 Jun 2001 12:05:20 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA85124
	for <isis-wg@spider.juniper.net>; Wed, 20 Jun 2001 05:58:55 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5KCuEw84924
	for <isis-wg@juniper.net>; Wed, 20 Jun 2001 05:56:14 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id ED5658266E; Wed, 20 Jun 2001 08:57:11 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010620085009.00a1a660@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: Vijay Gill <vijay@umbc.edu>
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
Cc: <isis-wg@juniper.net>
In-Reply-To: <Pine.SGI.4.31L.02.0106191552170.11964316-100000@irix2.gl.u
 mbc.edu>
References: <15151.43157.504408.482017@redcs1.procket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 20 Jun 2001 08:53:25 -0400

At 15:59 19/06/01, Vijay Gill wrote:
> least 4470 MTU (+ whatever
>overhead for labels, et al is needed). Reasons for this are varied but in
>general tend to be something along the lines of datacenter to datacenter
>traffic and OC-x connected customers with servers doing jumbos on gigabit
>ethernet devices wanting to talk to other branch offices, and therefore
>we'd like to avoid fragmentation if possible.

Vijay,

        I'm confused by your reasoning method.  As currently deployed, 
"jumbos on gigabit ethernet devices" have an MTU of 9180, not 4470.  
If your comment had said "jumbos on gig ethernet devices are uncommon", 
then the conclusion in favour of 4470 would have been a ton more obvious 
to me.  Saying that "jumbos on gigabit ethernet devices" and wanting
to avoid fragmentation are reasons for 9180 instead of 4470.
(Clarification welcome. :-)

        There is also the small matter that a number of exchange points 
(notably LINX, PAIX) support 9180 MTU Ethernet today.  I recognise
you're on the AboveNet side rather than the PAIX side, but any
comments on that ?

Ran

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 15:06:06 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18561
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:06:05 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA86771;
	Wed, 20 Jun 2001 12:07:04 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA85182
	for <isis-wg@spider.juniper.net>; Wed, 20 Jun 2001 06:07:30 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5KD4nw85189
	for <isis-wg@juniper.net>; Wed, 20 Jun 2001 06:04:49 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id E14A98266E
	for <isis-wg@juniper.net>; Wed, 20 Jun 2001 09:05:51 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010620085427.00a1e760@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: isis-wg@juniper.net
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] hardware tradeoffs
In-Reply-To: <15151.44194.820031.284764@redcs1.procket.com>
References: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
 <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2>
 <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 20 Jun 2001 09:02:05 -0400

At 15:48 19/06/01, Tony Li wrote:
>Again, there are many POS links in the world which will not work at 9180,
>so this is not a deployable solution.  You can come down.  We can't go up.
>It's that simple.

        Having done a fair amount of hardware work lately, including
some on POS interfaces, I'll simply note that its entirely practical
and cost-effective to design a POS interface that can have 
variable amounts of memory buffering.  Some other vendors have 
shipped these, even if you have chosen not to do this.

        As to the GigE MTU, a number of implementations can't change 
MTU downwards easily without spinning hardware (this is one of the
business risks associated with very highly integrated devices; entirely
analagous to the business risk of not designing a POS interface to
be able to support enough buffer memory) and getting paying customers 
very very upset with us.  GigE vendors went to 9180 due to strong paying 
customer demand, not on some whim.  That noted, if folks only offer 
GigE frames with a 4470 MTU, then they obviously get passed through 
GigE devices just fine.  It is not realistic to expect that existing 
GigE devices will be doing the fragmentation on behalf of some 
downstream device that's out of step with the rest of the GigE world. 
Most hosts use software for generating packets, so the originating
hosts notionally could reconfigure their MTU down to 4470 on their
GigE interfaces.  No doubt there is some "registry" variable for this
in Windows, for example.

        It sure sounds like we had all better start trying to figure
out how to make PMTU work more reliably... :-)

Regards,

Ran

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 15:07:44 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18712
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:07:43 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA86799;
	Wed, 20 Jun 2001 12:08:44 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA85219
	for <isis-wg@spider.juniper.net>; Wed, 20 Jun 2001 06:11:07 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5KD8Pw85274
	for <isis-wg@juniper.net>; Wed, 20 Jun 2001 06:08:26 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.inet.org (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP
	id 75D948266E; Wed, 20 Jun 2001 09:09:28 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010620090309.00a1bec0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: danny@ambernetworks.com
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU 
Cc: isis-wg@juniper.net
In-Reply-To: <200106191813.MAA00676@tcb.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 20 Jun 2001 09:05:42 -0400

At 14:13 19/06/01, Danny McPherson wrote:
>I'd also like to hear from other GE switch/router vendors
>that agree with Ran that 9180 is 'de facto', we've only heard 
>from one thus far (i.e., Ran's).

Foundry, Cisco (most products, one exception that I've heard
about anecdotally), and Alteon (original proponent of 9180; 
now owned by Nortel) all support 9180 IP MTU  (9200 byte Ethernet MTU).  
A range of workstations/servers, including WindowsNT/Windows2000,
support it.  Not all of those vendors are subscribed to the
IS-IS mailing list, by the way, so I'd encourage you to pick
up the phone if you want to hear answers from them directly.

Ran

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 20 15:33:45 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19539
	for <isis-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:33:43 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA87116;
	Wed, 20 Jun 2001 12:34:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA87096
	for <isis-wg@spider.juniper.net>; Wed, 20 Jun 2001 12:33:19 -0700 (PDT)
Received: from mx3out.umbc.edu (mx3out.umbc.edu [130.85.253.53])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5KJUZw01666
	for <isis-wg@juniper.net>; Wed, 20 Jun 2001 12:30:35 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11])
	by mx3out.umbc.edu (8.11.3/8.11.3) with ESMTP id f5KJVc110008;
	Wed, 20 Jun 2001 15:31:38 -0400 (EDT)
Received: from localhost (vijay@localhost)
	by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id PAA12593642;
	Wed, 20 Jun 2001 15:31:38 -0400 (EDT)
X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs
From: Vijay Gill <vijay@umbc.edu>
X-X-Sender:  <vijay@irix2.gl.umbc.edu>
To: RJ Atkinson <rja@inet.org>
cc: <isis-wg@juniper.net>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <5.1.0.14.2.20010620085009.00a1a660@10.30.15.2>
Message-ID: <Pine.SGI.4.31L.02.0106201523360.12700982-100000@irix2.gl.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 20 Jun 2001 15:31:38 -0400

On Wed, 20 Jun 2001, RJ Atkinson wrote:

Ran,

>         I'm confused by your reasoning method.  As currently deployed,
> "jumbos on gigabit ethernet devices" have an MTU of 9180, not 4470.
> If your comment had said "jumbos on gig ethernet devices are uncommon",
> then the conclusion in favour of 4470 would have been a ton more obvious
> to me.  Saying that "jumbos on gigabit ethernet devices" and wanting
> to avoid fragmentation are reasons for 9180 instead of 4470.
> (Clarification welcome. :-)

Apologies for the unclear wording. I really should have said 'all we
_cared_ about was ~4k mtu.' If it went higher, ok, we set it to 4470 and
moved on.  The point being that we didn't care about an mtu higher than
~4k, we only ensured that the edge-edge MTU in the network was at least
4470. Now this was the result of historical accident perhaps, but the only
MTU related questions (a few) customers asked was if we had a 4k mtu, and
we could answer in the affirmative to that. No one asked for a 9k that I
was aware of, so we did not bother.

>         There is also the small matter that a number of exchange
> points (notably LINX, PAIX) support 9180 MTU Ethernet today.  I
> recognise you're on the AboveNet side rather than the PAIX side, but
> any comments on that ?

I work for Metromedia, not AboveNet.  PAIX questions would be best
answered by Paul and company, but I do know that there has always been a
push for large MTU by those folks.

/vijay

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Thu Jun 21 19:12:16 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19984
	for <isis-archive@odin.ietf.org>; Thu, 21 Jun 2001 19:12:14 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA93749;
	Thu, 21 Jun 2001 16:12:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA93737
	for <isis-wg@spider.juniper.net>; Thu, 21 Jun 2001 16:11:28 -0700 (PDT)
Received: from tcb.net (tcb.net [205.168.100.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5LN8Ww56822
	for <isis-wg@juniper.net>; Thu, 21 Jun 2001 16:08:32 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1])
	by tcb.net (8.9.3/8.9.3) with ESMTP id QAA20071
	for <isis-wg@juniper.net>; Thu, 21 Jun 2001 16:09:41 -0600
Message-Id: <200106212209.QAA20071@tcb.net>
X-Mailer: exmh version 2.0.3
To: isis-wg@juniper.net
From: Danny McPherson <danny@ambernetworks.com>
Reply-To: danny@ambernetworks.com
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Thu, 21 Jun 2001 16:09:41 -0600



[]
To: isis-wg@juniper.net
From: RJ Atkinson <rja@inet.org>
Date: Mon, 18 Jun 2001 09:13:32 -0400

[...]
        As I noted at the outset, an Informational RFC is totally
non-binding (and the content of standards-track RFCs are pretty 
frequently ignored as well), so I don't see why you are getting
spun up.  
[...]

Then:

[]
Date: Thu, 21 Jun 2001 17:48:38 -0400
To: ipng@sunroof.eng.sun.com
From: Ran Atkinson <rja@extremenetworks.com>

[...]
	Because all IS-IS WG documents are published as Informational 
RFCs (because ISO is the standards-body for IS-IS), many folks treat 
Informational RFCs from the IS-IS WG as carrying equal weight
as a standards-track document.  While it might not precisely *be*
a standards-tack document, this tends to be the reality of output
from that particular WG.
[...]


Quite the change of heart...

However, I'm not sure I agree with your second assessment 
Of course, most folks outside the IETF seem to place little 
emphasis on the "track", regardless of what WG a given 
document is a product of.  Then again, we're not outside the 
IETF.

I recall the initial reasoning for the "Extended Ethernet 
Frame Size Support" draft being a product of the ISIS WG,
but I believe now that it should probably fall into an area
that would get it more exposure and feedback.

-danny

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 22 07:14:44 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16288
	for <isis-archive@odin.ietf.org>; Fri, 22 Jun 2001 07:14:44 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA96681;
	Fri, 22 Jun 2001 04:15:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA96666
	for <isis-wg@spider.juniper.net>; Fri, 22 Jun 2001 04:14:41 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5MBBew74012
	for <isis-wg@juniper.net>; Fri, 22 Jun 2001 04:11:40 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15925;
	Fri, 22 Jun 2001 07:12:13 -0400 (EDT)
Message-Id: <200106221112.HAA15925@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: isis-wg@juniper.net
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-03.txt
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 22 Jun 2001 07:12:13 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title		: IS-IS extensions for Traffic Engineering
	Author(s)	: T. Li, H. Smit
	Filename	: draft-ietf-isis-traffic-03.txt
	Pages		: 11
	Date		: 21-Jun-01
	
This document describes extensions to the IS-IS protocol to support
Traffic Engineering [1].  The IS-IS protocol is specified in [2],
with extensions for supporting IPv4 specified in [3].
This document extends the IS-IS protocol by specifying new
information that a Intermediate System (IS) [router] can place in
Link State Protocol Data Units (LSPs).  This information describes
additional information about the state of the network that is useful
for traffic engineering computations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-isis-traffic-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-isis-traffic-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010621134404.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-isis-traffic-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-isis-traffic-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010621134404.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Mon Jun 25 21:20:37 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01486
	for <isis-archive@odin.ietf.org>; Mon, 25 Jun 2001 21:20:35 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA18769;
	Mon, 25 Jun 2001 18:21:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA98407
	for <isis-wg@spider.juniper.net>; Fri, 22 Jun 2001 11:34:48 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5MIViw90335
	for <isis-wg@juniper.net>; Fri, 22 Jun 2001 11:31:44 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.inet.org (rja-laptop [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP
	id 29CFA8266E; Fri, 22 Jun 2001 14:32:47 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010622142811.00a21e10@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: danny@ambernetworks.com
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] More vendor data on IP/GigE MTU 
Cc: isis-wg@juniper.net
In-Reply-To: <200106212209.QAA20071@tcb.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 22 Jun 2001 14:28:57 -0400

At 18:09 21/06/01, Danny McPherson wrote:
>Quite the change of heart...

Customer input is a very good way, probably the most effective way, 
to help me change my mind.  That happened in this case.

Ran

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 26 17:24:07 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20665
	for <isis-archive@odin.ietf.org>; Tue, 26 Jun 2001 17:24:05 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA23620;
	Tue, 26 Jun 2001 14:22:12 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA23608
	for <isis-wg@spider.juniper.net>; Tue, 26 Jun 2001 14:21:12 -0700 (PDT)
Received: from mail.kebne.se (mail.kebne.se [212.209.134.151])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5QLHQw05994
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 14:17:26 -0700 (PDT)
X-JNPR-Received-From: outside
Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19)
	id <MAGP8CGT>; Tue, 26 Jun 2001 23:18:46 +0200
Message-ID: <31A473DBB655D21180850008C71E251A04D67B52@mail.kebne.se>
From: Anders Lowinger <anders.lowinger@xelerated.com>
To: Tony Li <tli@procket.com>, RJ Atkinson <rja@inet.org>
Cc: isis-wg@juniper.net
Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 26 Jun 2001 23:18:38 +0200

> Such buffers are typically on-chip and thus are relatively 
> expensive.  They also need to be MTU sized.  The combination of 
> these two factors generally push designers to want a smaller MTU.
> It makes the hardware more efficient, which in turn makes the 
> system more efficient.

Tony,

I'm pretty sure you know this so this is for the rest of the list.

One big difference between POS and Ethernet is that if you have
channelized interfaces on POS the data is byte-interleaved =>
reassembly is needed.

If you have channelization on Ethernet, or VLAN's as it is
called :-) each frame is sent back-to-back.

What is the difference?

Well, on a 10GE interface, to support 192 VLAN's you need
3x9180 bytes of store-and-forward buffer.

On a channelized OC192 down to OC1 (DS3/T3) this will require
192x9180 bits of store-and-forward buffer. As Tony mentioned
these buffers usually are on-chip and 1,68 Mbyte of on-chip
memory is very much.

(Actually you need the same amount in the transmit path also).

Lower MTU really helps here!

Back to ISIS, do we really need LSP datagrams with sizes over
1492? We could use the trick with multiple system-ID's if we
run out of LSP space.

What is the probability that we will have an ISIS area in
which we can increase the LSP size >1492? I doubt we will
see many of them.

Send IP Jumbograms with EthernetII type codes, the ISIS
datagrams as we do today (I think Henk mentioned this
a long time ago).

Regards
Anders Lowinger
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 26 19:06:55 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06889
	for <isis-archive@odin.ietf.org>; Tue, 26 Jun 2001 19:06:54 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA24081;
	Tue, 26 Jun 2001 16:08:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA24069
	for <isis-wg@spider.juniper.net>; Tue, 26 Jun 2001 16:07:04 -0700 (PDT)
Received: from redcs1.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5QN3Iw10129
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 16:03:18 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by redcs1.procket.com (8.9.3/8.9.3) id QAA27887;
	Tue, 26 Jun 2001 16:04:37 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15161.5381.530373.68221@redcs1.procket.com>
To: Anders Lowinger <anders.lowinger@xelerated.com>
Cc: Tony Li <tli@Procket.com>, RJ Atkinson <rja@inet.org>, isis-wg@juniper.net
Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <31A473DBB655D21180850008C71E251A04D67B52@mail.kebne.se>
References: <31A473DBB655D21180850008C71E251A04D67B52@mail.kebne.se>
X-Mailer: VM 6.92 under Emacs 20.5.1
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 26 Jun 2001 16:04:37 -0700
Content-Transfer-Encoding: 7bit



 | On a channelized OC192 down to OC1 (DS3/T3) this will require
 | 192x9180 bits of store-and-forward buffer. As Tony mentioned
 | these buffers usually are on-chip and 1,68 Mbyte of on-chip
 | memory is very much.


Excellent point.


 | Back to ISIS, do we really need LSP datagrams with sizes over
 | 1492? We could use the trick with multiple system-ID's if we
 | run out of LSP space.


Practically speaking, increasing the size of the LSP is a non-starter.  It
requires domain-wide coordination of the LSP size.  That would practically
be impossible for any domain that actually needed a larger LSP.


 | Send IP Jumbograms with EthernetII type codes, the ISIS
 | datagrams as we do today (I think Henk mentioned this
 | a long time ago).


It's not just the LSPs.  There are also the IIH's to think about.

Tony
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 26 19:12:19 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07914
	for <isis-archive@odin.ietf.org>; Tue, 26 Jun 2001 19:12:18 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA24125;
	Tue, 26 Jun 2001 16:13:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA24113
	for <isis-wg@spider.juniper.net>; Tue, 26 Jun 2001 16:12:34 -0700 (PDT)
Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5QN8mw10396
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 16:08:48 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from henk@localhost)
	by redd3174.procket.com (8.11.0/8.9.3) id f5QNA9U28078;
	Tue, 26 Jun 2001 16:10:09 -0700
From: Henk Smit <henk@Procket.com>
Message-Id: <200106262310.f5QNA9U28078@redd3174.procket.com>
X-Confidential: Procket Confidential/Need to know
Subject: Re: SV: [Isis-wg] More vendor data on IP/GigE MTU
To: anders.lowinger@xelerated.com (Anders Lowinger)
Cc: isis-wg@juniper.net
In-Reply-To: <31A473DBB655D21180850008C71E251A04D67B52@mail.kebne.se> from "Anders Lowinger" at Jun 26, 2001 11:18:38 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 26 Jun 2001 16:10:09 -0700 (PDT)
Content-Transfer-Encoding: 7bit


> Back to ISIS, do we really need LSP datagrams with sizes over 1492?

  No, ISIS doesn't need larger LSPs.

  The problem was this:
 *) Some router vendors support "jumboframes" over GE.
 *) IP packets are encapsulated in EthernetII frames. (*)
 *) Encapsulation of EthernetII frames in such jumboframes is easy.
 *) ISIS sends hellos padded to mtu size, to do early detection
    of mtu mismatches, and other problems.
 *) Some ISPs wanted this early detection to keep working even over
    GE with jumboframes.
 *) Therefor, ISIS must send hellos padded up to "jumboframe mtu"
 *) ISIS packets are encapsulated in 802.3/802.2 frames. (*)
 *) 802.3/802.2 frames can not be longer than 1500 bytes.
 *) Therefor ISIS can not use jumboframes.
 *) To solve this problem (and IMHO only this problem of padded hellos)
    draft-ietf-isis-ext-eth-00.txt was written.

  Possible solutions:
 1) Change ethernet specs.
 2) Make IS-IS use EthernetII encapsulation.
 3) Make IS-IS use IP encapsulation.
 4) Forget about padding IS-IS hellos to mtu-size.
                
  It seems proposal 1) encountered more opposition than envisioned. :-)
 Proposals 2) and 3) are gonna introduce lots and lots of interoperability
 problems. Not worthwile, IMHO.

  Doing 4) seems a nice and simple solution. And it has the benefit that
 ISIS will  keep working on bridged networks of GE and other flavors
 of Ethernet.

  I never understood why ISPs insisted on keeping ISIS to pad its hellos
 to mtu-size. OSPF sends small hellos, and that does not seem to give
 many more headaches.

     henk.

--
PS.(*) I know this terminology is not the proper lingo anymore. If you know
how to call those 2 encapsulation methods, please educate me. Thanks.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 26 19:28:25 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11355
	for <isis-archive@odin.ietf.org>; Tue, 26 Jun 2001 19:28:25 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA24240;
	Tue, 26 Jun 2001 16:30:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA24225
	for <isis-wg@spider.juniper.net>; Tue, 26 Jun 2001 16:29:36 -0700 (PDT)
Received: from redd2222.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5QNPnw11021
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 16:25:49 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1])
	by redd2222.procket.com (8.11.0/8.9.3) with ESMTP id f5QNR9b22596;
	Tue, 26 Jun 2001 16:27:09 -0700
X-Confidential: Procket Confidential/Need to know
Message-ID: <3B391A4D.2492FF7E@procket.com>
From: Derek Yeung <myeung@procket.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Henk Smit <henk@procket.com>
CC: Anders Lowinger <anders.lowinger@xelerated.com>, isis-wg@juniper.net
Subject: Re: SV: [Isis-wg] More vendor data on IP/GigE MTU
References: <200106262310.f5QNA9U28078@redd3174.procket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 26 Jun 2001 16:27:09 -0700
Content-Transfer-Encoding: 7bit

Henk Smit wrote:
> 
> > Back to ISIS, do we really need LSP datagrams with sizes over 1492?
> 
>   No, ISIS doesn't need larger LSPs.
> 
>   The problem was this:
>  *) Some router vendors support "jumboframes" over GE.
>  *) IP packets are encapsulated in EthernetII frames. (*)
>  *) Encapsulation of EthernetII frames in such jumboframes is easy.
>  *) ISIS sends hellos padded to mtu size, to do early detection
>     of mtu mismatches, and other problems.
>  *) Some ISPs wanted this early detection to keep working even over
>     GE with jumboframes.
>  *) Therefor, ISIS must send hellos padded up to "jumboframe mtu"
>  *) ISIS packets are encapsulated in 802.3/802.2 frames. (*)
>  *) 802.3/802.2 frames can not be longer than 1500 bytes.
>  *) Therefor ISIS can not use jumboframes.
>  *) To solve this problem (and IMHO only this problem of padded hellos)
>     draft-ietf-isis-ext-eth-00.txt was written.
> 
>   Possible solutions:
>  1) Change ethernet specs.
>  2) Make IS-IS use EthernetII encapsulation.
>  3) Make IS-IS use IP encapsulation.
>  4) Forget about padding IS-IS hellos to mtu-size.
> 
>   It seems proposal 1) encountered more opposition than envisioned. :-)
>  Proposals 2) and 3) are gonna introduce lots and lots of interoperability
>  problems. Not worthwile, IMHO.
> 
>   Doing 4) seems a nice and simple solution. And it has the benefit that
>  ISIS will  keep working on bridged networks of GE and other flavors
>  of Ethernet.
> 
>   I never understood why ISPs insisted on keeping ISIS to pad its hellos
>  to mtu-size. OSPF sends small hellos, and that does not seem to give
>  many more headaches.

	OSPF have the same problem. OSPF solves the problem by putting the 
MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable to put a TLV in 
IIH to carry the MTU instead of padding IIH to full MTU size ?

- Derek

> 
>      henk.
> 
> --
> PS.(*) I know this terminology is not the proper lingo anymore. If you know
> how to call those 2 encapsulation methods, please educate me. Thanks.
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 26 20:03:30 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18512
	for <isis-archive@odin.ietf.org>; Tue, 26 Jun 2001 20:03:29 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA24482;
	Tue, 26 Jun 2001 17:03:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA24470
	for <isis-wg@spider.juniper.net>; Tue, 26 Jun 2001 17:02:11 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5QNwPw12102
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 16:58:25 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id RAA16294;
	Tue, 26 Jun 2001 17:06:18 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <15919150156.20010626170618@nexsi.com>
To: Derek Yeung <myeung@procket.com>
CC: Henk Smit <henk@procket.com>,
        Anders Lowinger <anders.lowinger@xelerated.com>, <isis-wg@juniper.net>
Subject: Re: SV: [Isis-wg] More vendor data on IP/GigE MTU
In-Reply-To: <3B391A4D.2492FF7E@procket.com>
References: <200106262310.f5QNA9U28078@redd3174.procket.com>
 <3B391A4D.2492FF7E@procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 26 Jun 2001 17:06:18 -0700
Content-Transfer-Encoding: 7bit


I like Derek's suggestion.

On the other hand, (and I do know option 3 has been beaten
to death), using IP encapsulation solves this problem in
a "natural" way, i.e., routing traffic follows the path
of transit traffic. As an additional benefit, this will
solve the problem of an ISIS adjacency staying up (and thus
attracting transit traffic) even though IP processing of
the box (or a line card) has gone south.

Alex.

>>   Possible solutions:
>>  1) Change ethernet specs.
>>  2) Make IS-IS use EthernetII encapsulation.
>>  3) Make IS-IS use IP encapsulation.
>>  4) Forget about padding IS-IS hellos to mtu-size.
>> 
>>   It seems proposal 1) encountered more opposition than envisioned. :-)
>>  Proposals 2) and 3) are gonna introduce lots and lots of interoperability
>>  problems. Not worthwile, IMHO.
>> 
>>   Doing 4) seems a nice and simple solution. And it has the benefit that
>>  ISIS will  keep working on bridged networks of GE and other flavors
>>  of Ethernet.
>> 
>>   I never understood why ISPs insisted on keeping ISIS to pad its hellos
>>  to mtu-size. OSPF sends small hellos, and that does not seem to give
>>  many more headaches.

>         OSPF have the same problem. OSPF solves the problem by putting the 
> MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable to put a TLV in 
> IIH to carry the MTU instead of padding IIH to full MTU size ?

> - Derek


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 26 21:27:57 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09230
	for <isis-archive@odin.ietf.org>; Tue, 26 Jun 2001 21:27:55 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA24886;
	Tue, 26 Jun 2001 18:28:12 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA24874
	for <isis-wg@spider.juniper.net>; Tue, 26 Jun 2001 18:27:10 -0700 (PDT)
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5R1NIw14468
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 18:23:23 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from redback.com (prz-laptop.redback.com [155.53.36.102])
	by prattle.redback.com (Postfix) with ESMTP
	id 0DD5A26BD07; Tue, 26 Jun 2001 18:24:42 -0700 (PDT)
Message-ID: <3B3931DC.5366A3E0@redback.com>
From: Tony Przygienda <prz@redback.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Henk Smit <henk@procket.com>
Cc: Anders Lowinger <anders.lowinger@xelerated.com>, isis-wg@juniper.net
Subject: Re: SV: [Isis-wg] More vendor data on IP/GigE MTU
References: <200106262310.f5QNA9U28078@redd3174.procket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 26 Jun 2001 18:07:41 -0700
Content-Transfer-Encoding: 7bit

Henk Smit wrote:

> > Back to ISIS, do we really need LSP datagrams with sizes over 1492?
>
>   No, ISIS doesn't need larger LSPs.
>
>   Possible solutions:
>  1) Change ethernet specs.
>  2) Make IS-IS use EthernetII encapsulation.
>  3) Make IS-IS use IP encapsulation.
>  4) Forget about padding IS-IS hellos to mtu-size.
>

> Proposals 2) and 3) are gonna introduce lots and lots of interoperability
>  problems.

agreed for 2), for 3) I think you're exaggerating. I still think long-term
that
will take care of quite some problems that a lot of hacks are being invented
to
get around today. I remember the e-mail exchange and don't care to rehash all
the
arguments again. Let's just wait till time is ripe (and I know, it may be
never ;-)

> Not worthwile, IMHO.
>
>   Doing 4) seems a nice and simple solution. And it has the benefit that
>  ISIS will  keep working on bridged networks of GE and other flavors
>  of Ethernet.  I never understood why ISPs insisted on keeping ISIS to pad
> its hellos

>  to mtu-size. OSPF sends small hellos, and that does not seem to give
>  many more headaches.

Some vendors feel strongly (maybe there was some marketing brain-washing that
caused that, don't know) that it's a desirable feature to detect
MTU mismatches and
broken equipment loosing last 2-3 bytes and such jazz.

I like Derek proposal and  I think that a TLV is easily added for that purpose
... That will
not diagnose broken equipment that looses the last bytes but it will take care
of
misconfiguration.

And yes, for the list,
most modern implementations allow to squelch off the padding to mtu-size
as people probably know.

    thanks

    -- tony


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 26 22:17:28 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26527
	for <isis-archive@odin.ietf.org>; Tue, 26 Jun 2001 22:17:27 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA25162;
	Tue, 26 Jun 2001 19:19:12 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA25071
	for <isis-wg@spider.juniper.net>; Tue, 26 Jun 2001 19:02:45 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5R1wvw15272
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 18:58:57 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from bcn.East.Sun.COM ([129.148.75.4])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA26468
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 20:00:19 -0600 (MDT)
Received: from bcn (bcn [129.148.75.4])
	by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id WAA02503
	for <isis-wg@juniper.net>; Tue, 26 Jun 2001 22:00:20 -0400 (EDT)
Message-Id: <200106270200.WAA02503@bcn.East.Sun.COM>
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Subject: Re: SV: [Isis-wg] More vendor data on IP/GigE MTU
To: isis-wg@juniper.net
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: LnH7lwUXkcQ7cKYDE1N6pg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc 
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 26 Jun 2001 22:00:20 -0400 (EDT)

Apologies in advance...I'm behind on email and haven't been
following this thread, so I hope I'm not duplicating what
someone else said.


>>Re: Why pad to full MTU size?

I vaguely remember the reason was that although you might think you're
on the same link as your neighbor, you might have bridges bridging
your packet over a sub-link with a smaller packet size. So the only
way to tell if you really can send a packet as big as you think you
can is to send such a big packet. Telling your neighbor "I can send
4000 byte packets" because you're on FDDI, and he's on FDDI, won't work
if the bridged path between you contains an Ethernet with MTU 1500.

I vaguely remember another reason was that someone told me that some
links have failure modes where small packets go through OK but
big ones don't, so you don't want to bring up the adjancency
if the link is that flaky.

Radia

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Tue Jun 26 22:27:55 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00325
	for <isis-archive@odin.ietf.org>; Tue, 26 Jun 2001 22:27:55 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA25231;
	Tue, 26 Jun 2001 19:29:11 -0700 (PDT)
Received: from magenta.juniper.net (magenta.juniper.net [172.17.28.122])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA25219
	for <isis-wg@spider.juniper.net>; Tue, 26 Jun 2001 19:28:33 -0700 (PDT)
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57])
	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id f5R2Q8J78255;
	Tue, 26 Jun 2001 19:26:08 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id TAA24834; Tue, 26 Jun 2001 19:26:07 -0700 (PDT)
Message-Id: <200106270226.TAA24834@cirrus.juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: henk@Procket.com
CC: anders.lowinger@xelerated.com, isis-wg@juniper.net
In-reply-to: <200106262310.f5QNA9U28078@redd3174.procket.com> (message from
	Henk Smit on Tue, 26 Jun 2001 16:10:09 -0700 (PDT))
Subject: Re: SV: [Isis-wg] More vendor data on IP/GigE MTU
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Tue, 26 Jun 2001 19:26:07 -0700 (PDT)

For what it's worth, we only pad to the max LSP size (1492) since that's
really all the padding is trying to accomplish (detecting links too small
to carry some of the LSPs.)  In all of the years I've been working with
ISIS, the padding has shown no obvious operational benefit, but has
created countless problems (anybody remember FDDI/Ethernet bridges?)

MTU mismatch detection is best handled as a more straightforward extension,
if anybody really cares.


--Dave

   X-JNPR-Received-From: outside
   From: Henk Smit <henk@Procket.com>
   X-Confidential: Procket Confidential/Need to know
   Cc: isis-wg@juniper.net
   X-Mailer: ELM [version 2.5 PL3]
   MIME-Version: 1.0
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit
   Sender: isis-wg-admin@spider.juniper.net
   Errors-To: isis-wg-admin@spider.juniper.net
   X-BeenThere: isis-wg@external.juniper.net
   X-Mailman-Version: 2.0rc1
   Precedence: bulk
   List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
   List-Post: <mailto:isis-wg@external.juniper.net>
   List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:isis-wg-request@external.juniper.net?subject=subscribe>
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
   List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
   Date: Tue, 26 Jun 2001 16:10:09 -0700 (PDT)


   > Back to ISIS, do we really need LSP datagrams with sizes over 1492?

     No, ISIS doesn't need larger LSPs.

     The problem was this:
    *) Some router vendors support "jumboframes" over GE.
    *) IP packets are encapsulated in EthernetII frames. (*)
    *) Encapsulation of EthernetII frames in such jumboframes is easy.
    *) ISIS sends hellos padded to mtu size, to do early detection
       of mtu mismatches, and other problems.
    *) Some ISPs wanted this early detection to keep working even over
       GE with jumboframes.
    *) Therefor, ISIS must send hellos padded up to "jumboframe mtu"
    *) ISIS packets are encapsulated in 802.3/802.2 frames. (*)
    *) 802.3/802.2 frames can not be longer than 1500 bytes.
    *) Therefor ISIS can not use jumboframes.
    *) To solve this problem (and IMHO only this problem of padded hellos)
       draft-ietf-isis-ext-eth-00.txt was written.

     Possible solutions:
    1) Change ethernet specs.
    2) Make IS-IS use EthernetII encapsulation.
    3) Make IS-IS use IP encapsulation.
    4) Forget about padding IS-IS hellos to mtu-size.

     It seems proposal 1) encountered more opposition than envisioned. :-)
    Proposals 2) and 3) are gonna introduce lots and lots of interoperability
    problems. Not worthwile, IMHO.

     Doing 4) seems a nice and simple solution. And it has the benefit that
    ISIS will  keep working on bridged networks of GE and other flavors
    of Ethernet.

     I never understood why ISPs insisted on keeping ISIS to pad its hellos
    to mtu-size. OSPF sends small hellos, and that does not seem to give
    many more headaches.

	henk.

   --
   PS.(*) I know this terminology is not the proper lingo anymore. If you know
   how to call those 2 encapsulation methods, please educate me. Thanks.
   _______________________________________________
   Isis-wg mailing list  -  Isis-wg@external.juniper.net
   http://external.juniper.net/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 27 10:41:21 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03359
	for <isis-archive@odin.ietf.org>; Wed, 27 Jun 2001 10:41:20 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA28248;
	Wed, 27 Jun 2001 07:42:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA28236
	for <isis-wg@spider.juniper.net>; Wed, 27 Jun 2001 07:41:02 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5REb8w30339
	for <isis-wg@juniper.net>; Wed, 27 Jun 2001 07:37:09 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.extremenetworks.com (mosquito [10.30.20.240])
	by gnat.inet.org (Postfix) with ESMTP id 667E38266E
	for <isis-wg@juniper.net>; Wed, 27 Jun 2001 10:38:12 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010627102922.01f5ac60@10.30.15.2>
X-Sender: rja@nowhere (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: isis-wg@juniper.net
From: Ran Atkinson <rja@extremenetworks.com>
In-Reply-To: <3B391A4D.2492FF7E@procket.com>
References: <200106262310.f5QNA9U28078@redd3174.procket.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [Isis-wg] Derek's proposal for MTU discovery in IS-IS
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 27 Jun 2001 10:34:13 -0400


        Henk's historical analysis is extremely helpful.
I hope we are all now focused on the problem at hand.
Thanks much for the detailed analysis and history.

At 19:27 26/06/01, Derek Yeung wrote:
>        OSPF have the same problem. OSPF solves the problem by putting the 
>MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable 
>to put a TLV in IIH to carry the MTU instead of padding IIH to full 
>MTU size ?

        This seems like a simpler approach.  The concept is known to
work (thanks to OSPF).  Why don't we just try this to solve the
immediate IS-IS issue that Henk outlined ?  Oh, and if we do this,
it might not hurt to add a MIB object or two to make MTU mismatches
discovered by IS-IS easy for operators to grab via SNMP.

        Quite separately, I'll probably draft up an "IP over
Jumbogram Ethernet-II Framing" spec that just documents the
as deployed IP/Ethernet practice, as an Informational RFC.  I don't 
see that as an IS-IS WG work item, in no small part because IS-IS 
does not use Ethernet-II Framing.  

Cheers,

Ran
rja@inet.org



_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 27 12:13:17 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01831
	for <isis-archive@odin.ietf.org>; Wed, 27 Jun 2001 12:13:16 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA28663;
	Wed, 27 Jun 2001 09:14:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA28651
	for <isis-wg@spider.juniper.net>; Wed, 27 Jun 2001 09:13:14 -0700 (PDT)
Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5RG9Kw34339
	for <isis-wg@juniper.net>; Wed, 27 Jun 2001 09:09:20 -0700 (PDT)
X-JNPR-Received-From: outside
Message-ID: <EB5FFC72F183D411B3820006295734296AF11E@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Ran Atkinson'" <rja@extremenetworks.com>
Cc: "'isis-wg@juniper.net'" <isis-wg@juniper.net>
Subject: RE: [Isis-wg] Derek's proposal for MTU discovery in IS-IS
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 27 Jun 2001 12:10:34 -0400


> it might not hurt to add a MIB object or two to make MTU mismatches
> discovered by IS-IS easy for operators to grab via SNMP.

Ran - 
	Would a counter in the Circuit table help?
Something along the lines of isisCircRejAdjs today?

- jeff parker
- MIB scribe
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Wed Jun 27 16:09:57 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25121
	for <isis-archive@odin.ietf.org>; Wed, 27 Jun 2001 16:09:56 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA29648;
	Wed, 27 Jun 2001 13:11:11 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA29636
	for <isis-wg@spider.juniper.net>; Wed, 27 Jun 2001 13:10:25 -0700 (PDT)
Received: from redcs1.procket.com (flowpoint.procket.com [209.140.237.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5RK6Uw45555
	for <isis-wg@juniper.net>; Wed, 27 Jun 2001 13:06:30 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from tli@localhost)
	by redcs1.procket.com (8.9.3/8.9.3) id NAA05699;
	Wed, 27 Jun 2001 13:07:56 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redcs1.procket.com: tli set sender to tli@redcs1.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15162.15644.474511.856119@redcs1.procket.com>
To: isis-wg@juniper.net
X-Mailer: VM 6.92 under Emacs 20.5.1
Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Wed, 27 Jun 2001 13:07:56 -0700
Content-Transfer-Encoding: 7bit


Folks,

It's equally been forever on this draft as well, but we WOULD appreciate it
if you could look it over again.  It's been submitted as a revised ID.  If
we could get comments in by the end of next week, please.  Assuming that
there are no objections, we will push this forward to Informational.

Ran & Tony



======================================================================


Network Working Group                                                 Tony Li
INTERNET DRAFT                                               Procket Networks
draft-ietf-isis-hmac-03.txt                                       RJ Atkinson
                                                             Extreme Networks
                                                                 20 June 2001




                   IS-IS Cryptographic Authentication






STATUS OF THIS MEMO

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

ABSTRACT

      This document describes the authentication of IS-IS PDUs using the
   HMAC-MD5 algorithm [1].  IS-IS is specified in [2],  with  extensions
   to support IPv4 described in [3].  The base specification includes an
   authentication mechanism  that  allows  for  multiple  authentication
   algorithms.   The base specification only specifies the algorithm for
   cleartext passwords.

        This document proposes an extension to that  specification  that
   allows the use of the HMAC-MD5 authentication algorithm to be used in
   conjunction with the existing authentication mechanisms.





Li & Atkinson              Expires in 6 months               [Page 1]

Internet Draft            IS-IS Authentication              20 June 2001


1. Introduction

        The IS-IS protocol, as specified in ISO 10589, provides for  the
   authentication  of  Link  State  PDUs (LSPs) through the inclusion of
   authentication information as part of the LSP.   This  authentication
   information is encoded as a Type-Length-Value (TLV) tuple.

        The  type  of the TLV is specified as 10.  The length of the TLV
   is variable.  The value of the  TLV  depends  on  the  authentication
   algorithm  and  related  secrets  being used.  The first octet of the
   value is  used  to  specify  the  authentication  type.   Type  0  is
   reserved, type 1 indicates a cleartext password, and type 255 is used
   for routing domain private authentication methods.  The remainder  of
   the TLV value is known as the Authentication Value.

        This  document  extends  the above situation by allocating a new
   authentication type for HMAC-MD5 and specifying  the  algorithms  for
   the  computation  of  the  Authentication  Value.  This document also
   describes modifications to the  base  protocol  to  insure  that  the
   authentication mechanisms described in this document are effective.

      This  document  is a publication of the IS-IS Working Group within
   the IETF, and is a contribution to ISO  IEC  JTC1/SC6,  for  eventual
   inclusion with ISO 10589.



2. Authentication Procedures

        The  authentication  type  used  for HMAC-MD5 is 54 (0x36).  The
   length of the Authentication Value for HMAC-MD5 is 16, and the length
   field in the TLV is 17.

        The  HMAC-MD5  algorithm  requires  a key K and text T as input.
   The key K is the password for the  PDU  type,  as  specified  in  ISO
   10589.   The  text  T  is  the  PDU  to  be  authenticated  with  the
   Authentication Value field inside of the  Authentication  Information
   TLV  set to zero.  Note that the Authentication Type is set to 54 and
   the length of the TLV is set to 17 before authentication is computed.
   When  LSPs  are  authenticated,  the  Checksum and Remaining Lifetime
   fields are set to zero (0) before authentication  is  computed.   The
   result  of the algorithm is placed in the Authentication Value field.

        When calculating the HMAC-MD5 result for  Sequence  Number  PDUs
   and IS-IS HELLO PDUs, Level 1 Sequence Number PDUs SHALL use the Area
   Authentication string as  in  Level  1  Link  State  PDUs.   Level  2
   Sequence Number PDUs shall use the domain authentication string as in
   Level 2 Link State PDUs.  IS-IS HELLO PDUs SHALL use the  Link  Level



Li & Atkinson              Expires in 6 months               [Page 2]

Internet Draft            IS-IS Authentication              20 June 2001


   Authentication String, which MAY be different from that of Link State
   PDUs.  The  HMAC-MD5  result  for  the  IS-IS  HELLO  PDUs  SHALL  be
   calculated  after the Packet is padded to the MTU size, if padding is
   not disabled.  Implementations that support the optional checksum for
   the  Sequence  Number  PDUs and IS-IS HELLO PDUs MUST NOT include the
   Checksum TLV.

      An implementation  that  implements  HMAC-MD5  authentication  and
   receives  HMAC-MD5 Authentication Information MUST discard the PDU if
   the Authentication Value is incorrect.

      An implementation MAY include HMAC-MD5 Authentication  Information
   in  PDUs even if it does not fully implement HMAC-MD5 authentication.
   This allows an implementation to generate authentication  information
   without   verifying   the  authentication  information.   This  is  a
   transition  aid  for   networks   in   the   process   of   deploying
   authentication.

      An  implementation MAY check a set of passwords when verifying the
   Authentication Value.  This provides a  mechanism  for  incrementally
   changing passwords in a network.

      An  implementation that does not implement HMAC-MD5 authentication
   MAY accept a PDU that  contains  the  HMAC-MD5  Authentication  Type.
   ISes  (routers)  that  implement HMAC-MD5 authentication and initiate
   LSP purges MUST remove the body of the LSP and add the authentication
   TLV.   ISes  implementing  HMAC-MD5  authentication  MUST  NOT accept
   unauthenticated purges.  ISes MUST NOT  accept  purges  that  contain
   TLVs  other  than  the  authentication  TLV.   These restrictions are
   necessary to prevent a hostile system from receiving an LSP,  setting
   the  Remaining  Lifetime  field  to  zero,  and  flooding it, thereby
   initiating a purge without knowing the authentication password.

2.1 Implementation Considerations

        There is an implementation issue just after password rollover on
   an  IS-IS  router  that  might  benefit  from  additional commentary.
   Immediately after password rollover on the router, the router or  IS-
   IS  process  may  restart.   If  this  happens,  this  causes the LSP
   Sequence Number restarts from the value 1  using  the  new  password.
   However,  neighbors  will  reject those new LSPs because the Sequence
   Number is smaller.  The router can not increase its own LSP  Sequence
   Number  because  it  fails  to  authenticate  its  own  old  LSP that
   neighbors keep sending to it.  So the router can not update  its  LSP
   Sequence Number to its neighbors until all the neighbors time out all
   of the original LSPs.  One possible solution to this problem  is  for
   the IS-IS process to detect if any inbound LSP with an authentication
   failure has the local System ID and also has a higher Sequence Number



Li & Atkinson              Expires in 6 months               [Page 3]

Internet Draft            IS-IS Authentication              20 June 2001


   than  the IS-IS process has.  In this event, the IS-IS process SHOULD
   increase its own LSP Sequence Number  accordingly  and  re-flood  the
   LSPs.  However, as this scenario could also be triggered by an active
   attack by an adversary, it is recommended that a counter also be kept
   on this case to mitigate the risk from such an active attack.



3. Security Considerations

        This  document  enhances  the  security  of  the  IS-IS  routing
   protocol.  Because a routing protocol contains information that  need
   not   be  kept  secret,  privacy  is  not  a  requirement.   However,
   authentication of the messages within the protocol is of interest, to
   reduce  the  risk  of an adversary compromising the routing system by
   deliberately injecting false information into the routing system.

        The technology  in  this  document  provides  an  authentication
   mechanism for IS-IS.  The mechanism described here is not perfect and
   does not need to be perfect.  Instead, this  mechanism  represents  a
   significant  increase  in the work function of an adversary attacking
   the  IS-IS  protocol,  while  not   causing   undue   implementation,
   deployment, or operational complexity.

        This  mechanism  does  not  prevent replay attacks, however such
   attacks would trigger existing mechanisms in the IS-IS protocol  that
   would  effectively reject old information.  Denial of service attacks
   are not generally preventable in a useful networking protocol [4].

        Changes  to  the   authentication   mechanism   described   here
   (primarily: to add a Key-ID field such as OSPFv2 and RIPv2 have) were
   considered  at  some  length,  but  ultimately  were  rejected.   The
   mechanism  here  was  already widely implemented in 1999.  As of this
   writing, this mechanism is fairly widely deployed  within  the  users
   interested in cryptographic authentication of IS-IS.  The improvement
   provided by the proposed revised mechanism was not  large  enough  to
   justify  the  change,  given  the installed base and lack of operator
   interest in deploying the proposed revised mechanism.

        If and when a key  management  protocol  appears  that  is  both
   widely  implemented  and  easily deployed to secure routing protocols
   such as IS-IS, a different authentication mechanism that is  designed
   for use with that key management schema could be added if desired.

        If  a stronger authentication were believed to be required, then
   the use of a full digital signature [5] would  be  an  approach  that
   should  be seriously considered.  It was rejected for this purpose at
   this time because the computational burden of full digital signatures



Li & Atkinson              Expires in 6 months               [Page 4]

Internet Draft            IS-IS Authentication              20 June 2001


   is  believed  to  be much higher than is reasonable given the current
   threat environment in operational commercial networks.

ACKNOWLEDGMENTS

        The author would like  to  thank  (in  alphabetical  order)  Ran
   Atkinson,  Dave  Katz, Steven Luong, Tony Pryzygienda, Nai-Ming Shen,
   and Henk Smit for their comments and suggestions on this document.

REFERENCES

   [1] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed-Hashing for Message
   Authentication", RFC-2104, February 1997

   [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routing
   Exchange Protocol for use in Conjunction with the Protocol for Providing
   the Connectionless-mode Network Service (ISO 8473)", International Standard
   10589 [Also republished as RFC 1142].

   [3] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual
   environments", RFC-1195, December 1990.

   [4] V.L. Voydock & S. T. Kent, "Security Mechanisms in High-level
   Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

   [5] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital Signatures",
   RFC-2154, June 1997.

Author's Address

   Tony Li
   Procket Networks
   1100 Cadillac Ct.
   Milpitas, California
   95035  USA

   Email: tli@procket.net
   Phone: +1 (408) 635-7903

   RJ Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA
   95051  USA

   Email: rja@extremenetworks.com
   Phone: +1 (408) 579-2800




Li & Atkinson              Expires in 6 months               [Page 5]

Internet Draft            IS-IS Authentication              20 June 2001





















































Li & Atkinson              Expires in 6 months               [Page 6]

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Thu Jun 28 17:57:02 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11738
	for <isis-archive@odin.ietf.org>; Thu, 28 Jun 2001 17:57:01 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA35779;
	Thu, 28 Jun 2001 14:58:12 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA35767
	for <isis-wg@spider.juniper.net>; Thu, 28 Jun 2001 14:57:52 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5SLrkw95092
	for <isis-wg@juniper.net>; Thu, 28 Jun 2001 14:53:46 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id PAA02448;
	Thu, 28 Jun 2001 15:01:57 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <139736780.20010628150155@nexsi.com>
To: Tony Li <tli@procket.com>
CC: isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <15162.15644.474511.856119@redcs1.procket.com>
References: <15162.15644.474511.856119@redcs1.procket.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------618D80177E8F1"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Thu, 28 Jun 2001 15:01:55 -0700

------------618D80177E8F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


After some discussion with tli, I quickly drafted a small
document (attached) that addresses some nasty replay attacks not
covered by the HMAC doc. The intention is to see if people
interested in ISIS authentication care about this stuff
at all. If there's enough interest, I'll beautify the text
and we can make it a separate WG item.

Another point for discussion---it may be a good idea to say
that the implementations must put the Auth TLV in the beginning
of the packet. This way we can drop attacker's packets and
authenticate valid ones faster (we don't have to parse the whole
thing). This, of course, will work only if the current
implementations already do so, which I'm not 100% sure about,
so more clue is welcome.

Cheers,

-- 
Alex Zinin

Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote:


> Folks,

> It's equally been forever on this draft as well, but we WOULD appreciate it
> if you could look it over again.  It's been submitted as a revised ID.  If
> we could get comments in by the end of next week, please.  Assuming that
> there are no objections, we will push this forward to Informational.

> Ran & Tony
------------618D80177E8F1
Content-Type: text/plain; name="draft-ietf-isis-auth-anti-replay-00.txt"
Content-Disposition: attachment; filename="draft-ietf-isis-auth-anti-replay-00.txt"
Content-Transfer-Encoding: base64

CgoKCgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBBbGV4IFppbmluCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTmV4c2kgU3lzdGVtcwpFeHBpcmF0aW9uIERhdGU6IERl
Y2VtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDEKRmls
ZSBuYW1lOiBkcmFmdC1pZXRmLWlzaXMtYXV0aC1hbnRpLXJlcGxheS0wMC50eHQKCgogICAgICAg
ICAgICAgICAgICBQcm90ZWN0aW5nIElTSVMgZnJvbSByZXBsYXkgYXR0YWNrcwoKICAgICAgICAg
ICAgICAgIGRyYWZ0LWlldGYtaXNpcy1hdXRoLWFudGktcmVwbGF5LTAwLnR4dAoKClN0YXR1cyBv
ZiB0aGlzIE1lbW8KCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlz
IGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aAogICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEw
IG9mIFJGQzIwMjYuCgogICBJbnRlcm5ldCBEcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m
IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIEFyZWFz
LCBhbmQgaXRzIFdvcmtpbmcgR3JvdXBzLiBOb3RlIHRoYXQgb3RoZXIKICAgZ3JvdXBzIG1heSBh
bHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQgRHJhZnRzLgoKICAg
SW50ZXJuZXQgRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv
ZiBzaXgKICAgbW9udGhzLiBJbnRlcm5ldCBEcmFmdHMgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk
LCBvciBvYnNvbGV0ZWQgYnkKICAgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBu
b3QgYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0CiAgIERyYWZ0cyBhcyByZWZlcmVuY2UgbWF0
ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgYSAid29ya2luZwogICBkcmFmdCIg
b3IgIndvcmsgaW4gcHJvZ3Jlc3MiLgoKICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1E
cmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQt
YWJzdHJhY3RzLnR4dAoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj
dG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o
dG1sLgoKCkFic3RyYWN0CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFkZGl0aW9uYWwg
bWVjaGFuaXNtIGZvciBJU0lTCiAgIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24gdGhhdCBw
cm90ZWN0cyBuZXR3b3JrcyBydW5uaW5nIElTSVMgZnJvbQogICBzaW1wbGUgcGFja2V0IHJlcGxh
eSBhdHRhY2tzLgoKMSBNb3RpdmF0aW9uCgogICBUaGUgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNh
dGlvbiBtZWNoYW5pc20gZm9yIFtJU0lTXSwgZGVzY3JpYmVkIGluCiAgIFtITUFDXSBwcm92aWRl
cyBiYXNpYyBhdXRoZW50aWNhdGlvbiBmdW5jdGlvbmFsaXR5IHN1ZmZpY2llbnQgZm9yIHRoZQog
ICBtYWpvcml0eSBvZiBzaXR1YXRpb25zLiBIb3dldmVyLCB0aGlzIG1lY2hhbmlzbSBkb2VzIG5v
dCBwcm90ZWN0IElTSVMKICAgbmV0d29ya3MgZnJvbSB0aGUgcmVwbGF5IGF0dGFja3MgdGhhdCBj
YW4gYmUgcGVyZm9ybWVkIGJ5IHRoZQogICBhdHRhY2tlciBpZiBpdCBoYXMgZGlyZWN0IGFjY2Vz
cyB0byBhIGJyb2FkY2FzdCBzZWdtZW50IHJ1bm5pbmcgSVNJUy4KCiAgIEJlY2F1c2UgdGhlIG1l
Y2hhbmlzbSBkZXNjcmliZWQgaW4gW0hNQUNdIGRvZXMgbm90IGluY2x1ZGUgdGhlIG5vdGlvbgog
ICBvZiAiY3J5cHRvZ3JhcGhpYyBzZXF1ZW5jZSBudW1iZXIiLCBhbiBhdHRhY2tlciBjYW4gZWFz
aWx5IHJlcGxheQoKCgpaaW5pbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KCgoKCgpJTlRFUk5FVCBEUkFGVCAgICAgUHJv
dGVjdGluZyBJU0lTIGZyb20gcmVwbGF5IGF0dGFja3MgICAgICAgICBKdW5lIDIwMDEKCgogICBy
ZWNvcmRlZCBJU0lTIHBhY2tldHMuCgogICBFeGFtcGxlcyBvZiB0aGVzZSBhdHRhY2tzIGluY2x1
ZGUgcmVwbGF5aW5nIGFuIGVtcHR5IChsaXN0aW5nIG5vCiAgIG5laWdoYm9yIElTKSBJSUggcGFj
a2V0cyBhbmQgdGh1cyBjYXVzaW5nIHJvdXRlcnMgb24gdGhlIHNlZ21lbnQgdG8KICAgZGVzdHJv
eSB0aGUgYWRqYWNlbmNpZXMgd2l0aCB0aGUgcm91dGVyIHVuZGVyIGF0dGFjaywgcmVwbGF5aW5n
IENTTlAKICAgcGFja2V0cyBhbmQgdGh1cyBhcnRpZmljYWxseSBhdHRyYWN0aW5nIElTSVMgdHJh
ZmZpYyAoTFNQcykgdG8gdGhlCiAgIHNlZ21lbnQncyBESVMsIGFuZCBzbyBvbi4gV2hlbiB1c2Vk
IHBlcmlvZGljYWxseSwgdGhlc2UgYXR0YWNrcyBjYW4KICAgY2F1c2UgZ2xvYmFsIGluc3RhYmls
aXR5IGluIGFuIElTSVMgZG9tYWluLgoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2ltcGxl
IG1lY2hhbmlzbSwgc2ltaWxhciB0byB0aGUgb25lIHVzZWQgaW4KICAgdGhlIE9TUEYgcHJvdG9j
b2wsIHRvIHByb3RlY3QgYW4gSVNJUyBuZXR3b3JrIGZyb20gdGhlIHJlcGxheSBhdHRhY2tzCiAg
IGJ5IGludHJvZHVjaW5nIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UgbnVtYmVyIGludG8gSVNJUyBw
YWNrZXRzLiBUaGUKICAgbWV0aG9kIGlzIGNvbXBhdGlibGUgd2l0aCB0aGUgZXhzaXRpbmcgaW1w
bGVtZW50YXRpb25zIG9mIFtITUFDXS4KICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcm92aWRl
IGEgc29sdXRpb24gZm9yIHJlcGxheSBhdHRhY2tzIGJhc2VkIG9uCiAgIHRoZSBjcnlwdG9ncmFw
aGljIHNlcXVlbmNlIG51bWJlciByb2xsLW92ZXIuIFRoZSBhZG1pbmlzdHJhdG9yIGlzCiAgIHN1
cHBvc2VkIHRvIGNoYW5nZSB0aGUga2V5cyB0byBwcmV2ZW50IHRoaXMgdHlwZSBvZiBhdHRhY2tz
LgoKMiBQcm9wb3NlZCBTb2x1dGlvbgoKICAgVGhlIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UgbnVt
YmVyIGlmIGludHJvZHVjZWQgaW4gSVNJUyBwYWNrZXRzIGluCiAgIHRoZSBmb3JtIG9mIGEgbmV3
IFRMViB3aXRoIHRoZSB0eXBlIGNvZGUgPFRCRD4uIFRoZSBsZW5ndGggb2YgdGhlCiAgIFZhbHVl
IGZpZWxkIGluIHRoZSBUTFYgaXMgNCBieXRlcyAoMzIgYml0cykuIFRoZSB2YWx1ZSBvZiB0aGUg
TGVuZ3RoCiAgIGZpZWxkIGlzIDUuCgogICBUaGUgdmFsdWUgZmllbGQgb2YgdGhlIFRMViBjb250
YWlucyB0aGUgY3J5cHRvZ3JhcGhpYyBzZXF1ZW5jZQogICBudW1iZXIuCgogMi4xIFNlbmRpbmcg
SVNJUyBQYWNrZXRzIHdpdGggQ3J5cHRvZ3JhcGhpYyBTZXF1ZW5jZSBOdW1iZXIKCiAgIEltcGxl
bWVudGF0aW9ucyBzdXBwb3J0aW5nIHRoZSBleHRlbnNpb25zIGRlc2NyaWJlZCBpbiB0aGlzIGRv
Y3VtZW50CiAgIHNob3VsZCBtYWludGFpbiB0aGUgY3J5cHRvZ3JhcGhpYyBzZXF1ZW5jZSBudW1i
ZXIgY291bnRlciBvbiBhIHBlci0KICAgaW50ZXJmYWNlIGJhc2lzLiBJbXBsZW1lbnRhdGlvbnMg
bWF5IHVzZSB0aGUgdXAtdGltZSB0aW1lciwgb3IKICAgaW5pdGlhbGl6ZSB0aGUgY291bnRlciB3
aXRoIGEgemVybyB2YWx1ZSBhbmQgaW5jcmVtZW50IGl0IGFmdGVyCiAgIHNlbmRpbmcgZWFjaCBw
YWNrZXQgb24gdGhlIGludGVyZmFjZS4gVGhlIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UKICAgbnVt
YmVyIHJvbGwtb3ZlciBwcm9jZWR1cmUgaXMgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4K
CiAgIFdoZW4gY29uc3RydWN0aW5nIGFuIElTSVMgcGFja2V0IGF1dGhlbnRpY2F0ZWQgdXNpbmcg
W0hNQUNdLCB0aGUKICAgcm91dGVyIG1heSBpbmNsdWRlIHRoZSBjcnlwdG9ncmFwaGljIHNlcXVl
bmNlIG51bWJlciBUTFYgaW4gaXQuIElmCiAgIHRoZSBUTFYgaXMgaW5jbHVkZWQsIGl0IHNob3Vs
ZCBiZSBjb25zaWRlcmVkIGEgcGFydCBvZiB0aGUgdGV4dCBmb3IKICAgdGhlIGRpZ2VzdCBjYWxj
dWxhdGlvbi4KCiAyLjMgUmVjZWl2aW5nIElTSVMgUGFja2V0cyB3aXRoIENyeXB0b2dyYXBoaWMg
U2VxdWVuY2UgTnVtYmVyCgogICBJU0lTIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0aW5nIGRlc2Ny
aWJlZCBleHRlbnNpb25zIHNob3VsZCBtYWludGFpbgogICB0aGUgcmVjZWl2ZWQgY3J5cHRvZ3Jh
cGhpYyBzZXF1ZW5jZSBudW1iZXIgb24gYSBwZXItbmVpZ2hib3IgYmFzaXMuCgogICBXaGVuIHJl
Y2VpdmluZyBhdXRoZW50aWNhdGVkIElTSVMgcGFja2V0cywgdGhlIHJvdXRlciBwZXJmb3JtcyB0
aGUKICAgZm9sbG93aW5nIGNoZWNrcy4KCgoKWmluaW4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgoKCgoKSU5URVJORVQg
RFJBRlQgICAgIFByb3RlY3RpbmcgSVNJUyBmcm9tIHJlcGxheSBhdHRhY2tzICAgICAgICAgSnVu
ZSAyMDAxCgoKICAgIDEuIElmIHRoZSBjcnlwdG9ncmFwaGljIHNlcXVlbmNlIG51bWJlciBUTFYg
aXMgcHJlc2VudCBpbgogICAgICAgdGhlIHJlY2VpdmVkIHBhY2tldCwgY29tcGFyZSB0aGUgdmFs
dWUgZm91bmQgaW4gdGhlIFRMVgogICAgICAgd2l0aCB0aGUgdmFsdWUgaW4gdGhlIG5laWdoYm9y
IGRhdGEgc3RydWN0dXJlLiBJZiB0aGUKICAgICAgIHJlY2VpdmVkIHZhbHVlIGlzIGxlc3MgdGhh
biB0aGUgbG9jYWxseSByZWNvcmRlZCBvbmUsCiAgICAgICB0aGUgSVNJUyBwYWNrZXQgc2hvdWxk
IGJlIGlnbm9yZWQuIE90aGVyd2lzZSwgdGhlIHJvdXRlcgogICAgICAgc2hvdWxkIHBlcmZvcm0g
dGhlIHBhY2tldCB2ZXJpZmljYXRpb24gcHJvY2VkdXJlIGFzCiAgICAgICBkZXNjcmliZWQgaW4g
W0hNQUNdIGFuZCB1cGRhdGUgdGhlIG5laWdoYm9yIGRhdGEgc3RydWN0dXJlCiAgICAgICB3aXRo
IHRoZSByZWNlaXZlZCBjcnlwbyBzZXF1ZW5jZSBudW1iZXIuCgogICAgMi4gSWYgdGhlIElTSVMg
cGFja2V0IGlzIGF1dGhlbnRpY2F0ZWQgdXNpbmcgW0hNQUNdLCBkb2VzIG5vdAogICAgICAgY29u
dGFpbiB0aGUgY3J5cHRvIHNlcXVlbmNlIG51bWJlciBUTFYsIGFuZCB0aGUgcm91dGVyIGlzCiAg
ICAgICBjb25maWd1cmVkIHRvIHBlcmZvcm0gY3J5cHRvIHNlcXVlbmNlIG51bWJlciB2ZXJpZmlj
YXRpb24KICAgICAgIG9uIHRoZSByZWNlaXZpbmcgaW50ZXJmYWNlLCB0aGUgSVNJUyBwYWNrZXQg
c2hvdWxkIGJlIGlnbm9yZWQuCiAgICAgICBPdGhlcndpc2UgKHRoZSByb3V0ZXIgaXMgbm90IGNv
bmZpZ3VyZWQgdG8gcGVyZm9ybSB0aGlzCiAgICAgICB2ZXJpZmljYXRpb24pLCB0aGUgcGFja2V0
IHNob3VsZCBiZSBhdXRoZW50aWNhdGVkIGFzCiAgICAgICBkZXNjcmliZWQgaW4gW0hNQUNdLgoK
MyBDb21wYXRpYmlsaXR5IElzc3VlcwoKICAgSW1wbGVtZW50YXRpb25zIG5vdCBzdXBwb3J0aW5n
IGRlc2NyaWJlZCBleHRlbnNpb25zIHdpbGwgaWdub3JlIHRoZQogICBjcnlwdG9ncmFwaGljIHNl
cXVlbmNlIG51bWJlciBUTFYuIEFsc28sIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0aW5nCiAgIHRo
ZSBuZXcgVExWIHdpbGwgaW50ZXJvcGVyYXRlIHdpdGggaW1wbGVtZW50YXRpb24gdXNpbmcgW0hN
QUNdIG9ubHkKICAgdW5sZXNzIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0byBwZXJmb3JtIHNlcXVl
bmNlIG51bWJlciB2ZXJpZmljYXRpb24sCiAgIHdoaWNoIGlzIGV4cGVjdGVkIHRvIGJlIGRvbmUg
d2hlbiBhbGwgcm91dGVycyBvbiBhIHNlZ21lbnQgc3VwcG9ydAogICBkZXNjcmliZWQgbWVjaGFu
aXNtLgoKNCBTZWN1cml0eSBpc3N1ZXMKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVj
aGFuaXNtIHRoYXQgaW1wcm92ZXMgc2VjdXJpdHkgb2YgdGhlCiAgIElTSVMgcHJvdG9jb2wuCgo1
IEFja25vd2xlZGdlbWVudHMKCiAgIDxUQkQ+Cgo2IFJlZmVyZW5jZXMKCiAgIFtJU0lTXSBJU08s
ICJJbnRlcm1lZGlhdGUgc3lzdGVtIHRvIEludGVybWVkaWF0ZSBzeXN0ZW0gcm91dGVpbmcKICAg
ICAgICAgIGluZm9ybWF0aW9uIGV4Y2hhbmdlIHByb3RvY29sIGZvciB1c2UgaW4gY29uanVuY3Rp
b24gd2l0aCB0aGUKICAgICAgICAgIFByb3RvY29sIGZvciBwcm92aWRpbmcgdGhlIENvbm5lY3Rp
b25sZXNzLW1vZGUgTmV0d29yayBTZXJ2aWNlCiAgICAgICAgICAoSVNPIDg0NzMpLCIgSVNPL0lF
QyAxMDU4OToxOTkyLgoKICAgW0hNQUNdIExpLCBULiwgUkogQXRraW5zb24uICJJUy1JUyBDcnlw
dG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIgogICAgICAgICAgV29yayBpbiBwcm9ncmVzcy4gMjAg
SnVuZSAyMDAxLiBkcmFmdC1pZXRmLWlzaXMtaG1hYy0wMy50eHQuCgo3IEF1dGhvcnMnIGFkZHJl
c3NlcwoKICAgQWxleCBaaW5pbgoKCgpaaW5pbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10KCgoKCgpJTlRFUk5FVCBEUkFG
VCAgICAgUHJvdGVjdGluZyBJU0lTIGZyb20gcmVwbGF5IGF0dGFja3MgICAgICAgICBKdW5lIDIw
MDEKCgogICBOZXhzaSBTeXN0ZW1zCiAgIDE5NTkgQ29uY291cnNlIERyaXZlCiAgIFNhbiBKb3Nl
LCBDQSA5NTEzMQogICBhemluaW5AbmV4c2kuY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKWmluaW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgoK

------------618D80177E8F1--


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Thu Jun 28 18:46:10 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18197
	for <isis-archive@odin.ietf.org>; Thu, 28 Jun 2001 18:46:09 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA36090;
	Thu, 28 Jun 2001 15:48:12 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA36078
	for <isis-wg@spider.juniper.net>; Thu, 28 Jun 2001 15:47:59 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5SMhqw97010;
	Thu, 28 Jun 2001 15:43:52 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id PAA02986;
	Thu, 28 Jun 2001 15:52:09 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <16012749723.20010628155209@nexsi.com>
To: Hannes Gredler <hannes@juniper.net>
CC: Tony Li <tli@procket.com>, isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <20010629002937.A24703@juniper.net>
References: <15162.15644.474511.856119@redcs1.procket.com>
 <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Thu, 28 Jun 2001 15:52:09 -0700
Content-Transfer-Encoding: 7bit


Hannes,

 Thanks for the comment.

 Except for the savings on the TLV header, what would
 be the benefit? On the other hand, having a new TLV
 that is "covered" by the HMAC digest provides a nice
 transition behavior, i.e., those who don't know about
 it, just ignore it...

 BTW, there's a mistake in my draft---the Length field
 should be 4 bytes, not 5 :)

-- 
Alex Zinin

Thursday, June 28, 2001, 3:29:37 PM, Hannes Gredler wrote:

> alex,

> couldn't we use a different authentication subtype
> rather than a new TLV ?

> hmac-md5 uses id 54 so maybe 55 ?

> frame format would be 5 bytes of cryptograhic sequence #
> plus 16 bytes of MD5 hash. TLV [10] length is always 22.

> /hannes


> On Thu, Jun 28, 2001 at 03:01:55PM -0700, Alex Zinin wrote:
> | 
> | After some discussion with tli, I quickly drafted a small
> | document (attached) that addresses some nasty replay attacks not
> | covered by the HMAC doc. The intention is to see if people
> | interested in ISIS authentication care about this stuff
> | at all. If there's enough interest, I'll beautify the text
> | and we can make it a separate WG item.
> | 
> | Another point for discussion---it may be a good idea to say
> | that the implementations must put the Auth TLV in the beginning
> | of the packet. This way we can drop attacker's packets and
> | authenticate valid ones faster (we don't have to parse the whole
> | thing). This, of course, will work only if the current
> | implementations already do so, which I'm not 100% sure about,
> | so more clue is welcome.
> | 
> | Cheers,
> | 
> | -- 
> | Alex Zinin
> | 
> | Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote:
> | 
> | 
| >> Folks,
> | 
| >> It's equally been forever on this draft as well, but we WOULD appreciate it
| >> if you could look it over again.  It's been submitted as a revised ID.  If
| >> we could get comments in by the end of next week, please.  Assuming that
| >> there are no objections, we will push this forward to Informational.
> | 
| >> Ran & Tony
> | 
> | 
> | 
> | 
> | 
> | 
> | Network Working Group                                         Alex Zinin
> | Internet Draft                                             Nexsi Systems
> | Expiration Date: December 2001                                 June 2001
> | File name: draft-ietf-isis-auth-anti-replay-00.txt
> | 
> | 
> |                   Protecting ISIS from replay attacks
> | 
> |                 draft-ietf-isis-auth-anti-replay-00.txt
> | 
> | 
> | Status of this Memo
> | 
> |    This document is an Internet-Draft and is in full conformance with
> |    all provisions of Section 10 of RFC2026.
> | 
> |    Internet Drafts are working documents of the Internet Engineering
> |    Task Force (IETF), its Areas, and its Working Groups. Note that other
> |    groups may also distribute working documents as Internet Drafts.
> | 
> |    Internet Drafts are draft documents valid for a maximum of six
> |    months. Internet Drafts may be updated, replaced, or obsoleted by
> |    other documents at any time. It is not appropriate to use Internet
> |    Drafts as reference material or to cite them other than as a "working
> |    draft" or "work in progress".
> | 
> |    The list of current Internet-Drafts can be accessed at
> |    http://www.ietf.org/ietf/1id-abstracts.txt
> | 
> |    The list of Internet-Draft Shadow Directories can be accessed at
> |    http://www.ietf.org/shadow.html.
> | 
> | 
> | Abstract
> |    This document describes an additional mechanism for ISIS
> |    cryptographic authentication that protects networks running ISIS from
> |    simple packet replay attacks.
> | 
> | 1 Motivation
> | 
> |    The cryptographic authentication mechanism for [ISIS], described in
> |    [HMAC] provides basic authentication functionality sufficient for the
> |    majority of situations. However, this mechanism does not protect ISIS
> |    networks from the replay attacks that can be performed by the
> |    attacker if it has direct access to a broadcast segment running ISIS.
> | 
> |    Because the mechanism described in [HMAC] does not include the notion
> |    of "cryptographic sequence number", an attacker can easily replay
> | 
> | 
> | 
> | Zinin                                                           [Page 1]
> | 
> | 
> | 
> | 
> | 
> | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
> | 
> | 
> |    recorded ISIS packets.
> | 
> |    Examples of these attacks include replaying an empty (listing no
> |    neighbor IS) IIH packets and thus causing routers on the segment to
> |    destroy the adjacencies with the router under attack, replaying CSNP
> |    packets and thus artifically attracting ISIS traffic (LSPs) to the
> |    segment's DIS, and so on. When used periodically, these attacks can
> |    cause global instability in an ISIS domain.
> | 
> |    This document defines a simple mechanism, similar to the one used in
> |    the OSPF protocol, to protect an ISIS network from the replay attacks
> |    by introducing cryptographic sequence number into ISIS packets. The
> |    method is compatible with the exsiting implementations of [HMAC].
> |    This document does not provide a solution for replay attacks based on
> |    the cryptographic sequence number roll-over. The administrator is
> |    supposed to change the keys to prevent this type of attacks.
> | 
> | 2 Proposed Solution
> | 
> |    The cryptographic sequence number if introduced in ISIS packets in
> |    the form of a new TLV with the type code <TBD>. The length of the
> |    Value field in the TLV is 4 bytes (32 bits). The value of the Length
> |    field is 5.
> | 
> |    The value field of the TLV contains the cryptographic sequence
> |    number.
> | 
> |  2.1 Sending ISIS Packets with Cryptographic Sequence Number
> | 
> |    Implementations supporting the extensions described in this document
> |    should maintain the cryptographic sequence number counter on a per-
> |    interface basis. Implementations may use the up-time timer, or
> |    initialize the counter with a zero value and increment it after
> |    sending each packet on the interface. The cryptographic sequence
> |    number roll-over procedure is not defined in this document.
> | 
> |    When constructing an ISIS packet authenticated using [HMAC], the
> |    router may include the cryptographic sequence number TLV in it. If
> |    the TLV is included, it should be considered a part of the text for
> |    the digest calculation.
> | 
> |  2.3 Receiving ISIS Packets with Cryptographic Sequence Number
> | 
> |    ISIS implementations supporting described extensions should maintain
> |    the received cryptographic sequence number on a per-neighbor basis.
> | 
> |    When receiving authenticated ISIS packets, the router performs the
> |    following checks.
> | 
> | 
> | 
> | Zinin                                                           [Page 2]
> | 
> | 
> | 
> | 
> | 
> | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
> | 
> | 
> |     1. If the cryptographic sequence number TLV is present in
> |        the received packet, compare the value found in the TLV
> |        with the value in the neighbor data structure. If the
> |        received value is less than the locally recorded one,
> |        the ISIS packet should be ignored. Otherwise, the router
> |        should perform the packet verification procedure as
> |        described in [HMAC] and update the neighbor data structure
> |        with the received crypo sequence number.
> | 
> |     2. If the ISIS packet is authenticated using [HMAC], does not
> |        contain the crypto sequence number TLV, and the router is
> |        configured to perform crypto sequence number verification
> |        on the receiving interface, the ISIS packet should be ignored.
> |        Otherwise (the router is not configured to perform this
> |        verification), the packet should be authenticated as
> |        described in [HMAC].
> | 
> | 3 Compatibility Issues
> | 
> |    Implementations not supporting described extensions will ignore the
> |    cryptographic sequence number TLV. Also, implementations supporting
> |    the new TLV will interoperate with implementation using [HMAC] only
> |    unless explicitly configured to perform sequence number verification,
> |    which is expected to be done when all routers on a segment support
> |    described mechanism.
> | 
> | 4 Security issues
> | 
> |    This document describes a mechanism that improves security of the
> |    ISIS protocol.
> | 
> | 5 Acknowledgements
> | 
> |    <TBD>
> | 
> | 6 References
> | 
> |    [ISIS] ISO, "Intermediate system to Intermediate system routeing
> |           information exchange protocol for use in conjunction with the
> |           Protocol for providing the Connectionless-mode Network Service
> |           (ISO 8473)," ISO/IEC 10589:1992.
> | 
> |    [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication"
> |           Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt.
> | 
> | 7 Authors' addresses
> | 
> |    Alex Zinin
> | 
> | 
> | 
> | Zinin                                                           [Page 3]
> | 
> | 
> | 
> | 
> | 
> | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
> | 
> | 
> |    Nexsi Systems
> |    1959 Concourse Drive
> |    San Jose, CA 95131
> |    azinin@nexsi.com
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | Zinin                                                           [Page 4]
> | 
> | 


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 02:40:37 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25193
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 02:40:36 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA37975;
	Thu, 28 Jun 2001 23:42:13 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA35982
	for <isis-wg@spider.juniper.net>; Thu, 28 Jun 2001 15:32:26 -0700 (PDT)
Received: from ghostrider.gredler.at (ghostrider.gredler.at [193.83.223.228])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5SMSIw96491
	for <isis-wg@juniper.net>; Thu, 28 Jun 2001 15:28:18 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from hannes@localhost)
	by ghostrider.gredler.at (8.9.3/8.9.3) id AAA24719;
	Fri, 29 Jun 2001 00:29:37 +0200
From: Hannes Gredler <hannes@juniper.net>
To: Alex Zinin <azinin@nexsi.com>
Cc: Tony Li <tli@procket.com>, isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
Message-ID: <20010629002937.A24703@juniper.net>
References: <15162.15644.474511.856119@redcs1.procket.com> <139736780.20010628150155@nexsi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <139736780.20010628150155@nexsi.com>; from azinin@nexsi.com on Thu, Jun 28, 2001 at 03:01:55PM -0700
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 00:29:37 +0200

alex,

couldn't we use a different authentication subtype
rather than a new TLV ?

hmac-md5 uses id 54 so maybe 55 ?

frame format would be 5 bytes of cryptograhic sequence #
plus 16 bytes of MD5 hash. TLV [10] length is always 22.

/hannes


On Thu, Jun 28, 2001 at 03:01:55PM -0700, Alex Zinin wrote:
| 
| After some discussion with tli, I quickly drafted a small
| document (attached) that addresses some nasty replay attacks not
| covered by the HMAC doc. The intention is to see if people
| interested in ISIS authentication care about this stuff
| at all. If there's enough interest, I'll beautify the text
| and we can make it a separate WG item.
| 
| Another point for discussion---it may be a good idea to say
| that the implementations must put the Auth TLV in the beginning
| of the packet. This way we can drop attacker's packets and
| authenticate valid ones faster (we don't have to parse the whole
| thing). This, of course, will work only if the current
| implementations already do so, which I'm not 100% sure about,
| so more clue is welcome.
| 
| Cheers,
| 
| -- 
| Alex Zinin
| 
| Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote:
| 
| 
| > Folks,
| 
| > It's equally been forever on this draft as well, but we WOULD appreciate it
| > if you could look it over again.  It's been submitted as a revised ID.  If
| > we could get comments in by the end of next week, please.  Assuming that
| > there are no objections, we will push this forward to Informational.
| 
| > Ran & Tony
| 
| 
| 
| 
| 
| 
| Network Working Group                                         Alex Zinin
| Internet Draft                                             Nexsi Systems
| Expiration Date: December 2001                                 June 2001
| File name: draft-ietf-isis-auth-anti-replay-00.txt
| 
| 
|                   Protecting ISIS from replay attacks
| 
|                 draft-ietf-isis-auth-anti-replay-00.txt
| 
| 
| Status of this Memo
| 
|    This document is an Internet-Draft and is in full conformance with
|    all provisions of Section 10 of RFC2026.
| 
|    Internet Drafts are working documents of the Internet Engineering
|    Task Force (IETF), its Areas, and its Working Groups. Note that other
|    groups may also distribute working documents as Internet Drafts.
| 
|    Internet Drafts are draft documents valid for a maximum of six
|    months. Internet Drafts may be updated, replaced, or obsoleted by
|    other documents at any time. It is not appropriate to use Internet
|    Drafts as reference material or to cite them other than as a "working
|    draft" or "work in progress".
| 
|    The list of current Internet-Drafts can be accessed at
|    http://www.ietf.org/ietf/1id-abstracts.txt
| 
|    The list of Internet-Draft Shadow Directories can be accessed at
|    http://www.ietf.org/shadow.html.
| 
| 
| Abstract
|    This document describes an additional mechanism for ISIS
|    cryptographic authentication that protects networks running ISIS from
|    simple packet replay attacks.
| 
| 1 Motivation
| 
|    The cryptographic authentication mechanism for [ISIS], described in
|    [HMAC] provides basic authentication functionality sufficient for the
|    majority of situations. However, this mechanism does not protect ISIS
|    networks from the replay attacks that can be performed by the
|    attacker if it has direct access to a broadcast segment running ISIS.
| 
|    Because the mechanism described in [HMAC] does not include the notion
|    of "cryptographic sequence number", an attacker can easily replay
| 
| 
| 
| Zinin                                                           [Page 1]
| 
| 
| 
| 
| 
| INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| 
| 
|    recorded ISIS packets.
| 
|    Examples of these attacks include replaying an empty (listing no
|    neighbor IS) IIH packets and thus causing routers on the segment to
|    destroy the adjacencies with the router under attack, replaying CSNP
|    packets and thus artifically attracting ISIS traffic (LSPs) to the
|    segment's DIS, and so on. When used periodically, these attacks can
|    cause global instability in an ISIS domain.
| 
|    This document defines a simple mechanism, similar to the one used in
|    the OSPF protocol, to protect an ISIS network from the replay attacks
|    by introducing cryptographic sequence number into ISIS packets. The
|    method is compatible with the exsiting implementations of [HMAC].
|    This document does not provide a solution for replay attacks based on
|    the cryptographic sequence number roll-over. The administrator is
|    supposed to change the keys to prevent this type of attacks.
| 
| 2 Proposed Solution
| 
|    The cryptographic sequence number if introduced in ISIS packets in
|    the form of a new TLV with the type code <TBD>. The length of the
|    Value field in the TLV is 4 bytes (32 bits). The value of the Length
|    field is 5.
| 
|    The value field of the TLV contains the cryptographic sequence
|    number.
| 
|  2.1 Sending ISIS Packets with Cryptographic Sequence Number
| 
|    Implementations supporting the extensions described in this document
|    should maintain the cryptographic sequence number counter on a per-
|    interface basis. Implementations may use the up-time timer, or
|    initialize the counter with a zero value and increment it after
|    sending each packet on the interface. The cryptographic sequence
|    number roll-over procedure is not defined in this document.
| 
|    When constructing an ISIS packet authenticated using [HMAC], the
|    router may include the cryptographic sequence number TLV in it. If
|    the TLV is included, it should be considered a part of the text for
|    the digest calculation.
| 
|  2.3 Receiving ISIS Packets with Cryptographic Sequence Number
| 
|    ISIS implementations supporting described extensions should maintain
|    the received cryptographic sequence number on a per-neighbor basis.
| 
|    When receiving authenticated ISIS packets, the router performs the
|    following checks.
| 
| 
| 
| Zinin                                                           [Page 2]
| 
| 
| 
| 
| 
| INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| 
| 
|     1. If the cryptographic sequence number TLV is present in
|        the received packet, compare the value found in the TLV
|        with the value in the neighbor data structure. If the
|        received value is less than the locally recorded one,
|        the ISIS packet should be ignored. Otherwise, the router
|        should perform the packet verification procedure as
|        described in [HMAC] and update the neighbor data structure
|        with the received crypo sequence number.
| 
|     2. If the ISIS packet is authenticated using [HMAC], does not
|        contain the crypto sequence number TLV, and the router is
|        configured to perform crypto sequence number verification
|        on the receiving interface, the ISIS packet should be ignored.
|        Otherwise (the router is not configured to perform this
|        verification), the packet should be authenticated as
|        described in [HMAC].
| 
| 3 Compatibility Issues
| 
|    Implementations not supporting described extensions will ignore the
|    cryptographic sequence number TLV. Also, implementations supporting
|    the new TLV will interoperate with implementation using [HMAC] only
|    unless explicitly configured to perform sequence number verification,
|    which is expected to be done when all routers on a segment support
|    described mechanism.
| 
| 4 Security issues
| 
|    This document describes a mechanism that improves security of the
|    ISIS protocol.
| 
| 5 Acknowledgements
| 
|    <TBD>
| 
| 6 References
| 
|    [ISIS] ISO, "Intermediate system to Intermediate system routeing
|           information exchange protocol for use in conjunction with the
|           Protocol for providing the Connectionless-mode Network Service
|           (ISO 8473)," ISO/IEC 10589:1992.
| 
|    [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication"
|           Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt.
| 
| 7 Authors' addresses
| 
|    Alex Zinin
| 
| 
| 
| Zinin                                                           [Page 3]
| 
| 
| 
| 
| 
| INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| 
| 
|    Nexsi Systems
|    1959 Concourse Drive
|    San Jose, CA 95131
|    azinin@nexsi.com
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| Zinin                                                           [Page 4]
| 
| 

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 02:42:31 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26397
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 02:42:30 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA38002;
	Thu, 28 Jun 2001 23:44:35 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA37907
	for <isis-wg@spider.juniper.net>; Thu, 28 Jun 2001 23:31:32 -0700 (PDT)
Received: from ghostrider.gredler.at (ghostrider.gredler.at [193.83.223.228])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5T6RKw07978
	for <isis-wg@juniper.net>; Thu, 28 Jun 2001 23:27:20 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from hannes@localhost)
	by ghostrider.gredler.at (8.9.3/8.9.3) id IAA25205;
	Fri, 29 Jun 2001 08:28:41 +0200
From: Hannes Gredler <hannes@juniper.net>
To: Alex Zinin <azinin@nexsi.com>
Cc: Tony Li <tli@procket.com>, isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
Message-ID: <20010629082840.A25186@juniper.net>
References: <15162.15644.474511.856119@redcs1.procket.com> <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net> <16012749723.20010628155209@nexsi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <16012749723.20010628155209@nexsi.com>; from azinin@nexsi.com on Thu, Jun 28, 2001 at 03:52:09PM -0700
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 08:28:40 +0200

Alex,

no practical ones, only for-clarity reasons -
just want to avoid to have authentication distributed over 3 TLVs.
[10,133,and your <TBD> TLV] -
motivation for that is that some greenfield-customers of mine
[=people new to the IS-IS protocol] kept asking about
the motivation behind TLV 133 ... 

however i do admit that having the crypto-seq-key in a
dedicated TLV does provide some migration-sexyness.

what could be done is to _proper_ structure [subTLVs]
your new <TBD> TLV in order to have _one_ extensible
general purpose authentication TLV, which potentially
can carry future, arbitrary, security related information
[pub-keys] etc ...

i'd volunteer for the draft if people find that interesting ....

/hannes

On Thu, Jun 28, 2001 at 03:52:09PM -0700, Alex Zinin wrote:
| 
| Hannes,
| 
|  Thanks for the comment.
| 
|  Except for the savings on the TLV header, what would
|  be the benefit? On the other hand, having a new TLV
|  that is "covered" by the HMAC digest provides a nice
|  transition behavior, i.e., those who don't know about
|  it, just ignore it...
| 
|  BTW, there's a mistake in my draft---the Length field
|  should be 4 bytes, not 5 :)
| 
| -- 
| Alex Zinin
| 
| Thursday, June 28, 2001, 3:29:37 PM, Hannes Gredler wrote:
| 
| > alex,
| 
| > couldn't we use a different authentication subtype
| > rather than a new TLV ?
| 
| > hmac-md5 uses id 54 so maybe 55 ?
| 
| > frame format would be 5 bytes of cryptograhic sequence #
| > plus 16 bytes of MD5 hash. TLV [10] length is always 22.
| 
| > /hannes
| 
| 
| > On Thu, Jun 28, 2001 at 03:01:55PM -0700, Alex Zinin wrote:
| > | 
| > | After some discussion with tli, I quickly drafted a small
| > | document (attached) that addresses some nasty replay attacks not
| > | covered by the HMAC doc. The intention is to see if people
| > | interested in ISIS authentication care about this stuff
| > | at all. If there's enough interest, I'll beautify the text
| > | and we can make it a separate WG item.
| > | 
| > | Another point for discussion---it may be a good idea to say
| > | that the implementations must put the Auth TLV in the beginning
| > | of the packet. This way we can drop attacker's packets and
| > | authenticate valid ones faster (we don't have to parse the whole
| > | thing). This, of course, will work only if the current
| > | implementations already do so, which I'm not 100% sure about,
| > | so more clue is welcome.
| > | 
| > | Cheers,
| > | 
| > | -- 
| > | Alex Zinin
| > | 
| > | Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote:
| > | 
| > | 
| | >> Folks,
| > | 
| | >> It's equally been forever on this draft as well, but we WOULD appreciate it
| | >> if you could look it over again.  It's been submitted as a revised ID.  If
| | >> we could get comments in by the end of next week, please.  Assuming that
| | >> there are no objections, we will push this forward to Informational.
| > | 
| | >> Ran & Tony
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | Network Working Group                                         Alex Zinin
| > | Internet Draft                                             Nexsi Systems
| > | Expiration Date: December 2001                                 June 2001
| > | File name: draft-ietf-isis-auth-anti-replay-00.txt
| > | 
| > | 
| > |                   Protecting ISIS from replay attacks
| > | 
| > |                 draft-ietf-isis-auth-anti-replay-00.txt
| > | 
| > | 
| > | Status of this Memo
| > | 
| > |    This document is an Internet-Draft and is in full conformance with
| > |    all provisions of Section 10 of RFC2026.
| > | 
| > |    Internet Drafts are working documents of the Internet Engineering
| > |    Task Force (IETF), its Areas, and its Working Groups. Note that other
| > |    groups may also distribute working documents as Internet Drafts.
| > | 
| > |    Internet Drafts are draft documents valid for a maximum of six
| > |    months. Internet Drafts may be updated, replaced, or obsoleted by
| > |    other documents at any time. It is not appropriate to use Internet
| > |    Drafts as reference material or to cite them other than as a "working
| > |    draft" or "work in progress".
| > | 
| > |    The list of current Internet-Drafts can be accessed at
| > |    http://www.ietf.org/ietf/1id-abstracts.txt
| > | 
| > |    The list of Internet-Draft Shadow Directories can be accessed at
| > |    http://www.ietf.org/shadow.html.
| > | 
| > | 
| > | Abstract
| > |    This document describes an additional mechanism for ISIS
| > |    cryptographic authentication that protects networks running ISIS from
| > |    simple packet replay attacks.
| > | 
| > | 1 Motivation
| > | 
| > |    The cryptographic authentication mechanism for [ISIS], described in
| > |    [HMAC] provides basic authentication functionality sufficient for the
| > |    majority of situations. However, this mechanism does not protect ISIS
| > |    networks from the replay attacks that can be performed by the
| > |    attacker if it has direct access to a broadcast segment running ISIS.
| > | 
| > |    Because the mechanism described in [HMAC] does not include the notion
| > |    of "cryptographic sequence number", an attacker can easily replay
| > | 
| > | 
| > | 
| > | Zinin                                                           [Page 1]
| > | 
| > | 
| > | 
| > | 
| > | 
| > | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| > | 
| > | 
| > |    recorded ISIS packets.
| > | 
| > |    Examples of these attacks include replaying an empty (listing no
| > |    neighbor IS) IIH packets and thus causing routers on the segment to
| > |    destroy the adjacencies with the router under attack, replaying CSNP
| > |    packets and thus artifically attracting ISIS traffic (LSPs) to the
| > |    segment's DIS, and so on. When used periodically, these attacks can
| > |    cause global instability in an ISIS domain.
| > | 
| > |    This document defines a simple mechanism, similar to the one used in
| > |    the OSPF protocol, to protect an ISIS network from the replay attacks
| > |    by introducing cryptographic sequence number into ISIS packets. The
| > |    method is compatible with the exsiting implementations of [HMAC].
| > |    This document does not provide a solution for replay attacks based on
| > |    the cryptographic sequence number roll-over. The administrator is
| > |    supposed to change the keys to prevent this type of attacks.
| > | 
| > | 2 Proposed Solution
| > | 
| > |    The cryptographic sequence number if introduced in ISIS packets in
| > |    the form of a new TLV with the type code <TBD>. The length of the
| > |    Value field in the TLV is 4 bytes (32 bits). The value of the Length
| > |    field is 5.
| > | 
| > |    The value field of the TLV contains the cryptographic sequence
| > |    number.
| > | 
| > |  2.1 Sending ISIS Packets with Cryptographic Sequence Number
| > | 
| > |    Implementations supporting the extensions described in this document
| > |    should maintain the cryptographic sequence number counter on a per-
| > |    interface basis. Implementations may use the up-time timer, or
| > |    initialize the counter with a zero value and increment it after
| > |    sending each packet on the interface. The cryptographic sequence
| > |    number roll-over procedure is not defined in this document.
| > | 
| > |    When constructing an ISIS packet authenticated using [HMAC], the
| > |    router may include the cryptographic sequence number TLV in it. If
| > |    the TLV is included, it should be considered a part of the text for
| > |    the digest calculation.
| > | 
| > |  2.3 Receiving ISIS Packets with Cryptographic Sequence Number
| > | 
| > |    ISIS implementations supporting described extensions should maintain
| > |    the received cryptographic sequence number on a per-neighbor basis.
| > | 
| > |    When receiving authenticated ISIS packets, the router performs the
| > |    following checks.
| > | 
| > | 
| > | 
| > | Zinin                                                           [Page 2]
| > | 
| > | 
| > | 
| > | 
| > | 
| > | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| > | 
| > | 
| > |     1. If the cryptographic sequence number TLV is present in
| > |        the received packet, compare the value found in the TLV
| > |        with the value in the neighbor data structure. If the
| > |        received value is less than the locally recorded one,
| > |        the ISIS packet should be ignored. Otherwise, the router
| > |        should perform the packet verification procedure as
| > |        described in [HMAC] and update the neighbor data structure
| > |        with the received crypo sequence number.
| > | 
| > |     2. If the ISIS packet is authenticated using [HMAC], does not
| > |        contain the crypto sequence number TLV, and the router is
| > |        configured to perform crypto sequence number verification
| > |        on the receiving interface, the ISIS packet should be ignored.
| > |        Otherwise (the router is not configured to perform this
| > |        verification), the packet should be authenticated as
| > |        described in [HMAC].
| > | 
| > | 3 Compatibility Issues
| > | 
| > |    Implementations not supporting described extensions will ignore the
| > |    cryptographic sequence number TLV. Also, implementations supporting
| > |    the new TLV will interoperate with implementation using [HMAC] only
| > |    unless explicitly configured to perform sequence number verification,
| > |    which is expected to be done when all routers on a segment support
| > |    described mechanism.
| > | 
| > | 4 Security issues
| > | 
| > |    This document describes a mechanism that improves security of the
| > |    ISIS protocol.
| > | 
| > | 5 Acknowledgements
| > | 
| > |    <TBD>
| > | 
| > | 6 References
| > | 
| > |    [ISIS] ISO, "Intermediate system to Intermediate system routeing
| > |           information exchange protocol for use in conjunction with the
| > |           Protocol for providing the Connectionless-mode Network Service
| > |           (ISO 8473)," ISO/IEC 10589:1992.
| > | 
| > |    [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication"
| > |           Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt.
| > | 
| > | 7 Authors' addresses
| > | 
| > |    Alex Zinin
| > | 
| > | 
| > | 
| > | Zinin                                                           [Page 3]
| > | 
| > | 
| > | 
| > | 
| > | 
| > | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| > | 
| > | 
| > |    Nexsi Systems
| > |    1959 Concourse Drive
| > |    San Jose, CA 95131
| > |    azinin@nexsi.com
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | Zinin                                                           [Page 4]
| > | 
| > | 
| 
| 
| _______________________________________________
| Isis-wg mailing list  -  Isis-wg@external.juniper.net
| http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 03:23:08 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24034
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 03:23:07 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA38253;
	Fri, 29 Jun 2001 00:25:13 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA38238
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 00:24:14 -0700 (PDT)
Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5T7K3w08975
	for <isis-wg@juniper.net>; Fri, 29 Jun 2001 00:20:04 -0700 (PDT)
X-JNPR-Received-From: outside
Received: (from prz@localhost)
	by net4u.net4u.ch (8.9.3/8.9.3) id JAA15862;
	Fri, 29 Jun 2001 09:20:08 +0200
From: Tony Przygienda <prz@net4u.ch>
Message-Id: <200106290720.JAA15862@net4u.net4u.ch>
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <139736780.20010628150155@nexsi.com> from Alex Zinin at "Jun 28, 2001  3: 1:55 pm"
To: azinin@nexsi.com
Cc: tli@procket.com, isis-wg@juniper.net
X-Mailer: ELM [version 2.4ME+ PL47 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 09:20:07 +0200 (MEST)
Content-Transfer-Encoding: 7bit

> 
> After some discussion with tli, I quickly drafted a small
> document (attached) that addresses some nasty replay attacks not
> covered by the HMAC doc. The intention is to see if people
> interested in ISIS authentication care about this stuff
> at all. If there's enough interest, I'll beautify the text
> and we can make it a separate WG item.

hmm , wouldn't that be rather something that we'd stick together
with key id into the HMAC TLV ? I'm getting just so litle concerned
about the proliferation of arbitrary TLVs floating around. It's 
not even that much the number space but you have to define the 
correlation of all those pieces of junk (eeeh, sorry, information)
to each other. What you do if HMAC is not around and you have 
this crypto sequence number in the packet? And what if you have
HMAC but not the crypto. The answer is always 'Obviously you do X'
but if not spelled out in some clear specs what X must be , 
multiple implementors
arrive to different 'X' solutions and interesting effects will
occur. This group is here to prevent those interesting effects 
from happening.

Technically, I glanced over your draft and it seems to me that what you 
trying to field is a 'nonce'. I've been told nonces are pretty
useless unless you actually negotiate them during adjacency
bring-up since otherwise somebody can record a session and
replay it with the recorded nonces. So not much protection you give. 
As well, think about implementations that process hellos before
they get to CSNP so they reorder internally. That makes nonces
hard since those implementations could drop packets arbitrarily.
Nothing anywhere seems to say that you have to process packets in the 
sequence you take them of the wire. BGP is simpler in this respect.

Rja may want to chime
in here but otherwise I'd strongly suggest to consult a security
expert who's done that before. I did that mechanism (key 
negotiation, nonce, even source authentication) in all gory
details once and it has more to it than meets the eye. Key id 
was kind of too obvious to let it pass I thought but getting 
into nonces will take it sweet time to get right.  Having said
that, I have nothing against a draft that specifies TLV
as we have today, key id+HMAC variation of the TLV and later version/RFC
with key id + nonce + HMAC variation of the TLV. They'll be all
backwards compatible since you can differentiate them on the 
length of the TLV. The only sentence needed is "implementation
MUST ignore HMAC TLV with unexpected length". Of course per 
interface knob is needed to say "send-plain-HMAC", "send-keyid-HMAC",
"send-keyid-nonce-HMAC". I don't have any particular 
preference, I'm just trying to keep the discussion 
technically sound and speak out trade-offs involved.

> Another point for discussion---it may be a good idea to say
> that the implementations must put the Auth TLV in the beginning
> of the packet. This way we can drop attacker's packets and
> authenticate valid ones faster (we don't have to parse the whole
> thing). This, of course, will work only if the current
> implementations already do so, which I'm not 100% sure about,
> so more clue is welcome.

parsing the TLV headers until you arrive to the HMAC tlv is 
very cheap (withough looking @ the content until you hit HMAC).
If you enforce that Auth TLV must be first, then you 
have to say what the implemenation supposed to do when it's not.
Dropping the packet
is kind of too harsh so you probably want "it SHOULD put it in 
the beginning and if it's somewhere else, accept anyway". 

Paul Koning taught me  something about protocol
design: If you want something in a packet but then you accept it
anyway if it's not that way, it's a waste of time even specifying
it. Occams razor or
in words of Goethe "In der Beschraenkung zeigt sich der Meister" or
in words of Henk "be liberal in what you accept" ;-)

	-- tony

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 03:26:34 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26527
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 03:26:33 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA38287;
	Fri, 29 Jun 2001 00:28:13 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA38275
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 00:27:27 -0700 (PDT)
Received: from pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5T7NHw09035;
	Fri, 29 Jun 2001 00:23:17 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from redback.com ([63.200.50.23])
 by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001))
 with ESMTP id <0GFO005IBKKQA0@mta7.pltn13.pbi.net>; Fri,
 29 Jun 2001 00:24:26 -0700 (PDT)
From: Tony Przygienda <prz@redback.com>
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
To: Hannes Gredler <hannes@juniper.net>
Cc: Alex Zinin <azinin@nexsi.com>, Tony Li <tli@procket.com>,
        isis-wg@juniper.net
Message-id: <3B3C2927.7F19E4BD@redback.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <15162.15644.474511.856119@redcs1.procket.com>
 <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net>
 <16012749723.20010628155209@nexsi.com> <20010629082840.A25186@juniper.net>
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 00:07:19 -0700
Content-Transfer-Encoding: 7BIT

Hannes Gredler wrote:

> Alex,
>
> no practical ones, only for-clarity reasons -
> just want to avoid to have authentication distributed over 3 TLVs.
> [10,133,and your <TBD> TLV] -
> motivation for that is that some greenfield-customers of mine
> [=people new to the IS-IS protocol] kept asking about
> the motivation behind TLV 133 ...
>
> however i do admit that having the crypto-seq-key in a
> dedicated TLV does provide some migration-sexyness.
>
> what could be done is to _proper_ structure [subTLVs]
> your new <TBD> TLV in order to have _one_ extensible
> general purpose authentication TLV, which potentially
> can carry future, arbitrary, security related information
> [pub-keys] etc ...
>
> i'd volunteer for the draft if people find that interesting ....

not a bad idea me thinks. That could take care of the key-id, nonce
and other stuff in a cleaner way that all other ways I've seen so far.
Why wouldn't we attach that stuff in 133 right after the HMAC e.g. ?

    -- tony


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 03:41:55 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07150
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 03:41:53 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA38414;
	Fri, 29 Jun 2001 00:43:12 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA38402
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 00:42:25 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5T7cEw09250;
	Fri, 29 Jun 2001 00:38:14 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id AAA07009;
	Fri, 29 Jun 2001 00:46:32 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <1193487614.20010629004631@nexsi.com>
To: Hannes Gredler <hannes@juniper.net>
CC: Tony Li <tli@procket.com>, isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <20010629082840.A25186@juniper.net>
References: <15162.15644.474511.856119@redcs1.procket.com>
 <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net>
 <16012749723.20010628155209@nexsi.com> <20010629082840.A25186@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 00:46:31 -0700
Content-Transfer-Encoding: 7bit


Hannes,

> no practical ones, only for-clarity reasons -
> just want to avoid to have authentication distributed over 3 TLVs.
> [10,133,and your <TBD> TLV] -
> motivation for that is that some greenfield-customers of mine
> [=people new to the IS-IS protocol] kept asking about
> the motivation behind TLV 133 ... 

Well, since 133 is not used anyway, we have only two,
which should be ok :)

> however i do admit that having the crypto-seq-key in a
> dedicated TLV does provide some migration-sexyness.

Yes, and I think this is pretty valuable.

> what could be done is to _proper_ structure [subTLVs]
> your new <TBD> TLV in order to have _one_ extensible
> general purpose authentication TLV, which potentially
> can carry future, arbitrary, security related information
> [pub-keys] etc ...

Hmmm... No problem subdividing... Would save the T-space,
I guess... Kind of having hard time imagining people actually
putting anything there considering the current state of
interest in security, though :))

> i'd volunteer for the draft if people find that interesting ....

Let's see what people say and coordinate then.

Alex.


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 04:08:11 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24887
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 04:08:10 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA38701;
	Fri, 29 Jun 2001 01:10:13 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA38686
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 01:09:51 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5T85fw09757
	for <isis-wg@juniper.net>; Fri, 29 Jun 2001 01:05:41 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id BAA07129;
	Fri, 29 Jun 2001 01:13:19 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <1145095136.20010629011319@nexsi.com>
To: Tony Przygienda <prz@net4u.ch>
CC: tli@procket.com, isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <200106290720.JAA15862@net4u.net4u.ch>
References: <200106290720.JAA15862@net4u.net4u.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 01:13:19 -0700
Content-Transfer-Encoding: 7bit


That's a long one :)
See below, pls.

>> After some discussion with tli, I quickly drafted a small
>> document (attached) that addresses some nasty replay attacks not
>> covered by the HMAC doc. The intention is to see if people
>> interested in ISIS authentication care about this stuff
>> at all. If there's enough interest, I'll beautify the text
>> and we can make it a separate WG item.

> hmm , wouldn't that be rather something that we'd stick together
> with key id into the HMAC TLV ?

Correct me if I'm wrong, but HMAC is not trying to send the Key ID,
just the digest. I specifically wanted to introduce as less changes
to the HMAC mechanism (since it is already deployed, I take it)
as possible.

> I'm getting just so litle concerned
> about the proliferation of arbitrary TLVs floating around. It's 
> not even that much the number space but you have to define the 
> correlation of all those pieces of junk (eeeh, sorry, information)
> to each other. What you do if HMAC is not around and you have 
> this crypto sequence number in the packet? And what if you have
> HMAC but not the crypto. The answer is always 'Obviously you do X'
> but if not spelled out in some clear specs what X must be , 
> multiple implementors
> arrive to different 'X' solutions and interesting effects will
> occur. This group is here to prevent those interesting effects 
> from happening.

That's why I said this is a quick _draft_ and I'll address this if
there's enough interest.

> Technically, I glanced over your draft and it seems to me that what you 
> trying to field is a 'nonce'.

Exactly, but not a random one as other protos do...

> I've been told nonces are pretty
> useless unless you actually negotiate them during adjacency
> bring-up since otherwise somebody can record a session and
> replay it with the recorded nonces. So not much protection you give.

Yes and no. Yes, meaning that the attacker can replay the session.
No meaning that protection is still there. We use the same mechanism
in OSPF. The assumption is that the key is changed on the segment
(in the domain) before the CryproSeqNum rolls over.

> As well, think about implementations that process hellos before
> they get to CSNP so they reorder internally. That makes nonces
> hard since those implementations could drop packets arbitrarily.
> Nothing anywhere seems to say that you have to process packets in the 
> sequence you take them of the wire. BGP is simpler in this respect.

I agree here. Note however, that implementations usually do the
authentication check as a part of the common sanity check and _then_
diverge the processing paths. So, this is addressible.

> Rja may want to chime
> in here but otherwise I'd strongly suggest to consult a security
> expert who's done that before. I did that mechanism (key 
> negotiation, nonce, even source authentication) in all gory
> details once and it has more to it than meets the eye. Key id 
> was kind of too obvious to let it pass I thought but getting 
> into nonces will take it sweet time to get right.

Hmmm... I think it's doable. The scheme works for OSPF already.

>  Having said
> that, I have nothing against a draft that specifies TLV
> as we have today, key id+HMAC variation of the TLV and later version/RFC
> with key id + nonce + HMAC variation of the TLV. They'll be all
> backwards compatible since you can differentiate them on the 
> length of the TLV. The only sentence needed is "implementation
> MUST ignore HMAC TLV with unexpected length". Of course per 
> interface knob is needed to say "send-plain-HMAC", "send-keyid-HMAC",
> "send-keyid-nonce-HMAC". I don't have any particular 
> preference, I'm just trying to keep the discussion 
> technically sound and speak out trade-offs involved.

I guess another consideration here is how much HMAC is deployed
and whether the length check is there or not. If it's not there,
and it's relatively widely deployed, we better off using a new TLV.

>> Another point for discussion---it may be a good idea to say
>> that the implementations must put the Auth TLV in the beginning
>> of the packet. This way we can drop attacker's packets and
>> authenticate valid ones faster (we don't have to parse the whole
>> thing). This, of course, will work only if the current
>> implementations already do so, which I'm not 100% sure about,
>> so more clue is welcome.

> parsing the TLV headers until you arrive to the HMAC tlv is 
> very cheap (withough looking @ the content until you hit HMAC).

One could envision an attacker doing a DOS-type of attack sending
invalid, MTU-long IIHs, containing bogus TLVs and putting the HMAC
one the last in set. Couple of loads instead of hundreds sounds like
a difference. Now recall jumbos and subsecond hellos...
I'm not saying this will save us from it, but it just seems better
to me.

> If you enforce that Auth TLV must be first, then you 
> have to say what the implemenation supposed to do when it's not.
> Dropping the packet
> is kind of too harsh so you probably want "it SHOULD put it in 
> the beginning and if it's somewhere else, accept anyway".

No, this would defeat the whole thing.

> Paul Koning taught me  something about protocol
> design: If you want something in a packet but then you accept it
> anyway if it's not that way, it's a waste of time even specifying
> it.

Exactly.

> Occams razor or
> in words of Goethe "In der Beschraenkung zeigt sich der Meister" or
> in words of Henk "be liberal in what you accept" ;-)

Well, I guess protocol security itself is kind of an exception from
this rule :)

IMHO if implementations do put 10 in some order today, we should
take advantage of this.

Alex.


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 04:13:43 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28233
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 04:13:42 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA38753;
	Fri, 29 Jun 2001 01:15:13 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA38732
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 01:14:24 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5T8AEw09832;
	Fri, 29 Jun 2001 01:10:14 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id BAA07137;
	Fri, 29 Jun 2001 01:18:32 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <435406984.20010629011831@nexsi.com>
To: Tony Przygienda <prz@redback.com>
CC: Hannes Gredler <hannes@juniper.net>, Tony Li <tli@procket.com>,
        isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <3B3C2927.7F19E4BD@redback.com>
References: <15162.15644.474511.856119@redcs1.procket.com>
 <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net>
 <16012749723.20010628155209@nexsi.com> <20010629082840.A25186@juniper.net>
 <3B3C2927.7F19E4BD@redback.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 01:18:31 -0700
Content-Transfer-Encoding: 7bit


Putting the key-id sounds indeed as a _real_ reason for sub-TLVs.

Alex.

> not a bad idea me thinks. That could take care of the key-id, nonce
> and other stuff in a cleaner way that all other ways I've seen so far.
> Why wouldn't we attach that stuff in 133 right after the HMAC e.g. ?

>     -- tony


> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 04:25:33 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07089
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 04:25:32 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA38855;
	Fri, 29 Jun 2001 01:27:13 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA38838
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 01:26:07 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5T8Lvw10055
	for <isis-wg@juniper.net>; Fri, 29 Jun 2001 01:21:57 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id BAA07173;
	Fri, 29 Jun 2001 01:29:30 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <1536064900.20010629012929@nexsi.com>
To: Tony Przygienda <prz@net4u.ch>, tli@procket.com, isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <1145095136.20010629011319@nexsi.com>
References: <200106290720.JAA15862@net4u.net4u.ch>
 <1145095136.20010629011319@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 01:29:29 -0700
Content-Transfer-Encoding: 7bit

Friday, June 29, 2001, 1:13:19 AM, Alex Zinin wrote:
> I guess another consideration here is how much HMAC is deployed
> and whether the length check is there or not. If it's not there,
> and it's relatively widely deployed, we better off using a new TLV.

Commenting myself. I would expect the length check to be there
as a part of normal well-known TLV processing, so probably this
is not a problem. But using 133 with Sub-TLVs sounds indeed better
to me.

Alex.


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 13:24:42 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19904
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 13:24:41 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41172;
	Fri, 29 Jun 2001 10:26:12 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41160
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 10:25:36 -0700 (PDT)
Received: from tot-wm.proxy.aol.com (tot-wm.proxy.aol.com [205.188.199.131])
	  by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id NAA07039 for <isis-wg@external.juniper.net>;
	  Fri, 29 Jun 2001 13:20:03 -0400 (EDT)
Received: from ma.ultranet.com (AC892FA9.ipt.aol.com [172.137.47.169])
	by tot-wm.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f5THK0c07553
	for <isis-wg@external.juniper.net>; Fri, 29 Jun 2001 13:20:01 -0400 (EDT)
Message-ID: <3B3CE366.6D5259D7@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
References: <200106290720.JAA15862@net4u.net4u.ch> <1145095136.20010629011319@nexsi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 13:21:58 -0700
Content-Transfer-Encoding: 7bit


Alex Zinin wrote:
> > As well, think about implementations that process hellos before
> > they get to CSNP so they reorder internally. That makes nonces
> > hard since those implementations could drop packets arbitrarily.
> > Nothing anywhere seems to say that you have to process packets in the
> > sequence you take them of the wire. BGP is simpler in this respect.
> 
> I agree here. Note however, that implementations usually do the
> authentication check as a part of the common sanity check and _then_
> diverge the processing paths. So, this is addressible.

This might make things more difficult for implementations
that use a separate high priority/urgent data path for
received hellos, taking a divergent processing path _before_
any common protocol sanity checking. Of course, there are alternate 
methods that could be employed, but it raises a question...

Out of curiosity, what would be the security effects of slightly
loosening the condition that a received message must have a higher
crypto seq num than the last recorded crypto seq num from the nbr,
to instead say that a received message must have a crypto seq num
no less than N behind the last recorded crypto seq num from the nbr
(for small N) ?  Instead of monotonically increasing received seq 
numbers, there would then be a small window of lagging but still valid 
numbers which slides up. On the one hand, it would permit a small amount 
of internal reordering (e.g., hellos could leapfrog up a bit), 
but on the other hand it would allow a malicious entity to replay 
some of the currently last N messages. How much of 
a lag would there need to be to cause a serious security risk? 

Side note: after rereading the draft, 
I have another question... in section 2.3 step 1, it says that
the received crypto seq number cannot be less than the last
recorded one... assuming that seq nums should be increasing per sec 2.1,
should that say instead that it cannot be less than or equal to
the recorded one (i.e., must be greater)? 
Also, if so, then sec 2.1 should probably say on sending
to init at 1 or greater instead of allowing 0 since the increment
is done after sending (assuming the receiving side will init the 
recorded value to 0).

Thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 13:44:50 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20556
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 13:44:49 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41271;
	Fri, 29 Jun 2001 10:46:13 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA41013
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 09:52:51 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5TGmbw23059
	for <isis-wg@juniper.net>; Fri, 29 Jun 2001 09:48:37 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from mosquito.inet.org (rja-laptop [10.30.34.139])
	by gnat.inet.org (Postfix) with ESMTP id 0854C8266E
	for <isis-wg@juniper.net>; Fri, 29 Jun 2001 12:49:52 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: isis-wg@juniper.net
From: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <1145095136.20010629011319@nexsi.com>
References: <200106290720.JAA15862@net4u.net4u.ch>
 <200106290720.JAA15862@net4u.net4u.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 12:45:51 -0400

At 04:13 29/06/01, Alex Zinin wrote:
>> I've been told nonces are pretty
>> useless unless you actually negotiate them during adjacency
>> bring-up since otherwise somebody can record a session and
>> replay it with the recorded nonces. So not much protection you give.
>
>Yes and no. Yes, meaning that the attacker can replay the session.
>No meaning that protection is still there. We use the same mechanism
>in OSPF. The assumption is that the key is changed on the segment
>(in the domain) before the CryproSeqNum rolls over.

        There are known issues with the OSPF and RIP use of the 
sequence number.  Vernon Schryver is normally happy to discuss 
at some length if asked.  As it happens, the deployment was 
too widespread for it to be realistic to change either of those specs 
-- at the point that issue entered the public literature.

Ran



_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 13:57:05 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20934
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 13:57:05 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41364;
	Fri, 29 Jun 2001 10:57:13 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41352
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 10:56:33 -0700 (PDT)
Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA11213;
	Fri, 29 Jun 2001 11:00:06 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <14340299757.20010629110004@nexsi.com>
To: David Hudek <dhudek@ma.ultranet.com>
CC: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <3B3CE366.6D5259D7@ma.ultranet.com>
References: <200106290720.JAA15862@net4u.net4u.ch>
 <1145095136.20010629011319@nexsi.com> <3B3CE366.6D5259D7@ma.ultranet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 11:00:04 -0700
Content-Transfer-Encoding: 7bit


David,

Friday, June 29, 2001, 1:21:58 PM, David Hudek wrote:
>> I agree here. Note however, that implementations usually do the
>> authentication check as a part of the common sanity check and _then_
>> diverge the processing paths. So, this is addressible.

> This might make things more difficult for implementations
> that use a separate high priority/urgent data path for
> received hellos, taking a divergent processing path _before_
> any common protocol sanity checking. Of course, there are alternate 
> methods that could be employed, but it raises a question...

Good point, see below.

> Out of curiosity, what would be the security effects of slightly
> loosening the condition that a received message must have a higher
> crypto seq num than the last recorded crypto seq num from the nbr,
> to instead say that a received message must have a crypto seq num
> no less than N behind the last recorded crypto seq num from the nbr
> (for small N) ?  Instead of monotonically increasing received seq 
> numbers, there would then be a small window of lagging but still valid 
> numbers which slides up. On the one hand, it would permit a small amount 
> of internal reordering (e.g., hellos could leapfrog up a bit), 
> but on the other hand it would allow a malicious entity to replay 
> some of the currently last N messages. How much of 
> a lag would there need to be to cause a serious security risk?

Well... this would give a much bigger window to the attacker.

I think the right way to address the problem of convergent processing
paths is maintaining separate CSNs on the sending and the receiving
sides so that CSNs, SNPs and LSPs have different contexts. In fact, since
ISIS is authenticating LSPs, one would probably want to have separate
CSNs for LSPs anyway. So we can just make it generalized enough and
say the three groups have separate sets.

> Side note: after rereading the draft, 
> I have another question... in section 2.3 step 1, it says that
> the received crypto seq number cannot be less than the last
> recorded one... assuming that seq nums should be increasing per sec 2.1,
> should that say instead that it cannot be less than or equal to
> the recorded one (i.e., must be greater)?

The reason for strict "not less" is to allow implementations that
use a local timer as the CSN and send multiple packets within a sec.

Thanks,

Alex.

> Also, if so, then sec 2.1 should probably say on sending
> to init at 1 or greater instead of allowing 0 since the increment
> is done after sending (assuming the receiving side will init the 
> recorded value to 0).

> Thanks,
> dave h
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 14:01:39 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21129
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 14:01:37 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA41417;
	Fri, 29 Jun 2001 11:03:14 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA41405
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 11:02:26 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5THwBw26078
	for <isis-wg@juniper.net>; Fri, 29 Jun 2001 10:58:11 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA11335;
	Fri, 29 Jun 2001 11:06:30 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <3140683129.20010629110628@nexsi.com>
To: RJ Atkinson <rja@inet.org>
CC: isis-wg@juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2>
References: <200106290720.JAA15862@net4u.net4u.ch>
 <200106290720.JAA15862@net4u.net4u.ch>
 <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 11:06:28 -0700
Content-Transfer-Encoding: 7bit


Ran,

 Thanks for the info, I'll get in touch with Vernon.
 Meanwhile, do you have any pointers?

-- 
Alex Zinin

Friday, June 29, 2001, 9:45:51 AM, RJ Atkinson wrote:

> At 04:13 29/06/01, Alex Zinin wrote:
>>> I've been told nonces are pretty
>>> useless unless you actually negotiate them during adjacency
>>> bring-up since otherwise somebody can record a session and
>>> replay it with the recorded nonces. So not much protection you give.
>>
>>Yes and no. Yes, meaning that the attacker can replay the session.
>>No meaning that protection is still there. We use the same mechanism
>>in OSPF. The assumption is that the key is changed on the segment
>>(in the domain) before the CryproSeqNum rolls over.

>         There are known issues with the OSPF and RIP use of the 
> sequence number.  Vernon Schryver is normally happy to discuss 
> at some length if asked.  As it happens, the deployment was 
> too widespread for it to be realistic to change either of those specs 
> -- at the point that issue entered the public literature.

> Ran



> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 18:12:00 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26212
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 18:11:59 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA42708;
	Fri, 29 Jun 2001 15:13:14 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA42696
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 15:12:31 -0700 (PDT)
Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id PAA13887;
	Fri, 29 Jun 2001 15:16:04 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <12355656019.20010629151601@nexsi.com>
To: David Hudek <dhudek@ma.ultranet.com>, isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <14340299757.20010629110004@nexsi.com>
References: <200106290720.JAA15862@net4u.net4u.ch>
 <1145095136.20010629011319@nexsi.com> <3B3CE366.6D5259D7@ma.ultranet.com>
 <14340299757.20010629110004@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 15:16:01 -0700
Content-Transfer-Encoding: 7bit

Friday, June 29, 2001, 11:00:04 AM, Alex Zinin wrote:
> I think the right way to address the problem of convergent processing
> paths is maintaining separate CSNs on the sending and the receiving
> sides so that CSNs, SNPs and LSPs have different contexts. In fact, since
> ISIS is authenticating LSPs, one would probably want to have separate
> CSNs for LSPs anyway. So we can just make it generalized enough and
> say the three groups have separate sets.

Thinking more about this... I guess we can go without CSNs in LSPs,
as the LSP's own SN should be enough in most cases (except for
the purge case, which is described in HMAC). So, we need only
two CSN groups---IIH & SNPs.

Alex.


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Fri Jun 29 23:02:02 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02331
	for <isis-archive@odin.ietf.org>; Fri, 29 Jun 2001 23:02:02 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA43893;
	Fri, 29 Jun 2001 20:03:13 -0700 (PDT)
Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged))
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA43881
	for <isis-wg@spider.juniper.net>; Fri, 29 Jun 2001 20:02:07 -0700 (PDT)
Received: from mail.nexsi.com ([63.121.79.248])
	by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f5U2vmw42635
	for <isis-wg@juniper.net>; Fri, 29 Jun 2001 19:57:48 -0700 (PDT)
X-JNPR-Received-From: outside
Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140])
	by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id UAA17305;
	Fri, 29 Jun 2001 20:06:09 -0700
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <10773060375.20010629200609@nexsi.com>
To: isis-wg@juniper.net
CC: RJ Atkinson <rja@inet.org>
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
In-Reply-To: <3140683129.20010629110628@nexsi.com>
References: <200106290720.JAA15862@net4u.net4u.ch>
 <200106290720.JAA15862@net4u.net4u.ch>
 <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2>
 <3140683129.20010629110628@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Fri, 29 Jun 2001 20:06:09 -0700
Content-Transfer-Encoding: 7bit


 Folks,

 So, we had a discussion with Vernon (RJ was CC'ed, so
 he'll probably step in if I do not reflect the discussion
 correctly).

 The SeqNum problems discussed are as follows:

   1. What happens when the SeqNum rolls back to 0.
   2. What happens when the router restarts.
   
 I share these concerns completely.
 
 They way I suggest these problems to be addressed is
 as follows. (I belive Jerome Etienne has a paper on a similar
 mechanism for OSPF somewhere.)

   1. SeqNum roll back does not seem to be a problem to me,
      see item 4 below.

   2. In the new TLV, introduce the generation ID (16 or 32 bits).

   3. The implementations guarantee that the generation ID is
      incremented with each reboot using one of multiple methods,
      e.g., reading, incrementing and writing it back to nvram
      on each boot, or using seconds since somewhen, or a calendar
      clock, whatever is better suited for a specific system.

   4. The CSN is incremented after each packet. If a system sends
      10 packs per sec, 32-bit space will give us more than 10
      years of a key lifetime. We may want to increase it though,
      if we seriously consider subsecond hellos.

   5. The receiving side checks that the CSN in the packet is
      _greater_ than the locally stored value.

 Vernon did not seem to like the scheme, because of the possible
 issues with NVRAM, and calendar clock...

 I believe the scheme works. The NVRAM/flash/disk/floppy/tape/punch-card
 portion should work, since the write is happening once per reboot and
 does not depend on the packet sending frequency. In fact I believe this
 is an implementation issue and the doc should only hint on this, but
 definitely not specify.

 If anyone believes there are flaws, please speak up.

 Cheers,
 
Alex.


_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 30 12:00:25 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23435
	for <isis-archive@odin.ietf.org>; Sat, 30 Jun 2001 12:00:25 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA49009;
	Sat, 30 Jun 2001 09:01:13 -0700 (PDT)
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA48997
	for <isis-wg@spider.juniper.net>; Sat, 30 Jun 2001 09:00:46 -0700 (PDT)
Received: from tot-ti.proxy.aol.com (tot-ti.proxy.aol.com [152.163.194.131])
	  by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id LAA17692 for <isis-wg@external.juniper.net>;
	  Sat, 30 Jun 2001 11:57:31 -0400 (EDT)
Received: from ma.ultranet.com (AC9D3E62.ipt.aol.com [172.157.62.98])
	by tot-ti.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f5UFvTm10901
	for <isis-wg@external.juniper.net>; Sat, 30 Jun 2001 11:57:29 -0400 (EDT)
Message-ID: <3B3E2194.9D853DEE@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
References: <200106290720.JAA15862@net4u.net4u.ch>
	 <1145095136.20010629011319@nexsi.com> <3B3CE366.6D5259D7@ma.ultranet.com>
	 <14340299757.20010629110004@nexsi.com> <12355656019.20010629151601@nexsi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: Hudeks@aol.com
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 30 Jun 2001 11:59:32 -0700
Content-Transfer-Encoding: 7bit


Alex Zinin wrote:
> Thinking more about this... I guess we can go without CSNs in LSPs,
> as the LSP's own SN should be enough in most cases (except for
> the purge case, which is described in HMAC). So, we need only
> two CSN groups---IIH & SNPs.

Sounds good. Allows implementations to easily reorder
types of messages if desired (e.g., high priority hellos)

-------------------------------------------------------------------
I had another question, but upon reading my email this morning,
I see that it's already been addressed :-)
(problem with restarting after being up for a while... 
after restart you are using small seq num but BadGuy replays 
one of your previous high seq num to your peer... so peer stops 
listening to you until/unless your seq num increments up to the
old value)

I'm definitely NOT a security expert, but since there
were some drawbacks mentioned for the proposed scheme
(issues with NVRAM, and calendar clock),
I'm wondering what would be the drawbacks of taking a page
from the LSP seq num handling and just putting in a mechanism
for an entity to bump up their seq num state if they discover a
prior incarnation with higher state floating about. 

They could discover that if the crypto data in a hello 
included not only your crypto state (seqNum, or genId + seqNum)
for the message in question, but also your current view of your 
neighbor's state for each category (IIH, SNP). 

If upon examining your neighbor's hello, you discovered
that they had been fooled, you could set your seq number
state appropriately (e.g., set genId/seqNum higher) and so recover.
To handle the case of both sides under attack at the same time, 
I suppose the procedure would have to change to have you conditionally 
trust the neighbor's view of yourself even if their own seq num is 
too small to trust the rest of the message (assuming it passes the
hmac test)... only trust and act upon it if the number is greater 
than your current value, so you only ratchet up (never reduce) 
crypto state. 

As long as both sides only ratchet up their crypto state, 
naively it would appear to be OK for such trust (don't at first 
see how a BadGuy could exploit the conditional trust of the neighbor's 
view of your seq num... even if they replayed an older one with smaller
values you wouldn't set your state lower).

There may be horrible security flaws in this :-),
but it does seem a little simpler and more automatic,
without any nvram, calendar clock, etc. issues.
You can start off with 0 state and recover to
acceptable state after a hello from your peer.
Might be worth discussing?



Actually, I just thought of one possible bad scenario, but
it seems sort of far-out?... if a BadGuy had a large
history of your prior messages (you had been up a long time), 
then they could incrementally fool your neighbor... replay to 
set seq num a bit higher than you, then you recover, then they
replay a different one to set yet a bit higher, then you recover, etc.
You could recover with a relatively large extra jump to reduce this,
I suppose, but then you'll start using up the space faster.
If the space is large enough (genID+seqNum) then this
might not be an issue?


thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 30 15:15:52 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24797
	for <isis-archive@odin.ietf.org>; Sat, 30 Jun 2001 15:15:51 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA49802;
	Sat, 30 Jun 2001 12:17:14 -0700 (PDT)
Received: from antiochus-fe0.ultra.net (antiochus-fe0.ultra.net [146.115.8.188])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA49789
	for <isis-wg@spider.juniper.net>; Sat, 30 Jun 2001 12:16:36 -0700 (PDT)
Received: from ma.ultranet.com (209-122-234-136.s2200.apx2.sbo.ma.dialup.rcn.com [209.122.234.136]) by antiochus-fe0.ultra.net (8.8.8/ult/n20340/mtc.v2) with ESMTP id PAA04770 for <isis-wg@external.juniper.net>; Sat, 30 Jun 2001 15:13:44 -0400 (EDT)
Message-ID: <3B3E4F94.1DA6313B@ma.ultranet.com>
From: David Hudek <dhudek@ma.ultranet.com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
References: <15162.15644.474511.856119@redcs1.procket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 30 Jun 2001 15:15:48 -0700
Content-Transfer-Encoding: 7bit


Quick comment on a possible implication of the hello text...

>    IS-IS HELLO PDUs SHALL use the  Link  Level
>    Authentication String, which MAY be different from that of Link State
>    PDUs.  The  HMAC-MD5  result  for  the  IS-IS  HELLO  PDUs  SHALL  be
>    calculated  after the Packet is padded to the MTU size, if padding is
>    not disabled. 

This would seem to imply that if padding is not disabled,
then if you want to interoperate you must
pad every hello, which would appear to be a change to
the Point-to-point hello procedure in 10589
(where it says to only pad the first IIH hello).
Are the "dominant implementations" padding all the
p2p hellos anyway? 

Thanks,
dave h
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg


From isis-wg-admin@spider.juniper.net  Sat Jun 30 16:19:10 2001
Received: from external.juniper.net (spider.juniper.net [207.17.137.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25258
	for <isis-archive@odin.ietf.org>; Sat, 30 Jun 2001 16:19:08 -0400 (EDT)
Received: from spider.juniper.net (localhost [127.0.0.1])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA50101;
	Sat, 30 Jun 2001 13:21:14 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA50089
	for <isis-wg@spider.juniper.net>; Sat, 30 Jun 2001 13:20:46 -0700 (PDT)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5UKI2r24095;
	Sat, 30 Jun 2001 13:18:02 -0700 (PDT)
Received: from cisco.com ([10.19.97.181])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AJE06345 (AUTH sluong);
	Sat, 30 Jun 2001 13:17:54 -0700 (PDT)
Message-ID: <3B3E2680.C308B342@cisco.com>
From: steve luong <sluong@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Hudek <dhudek@ma.ultranet.com>
CC: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt
References: <15162.15644.474511.856119@redcs1.procket.com> <3B3E4F94.1DA6313B@ma.ultranet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@spider.juniper.net
Errors-To: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help: <mailto:isis-wg-request@external.juniper.net?subject=help>
List-Post: <mailto:isis-wg@external.juniper.net>
List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	<mailto:isis-wg-request@external.juniper.net?subject=unsubscribe>
List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
Date: Sat, 30 Jun 2001 12:20:32 -0700
Content-Transfer-Encoding: 7bit

No, it does not imply that. That sentence does not change the decision to pad or
not to pad the IIH
in anyway. It tells you the sequence of what to do first. The sequence is you
pad the IIH first (if the IIH is supposed to be padded), then do the MD5
calculation over the entire PDU.

David Hudek wrote:
> 
> Quick comment on a possible implication of the hello text...
> 
> >    IS-IS HELLO PDUs SHALL use the  Link  Level
> >    Authentication String, which MAY be different from that of Link State
> >    PDUs.  The  HMAC-MD5  result  for  the  IS-IS  HELLO  PDUs  SHALL  be
> >    calculated  after the Packet is padded to the MTU size, if padding is
> >    not disabled.
> 
> This would seem to imply that if padding is not disabled,
> then if you want to interoperate you must
> pad every hello, which would appear to be a change to
> the Point-to-point hello procedure in 10589
> (where it says to only pad the first IIH hello).
> Are the "dominant implementations" padding all the
> p2p hellos anyway?
> 
> Thanks,
> dave h
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg